On 03/20/2014 09:38 AM, tytso@mit.edu wrote:
On Thu, Mar 20, 2014 at 04:48:30PM +0100, David Herrmann wrote:
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).
Hmm, good point. I had forgotten about the /proc/self/fd hole. Hmm... what if we have a SEAL_PROC which forces the permissions of /proc/self/fd to be 000?
This is the second time in a week that someone has asked for a way to have a struct file (or struct inode or whatever) that can't be reopened through /proc/pid/fd. This should be quite easy to implement as a separate feature.
Actually, that feature would solve a major pet peeve of mine, I think: I want something like memfd that allows me to keep the thing read-write but that whomever I pass the fd to can't change. With this feature, I could do:
fd_rw = memfd_create (or O_TMPFILE or whatever) fd_ro = open(/proc/self/fd/fd_ro, O_RDONLY); fcntl(fd_ro, F_RESTRICT, F_RESTRICT_REOPEN);
send fd_ro via SCM_RIGHTS.
To really make this work well, I also want to SEAL_SHRINK the inode so that the receiver can verify that I'm not going to truncate the file out from under it.
Bingo, fast and secure one-way IPC.
--Andy