From: sven.vermeulen@siphos.be (Sven Vermeulen)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Everything in mount_t or filesystem-specific mounts?
Date: Sat, 11 Jul 2015 14:49:16 +0200 [thread overview]
Message-ID: <20150711124916.GA23290@siphos.be> (raw)
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
next reply other threads:[~2015-07-11 12:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-11 12:49 Sven Vermeulen [this message]
2015-07-12 17:12 ` [refpolicy] Everything in mount_t or filesystem-specific mounts? Dominick Grift
2015-07-13 12:40 ` Christopher J. PeBenito
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150711124916.GA23290@siphos.be \
--to=sven.vermeulen@siphos.be \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.