--- 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
