RE: [kernel-hardening] [RFC] [PATCH 1/5] path_fchdir and path_fhandle LSM hooks

From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: "kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>
Cc: "linux-security-module@vger.kernel.org"
	<linux-security-module@vger.kernel.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"spender@grsecurity.net" <spender@grsecurity.net>,
	"jmorris@namei.org" <jmorris@namei.org>,
	"Schaufler, Casey" <casey.schaufler@intel.com>,
	"Leibowitz, Michael" <michael.leibowitz@intel.com>,
	"Roberts, William C" <william.c.roberts@intel.com>
Subject: RE: [kernel-hardening] [RFC] [PATCH 1/5] path_fchdir and path_fhandle LSM hooks
Date: Mon, 1 Aug 2016 08:38:45 +0000	[thread overview]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41B70522@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <20160731212318.GA31482@pc.thejh.net>

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

>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...

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 7586 bytes --]