[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41B6FDA1@IRSMSX102.ger.corp.intel.com>
Date: Fri, 29 Jul 2016 18:17:26 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Jann Horn <jann@...jh.net>, "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 2/5] task_unshare LSM hook
> 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.
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.
