From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Mon, 13 Jul 2015 08:40:31 -0400 Subject: [refpolicy] Everything in mount_t or filesystem-specific mounts? In-Reply-To: <20150712171253.GC8841@x250> References: <20150711124916.GA23290@siphos.be> <20150712171253.GC8841@x250> Message-ID: <55A3B1BF.8080000@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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__t when mount executes /sbin/mount.) >> >> The mount domains by the file systems could then be done through a >> mount_domain_template() 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