[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41B70522@IRSMSX102.ger.corp.intel.com>
Date: Mon, 1 Aug 2016 08:38:45 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>
CC: "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?
Yes, these ones. Also I guess in general security-wise it is better approach
to have a check in a place where descriptor will be attempted to
use/resolved vs. trying to make sure you caught all cases where/how process
might obtain some.
Various IPC, leaked descriptors, some other potential surprises... But I
think in this case it might be worth trying to do what you suggest since I
don't see good alternatives either.
>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.
I guess this could work, if I can correctly close the ones that are outside
of the chroot. I will check how SELinux does it. Thank you for the tip!
>Or are you concerned about shared file descriptor tables (which really
shouldn't happen accidentally,
You mean CLONE_FILES on clone()? If yes, then I am less concerned of this
since it really not common as far as I understood for legitimate
processes/daemons to be started this way. However, if this case needs to be
addressed, it is trickier, you cannot just substitute these ones with
/dev/null without breaking the parent also and you would need to check them
all, not just opened ones.
> at least when you keep in mind that for this to be an issue, the fs_struct
would have to not be shared)?
What do you mean by the last part? Not sure I understand here...
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.
