lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 20 Mar 2014 16:48:30 +0100
From:	David Herrmann <>
To:, David Herrmann <>,
	linux-kernel <>,
	Hugh Dickins <>,
	Alexander Viro <>,
	Karol Lewandowski <>,
	Kay Sievers <>, Daniel Mack <>,
	Lennart Poettering <>,
	John Stultz <>,
	Greg Kroah-Hartman <>, Tejun Heo <>,
	Johannes Weiner <>,
	"" <>,
	linux-fsdevel <>,
	linux-mm <>,
	Andrew Morton <>,
	Linus Torvalds <>,
	Ryan Lortie <>,
	"Michael Kerrisk (man-pages)" <>
Subject: Re: [PATCH 0/6] File Sealing & memfd_create()


On Thu, Mar 20, 2014 at 4:32 PM,  <> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists