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)?
Wkr,
Sven Vermeulen
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
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
http://www.tresys.com | oss.tresys.com