RE: [kernel-hardening] [RFC] [PATCH 2/5] task_unshare LSM hook

From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: Jann Horn <jann@thejh.net>,
	"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 2/5] task_unshare LSM hook
Date: Fri, 29 Jul 2016 18:17:26 +0000	[thread overview]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41B6FDA1@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <20160729175819.GA11621@pc.thejh.net>

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

> Why would you have an LSM hook just for the unshare() syscall given that
clone() exposes nearly the same functionality?

My trace of thought was like this: Clone creates new process, so we have two
options: 

-  do one more hook here also (or have a joint hook) and then also add the
info about this process into the hardchroot info list

or 

- do not add this child process to the list and therefore we don't need
updated pointers on fs for it, but just treat it as a child (since it would
be chrooted to the same location unless it calls unshare, chroot, pivot_root
or similar).

I went with the second approach to minimize the hooks changes needed and
number of processes to store in internal list. 

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