From: Mimi Zohar <zohar@linux.vnet.ibm.com> To: Casey Schaufler <casey@schaufler-ca.com>, Christoph Hellwig <hch@lst.de>, Al Viro <viro@zeniv.linux.org.uk> Cc: Jan Kara <jack@suse.cz>, Jeff Layton <jlayton@redhat.com>, linux-fsdevel@vger.kernel.org, linux-ima-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org Subject: Re: [RFC PATCH 2/4] ima: define new ima_sb_post_new_mount hook Date: Wed, 16 Aug 2017 16:59:13 -0400 [thread overview] Message-ID: <1502917153.21278.48.camel@linux.vnet.ibm.com> (raw) In-Reply-To: <63522b3b-5e61-f760-5f74-f9fbe44741f5@schaufler-ca.com> On Wed, 2017-08-16 at 12:24 -0700, Casey Schaufler wrote: > On 8/16/2017 10:30 AM, Mimi Zohar wrote: > > diff --git a/security/security.c b/security/security.c > > index 592153e8d2b6..79111141b383 100644 > > --- a/security/security.c > > +++ b/security/security.c > > @@ -402,6 +402,7 @@ void security_sb_post_new_mount(const struct vfsmount *newmnt, > > const struct path *path) > > { > > call_void_hook(sb_post_new_mount, newmnt, path); > > + ima_sb_post_new_mount(newmnt, path); > > Have you thought about converting the IMA code into > a security module that gets loaded after all the others? > That would make this (and several other similar instances) > bit of special case code go away. Yes, each time I need to add another IMA call, where there isn't an existing LSM hook, a decision needs to be made as to whether it needs to be a generic LSM hook or not. Assuming we made IMA an LSM module, what would we do with these other calls? Would they need to be converted to LSM hooks? (Are all LSMs visited, even if an earlier LSM fails? Or does the first LSM failure, stop the LSM traversal?) Unlike LSMs which are sharing the i_sec, IMA doesn't have an entry in the inode, but does an rbtree lookup to access the associated data. Having an i_sec would simplify a lot of the code, but making this sort of change would be a major undertaking. In this context, I'm not sure what you mean by "loaded". IMA needs to be enabled from the very beginning to capture all measurements and verify the integrity of files, without any gaps. At some point this would include other LSM policies. IMA certainly cannot be loaded late like kernel modules. Similarly, we would need to think about EVM. Mimi
WARNING: multiple messages have this Message-ID (diff)
From: zohar@linux.vnet.ibm.com (Mimi Zohar) To: linux-security-module@vger.kernel.org Subject: [RFC PATCH 2/4] ima: define new ima_sb_post_new_mount hook Date: Wed, 16 Aug 2017 16:59:13 -0400 [thread overview] Message-ID: <1502917153.21278.48.camel@linux.vnet.ibm.com> (raw) In-Reply-To: <63522b3b-5e61-f760-5f74-f9fbe44741f5@schaufler-ca.com> On Wed, 2017-08-16 at 12:24 -0700, Casey Schaufler wrote: > On 8/16/2017 10:30 AM, Mimi Zohar wrote: > > diff --git a/security/security.c b/security/security.c > > index 592153e8d2b6..79111141b383 100644 > > --- a/security/security.c > > +++ b/security/security.c > > @@ -402,6 +402,7 @@ void security_sb_post_new_mount(const struct vfsmount *newmnt, > > const struct path *path) > > { > > call_void_hook(sb_post_new_mount, newmnt, path); > > + ima_sb_post_new_mount(newmnt, path); > > Have you thought about converting the IMA code into > a security module that gets loaded after all the others? > That would make this (and several other similar instances) > bit of special case code go away. Yes, each time I need to add another IMA call, where there isn't an existing LSM hook, a decision needs to be made as to whether it needs to be a generic LSM hook or not. Assuming we made IMA an LSM module, what would we do with these other calls? ?Would they need to be converted to LSM hooks? ?(Are all LSMs visited, even if an earlier LSM fails? ?Or does the first LSM failure, stop the LSM traversal?) Unlike LSMs which are sharing the i_sec, IMA doesn't have an entry in the inode, but does an rbtree lookup to access the associated data. ?Having an i_sec would simplify a lot of the code, but making this sort of change would be a major undertaking. In this context, I'm not sure what you mean by "loaded".? IMA needs to be enabled from the very beginning to capture all measurements and verify the integrity of files, without any gaps. ?At some point this would include other LSM policies. ?IMA certainly cannot be loaded late like kernel modules. Similarly, we would need to think about EVM. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-08-16 21:00 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-16 17:30 [RFC PATCH 0/4] ima: filesystems not mounted with i_version Mimi Zohar 2017-08-16 17:30 ` Mimi Zohar 2017-08-16 17:30 ` [RFC PATCH 1/4] security: define new LSM sb_post_new_mount hook Mimi Zohar 2017-08-16 17:30 ` Mimi Zohar 2017-08-16 17:30 ` [RFC PATCH 2/4] ima: define new ima_sb_post_new_mount hook Mimi Zohar 2017-08-16 17:30 ` Mimi Zohar 2017-08-16 19:24 ` Casey Schaufler 2017-08-16 19:24 ` Casey Schaufler 2017-08-16 20:59 ` Mimi Zohar [this message] 2017-08-16 20:59 ` Mimi Zohar 2017-08-17 2:39 ` [Linux-ima-devel] " James Morris 2017-08-17 2:39 ` James Morris 2017-12-07 12:26 ` Jeff Layton 2017-12-07 12:26 ` Jeff Layton 2017-12-07 14:35 ` Mimi Zohar 2017-12-07 14:35 ` Mimi Zohar 2017-12-07 14:35 ` Mimi Zohar 2017-12-07 14:50 ` Jeff Layton 2017-12-07 14:50 ` Jeff Layton 2017-12-07 15:08 ` Mimi Zohar 2017-12-07 15:08 ` Mimi Zohar 2017-12-07 15:08 ` Mimi Zohar 2017-12-07 15:09 ` Jeff Layton 2017-12-07 15:09 ` Jeff Layton 2017-12-15 21:13 ` Jeff Layton 2017-12-15 21:13 ` Jeff Layton 2017-08-16 17:30 ` [RFC PATCH 3/4] security: define a new LSM sb_post_remount hook Mimi Zohar 2017-08-16 17:30 ` Mimi Zohar 2017-08-16 17:30 ` [RFC PATCH 4/4] ima: define a new ima_sb_post_remount hook Mimi Zohar 2017-08-16 17:30 ` Mimi Zohar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1502917153.21278.48.camel@linux.vnet.ibm.com \ --to=zohar@linux.vnet.ibm.com \ --cc=casey@schaufler-ca.com \ --cc=hch@lst.de \ --cc=jack@suse.cz \ --cc=jlayton@redhat.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-ima-devel@lists.sourceforge.net \ --cc=linux-security-module@vger.kernel.org \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.