Re: [PATCH 0/6] File Sealing & memfd_create()

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

On Thu, 20 Mar 2014 11:32:51 -0400
tytso@mit.edu wrote:

> On Wed, Mar 19, 2014 at 08:06:45PM +0100, David Herrmann wrote:
> > 
> > This series introduces the concept of "file sealing". Sealing a file restricts
> > the set of allowed operations on the file in question. Multiple seals are
> > defined and each seal will cause a different set of operations to return EPERM
> > if it is set. The following seals are introduced:
> > 
> >  * SEAL_SHRINK: If set, the inode size cannot be reduced
> >  * SEAL_GROW: If set, the inode size cannot be increased
> >  * SEAL_WRITE: If set, the file content cannot be modified
> 
> Looking at your patches, and what files you are modifying, you are
> enforcing this in the low-level file system.
> 
> Why not make sealing an attribute of the "struct file", and enforce it
> at the VFS layer?  That way all file system objects would have access
> to sealing interface, and for memfd_shmem, you can't get another
> struct file pointing at the object, the security properties would be
> identical.

Would it be more sensible to have a "sealer" which is a "device" which
you give a file handle too and it gives you back a sealable one.

So for the memfd case you'd create a private handle, pass it to the
sealer, and then pass the sealer handles to everyone else.

You have to implicitly trust the creator of the object has
- handed you the object you expect
- sealed it

so that appears no weaker but means you can meaningfully created sealed
versions of arbitary objects and if you want have non-sealed ones around
with it being up to the creator if they want for example to simply close
the unsealed one immediately afterwards.

Alan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>