[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 31 Jul 2016 23:23:18 +0200
From: Jann Horn <jann@...jh.net>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
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 06:28:08PM +0000, Reshetova, Elena wrote:
> On Sun, Jul 31, 2016 at 10:55:04AM +0000, Reshetova, Elena wrote:
[...]
> >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.
That doesn't make sense to me. Can you elaborate on that, please?
How would you "guess" a file descriptor? Are you talking about file
descriptors opened before chroot() that have been leaked accidentally?
In that case, you could just do on chroot() what SELinux does on a domain
transition and replace all dangerous open file descriptors with /dev/null.
Or are you concerned about shared file descriptor tables (which really
shouldn't happen accidentally, at least when you keep in mind that for
this to be an issue, the fs_struct would have to not be shared)?
Download attachment "signature.asc" of type "application/pgp-signature" (820 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.
