[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41B70337@IRSMSX102.ger.corp.intel.com>
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.
