[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 Jul 2016 18:09:02 +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 3/5] sb_unsharefs LSM hook
On Fri, Jul 29, 2016 at 10:34:38AM +0300, Elena Reshetova wrote:
> This adds a new security_sb_unsharefs() LSM hook.
> It can be used by LSMs concerned about unsharefs() system call.
>There is no unsharefs() system call. Your patch touches a kernel function
>unshare_fs_struct() that is called by the NFS server kernel thread and some
lustre stuff, which also looks like kernel threads.
Sorry, wrong wording, it isn't the system call, but it is an exported
function: http://lxr.free-electrons.com/source/fs/fs_struct.c#L152
So, in principle it can be used in many other places in future. Yes,
currently it is used by NFS server and Lustre, but no guarantees on what is
next in line.
Or are you saying that that having a check done in this palce doesn't make
sense? The reason I thought it is important is that since we need to store
the pointer to correct fs root and since it is updated in this case, we
don't want to miss this.
Best Regards,
Elena.
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.
