Hi
On Thu, Mar 20, 2014 at 4:32 PM, tytso@mit.edu wrote:
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.
Sealing as introduced here is an inode-attribute, not "struct file". This is intentional. For instance, a gfx-client can get a read-only FD via /proc/self/fd/ and pass it to the compositor so it can never overwrite the contents (unless the compositor has write-access to the inode itself, in which case it can just re-open it read-write).
Furthermore, I don't see any use-case besides memfd for sealing, so I purposely avoided changing core VFS interfaces. Protecting page-allocation/access for SEAL_WRITE like I do in shmem.c is not that easy to do generically. So if we moved this interface to "struct inode", all that would change is moving "u32 seals;" from one struct to the other. Ok, some protections might get easily implemented generically, but I without proper insight in the underlying implemenation, I couldn't verify all paths and possible races. Isn't keeping the API generic enough so far? Changing the underlying implementation can be done once we know what we want.
Thanks David