On Thu, 20 Mar 2014 16:12:54 +0100 David Herrmann dh.herrmann@gmail.com wrote:
Hi
On Thu, Mar 20, 2014 at 3:41 PM, One Thousand Gnomes gnomes@lxorguk.ukuu.org.uk wrote:
I think you want two things at minimum
owner to seal root can always override
Why should root be allowed to override?
Because root can already override it by say mmapping the kernel memory and patching. It also tends to be valuable for debugging horrible problems with complex systems.
Imposing fake restrictions on root just causes annoyance when doing stuff like debugging but doesn't actually change the security situation.
I'm fine with F_SET/GET_SEALS. But given you suggested requiring MFD_ALLOW_SEALS for sealing, I don't see why we couldn't limit this interface entirely to memfd_create().
But if someone does find a non memfd use for it then it's useful not to have to go "this fnctl for memfd, that fnctl for the other"
Just planning ahead.
Whether you want some way to undo a seal without an exclusive reference as the file owner is another question.
No. You are never allowed to undo a seal but with an exclusive reference. This interface was created for situations _without_ any trust relationship. So if the owner is allowed to undo seals, the interface doesn't make any sense. The only options I see is to not allow un-sealing at all (which I'm fine with) or tracking users (which is way too much overhead).
Ok - that makes sense