Date: Sun, 31 Jul 2016 18:28:08 +0000 From: "Reshetova, Elena" <elena.reshetova@...el.com> To: Jann Horn <jann@...jh.net> CC: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, "linux-security-module@...r.kernel.org" <linux-security-module@...r.kernel.org>, "keescook@...omium.org" <keescook@...omium.org>, "spender@...ecurity.net" <spender@...ecurity.net>, "jmorris@...ei.org" <jmorris@...ei.org>, "Schaufler, Casey" <casey.schaufler@...el.com>, "Leibowitz, Michael" <michael.leibowitz@...el.com>, "Roberts, William C" <william.c.roberts@...el.com> Subject: RE: [RFC] [PATCH 1/5] path_fchdir and path_fhandle LSM hooks On Sun, Jul 31, 2016 at 10:55:04AM +0000, Reshetova, Elena wrote: > On Fri, Jul 29, 2016 at 10:34:36AM +0300, Elena Reshetova wrote: > > This introduces two new LSM hooks operating on paths. > > > > - security_path_fchdir() checks for permission on > > changing working directory. It can be used by > > LSMs concerned on fchdir system call > > >I don't think security_path_fchdir() is a good abstraction level. It > neither covers the whole case of "cwd is changed" nor does it cover > the whole case of "someone uses a file descriptor to a directory to > look up stuff outside that directory". > Do you have a suggestion on what can be a good place? > > >For example, security_path_fchdir() seems to be intended to prevent > >the use > of a leaked file descriptor to the outside world for accessing other > files in the outside world. > Yes, this was exactly the use case. > > >But this is trivially bypassed by first using openat() directly > >instead of > fchdir()+open() (something that used to work against grsecurity, but > was fixed quite a while ago). > The way it has been addressed in grsecurity is having a check inside > filename_lookup() , but it doesn't look a very great place for putting > a hook. I was thinking about it , but so far didn't find any other > good alternatives. >Yeah, if you want to have such a hook, I think it needs to be in >filename_lookup() or below - but that's a relatively hot function, so it might have a measurable performance impact. Yes, it is way too much used from everywhere and doesn't even fit into LSM design... >Alternatively, you could forbid double-chroots and use the LSM hooks for file descriptor passing via unix domain sockets and binder to check incoming file descriptors. This would not prevent guessing the file descriptor unfortunately. I was planning to continue on chroot features and like grsecurity have an option to disable unix domain sockets outside of chroot. Binder is a different story since it is Android specific and we don't expect it to be used on normal Linux system. And on Android nobody uses chroot, so I don't think there is a use case for this. >As long as no directories are moved out of the chroot directory by something outside the chroot (a process chrooted into a parent directory or a process that isn't chrooted), that should prooobably work? Yes, I think this might work for given use case since we are not expecting processes outside of chroot to help exploited process inside chroot to escape. But guessable file descriptor is still an issue (not sure how real is this issue in practice nowadays). Download attachment "smime.p7s" of type "application/pkcs7-signature" (7586 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.