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

[dac.override@gmail.com (Dominick Grift)]

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.

> 
> Wkr,
>         Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150712/ac88bfec/attachment.bin