--- Eric Paris [EMAIL PROTECTED] wrote:
On Fri, 2007-11-09 at 14:46 -0800, Casey Schaufler wrote:
--- Eric Paris [EMAIL PROTECTED] wrote:
Adds security_get_sb_mnt_opts, security_set_sb_mnt_opts, and
security_clont_sb_mnt_opts to the LSM and to SELinux. This will allow
filesystems to directly own and control all of their mount options if
they so choose.
I understand why you would want get_sb_mnt_opts(), but what
is the value for set_sb_mnt_opts() and what is the purpose of
clone_sb_mnt_opts()?
set is really the most important one. NFS knows when it creates a
superblock (using SELinux as an example) that it wants to set
context=blah. Thus it calls into set_sb_mnt_opts with the flag for
context= and blah. get_sb_mnt_opts will likely get used in the
future for /proc/mounts to be able to report the security options.
clone is really just to make it easy for the FS. If they know i want
the new one to look like this old one they can just call into clone_
and don't have to worry about dealing freeing memory or anything like
that...
This interface deals only with option identifiers and
strings so it should generic enough for any LSM which may come in the
future. Filesystems which pass text mount data around in the kernel
(almost all of them) need not currently make use of this interface for
SELinux sake since it will still parse those strings as it always has.
If SELinux is still dealing with strings on it's own what is
the point of these hooks?
The point is that not all filesystems use strings. NFS is the real in
kernel kicker. See things like fs/nfs/namespace.c:nfs_do_clone_mount()
where they pass a binary blob into the vfs which arrives to the LSM as a
binary blob which it cannot parse. (note NFS also uses
nfs_parsed_mount_data and nfs_mount_data)
Nothing like a real example to make your point. Yup, I see it.
Since the LSM can't (ok, isn't allowed according to previous
discussions with vfs/fs people) deal with those binary blobs to get its
options some method must be created for those filesystems to pass that
data in a usable way.
An LSM would need to implement these functions only if they had mount
time options, such as selinux has context= or fscontext=. If the LSM
has no mount time options they could simply not implement and let the
dummy ops take care of things.
Smack and SELinux currently deal with options in sb_kern_mount(), with
help from sb_copy_data(). Why change the implementation?
I don't plan to change anything for any FS that passes text options, but
we aren't allowed to parse binary blobs (nor can we actually even know
for sure what blobs we are dealing with currently in the LSM even if we
were 'allowed' to parse them and get the needed data directly)
Ick.
A LSM other than SELinux would need to define new option numbers in
security.h
I don't think it is a good idea to require that LSM specific
information be stored outside the scope of the LSM.
Its either that or FS specific knowledge inside the LSM. See
security/selinux/hooks.c:try_context_mount() for an example of NFS
specific knowledge inside an LSM. This current implementation has bugs
since we don't know if *data is any of the 3 above named structs. This
patch doesn't fix those issues, but lays the groundwork for a fix...
If the filesystem interface requires different behavior for
different filesystem types I'd say it's broken, but given that
that is the historical behavior I suppose we'll have to either
live with it or suggest a better way. Looks as if that's your
plan here.
(or could reuse if they have the same basic meaning I guess)
and any FS which decides to own there own security options would need to
be patched to use this new interface for every possible LSM. This is
because it was stated to me very clearly that LSM's should not attempt
to understand FS mount data and the burdon to understand security should
be in the FS which owns the options.
Perhaps a mount option prefix then. Smack.root, SELinux.context,
that sort of thing. An LSM writer shouldn't have to patch security.h
every time she wants to add a mount option.
I did originally namespace these things such as SELINUX__CONTEXT_MNT but
later wondered what the point was. If another LSM decided to somehow
make use of the same infrastructure in FS that have binary mount data
and they used context= they should be able to use a generic CONTEXT_MNT
rather than pretend that flag has some special meaning. It actually
works nicely for other LSMs since once I get finished with NFS it should
support 3 mount options which although maybe not named nicely for non
SELinux LSMs will be usable without any FS changes...
I hear rumblings about reviving the notion of LSM stacking, in which
case a limited number of shared mount options might not work so well.
And while I don't think its a great thing that every LSM
