[refpolicy] Everything in mount_t or filesystem-specific mounts?

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 7/12/2015 1:12 PM, Dominick Grift wrote:
> On Sat, Jul 11, 2015 at 02:49:16PM +0200, Sven Vermeulen wrote:
>> Hi all
>>
>> I'm working on a Ceph policy and I've noticed that I need to add a number of
>> additional privileges on top of mount_t. The /sbin/mount.ceph binary
>> executes script (corecmd_exec_shell) and perhaps a few more (I had to add in
>> a lot to get it to work, but have yet to see if it would be better for
>> _exec's or _domtrans's)
>>
>> Currently, it looks like the system/mount.te policy assumes that all
>> privileges are to be added to mount_t. However, I get the impression that
>> mount_t could be a lot "smaller" policy-wise if we would grant the
>> permissions to filesystem-specific mounts (i.e. have a domain transition
>> from mount_t to mount_<fs>_t when mount executes /sbin/mount.<fs>)
>>
>> The mount domains by the file systems could then be done through a
>> mount_domain_template(<fs>) call and expanded as necessary for the file
>> system itself.
>>
>> I noticed we already added a few filesystem-specifics (such as FUSE support,
>> and SMBFS) but compared to the other file systems the number is sufficiently
>> low to keep the policy enhancements on mount_t. But given that additional
>> file systems are being developed which put more and more features (and as
>> such often require more and more privileges) I would expect that this would
>> only grow.
>>
>> So my question: would it make sense to eventually migrate to
>> filesystem-specific mounts and, if so, what would be a good trigger (i.e.
>> which kind of permissions do we not want inside a generic mount_t)?
> 
> My take is find: a balance. For example mount.fuse does not add that many permissions to the mount domain (if any at all) so in that case it might not make sense to create a separate type for it.
> 
> However if mount.ceph requires a lot of extra permissions on top of the permissions that mount_t already has, then that may be a compelling reason to create a separate domain for mount.ceph.

Generally I'd agree; something such as networking permissions is a good
example where a new domain would be a good idea.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com