linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Edwin Zimmerman <edwin@211mainstreet.net>,
	'LSM' <linux-security-module@vger.kernel.org>
Subject: Re: New LSM hooks
Date: Tue, 5 Feb 2019 11:25:38 -0800	[thread overview]
Message-ID: <c15e8f04-df2e-40f4-d227-754d03de3dd0@schaufler-ca.com> (raw)
In-Reply-To: <000001d4bd80$8b9442c0$a2bcc840$@211mainstreet.net>

On 2/5/2019 10:28 AM, Edwin Zimmerman wrote:
> On Tuesday, February 05, 2019 12:40 PM Casey Schaufler wrote:
>> Full disclosure: This is all about me and my interests.
>> ...
>>
>> What do I want, I hear you cry? I want some sanity in the way
>> LSM hooks are introduced. I want some standards or conventions
>> on what is appropriate to pass into and out of LSM hooks. I
>> want push back on special purpose hooks that are required to
>> fix the deficiencies of a filesystem or bizarre hardware
>> implementation. I want to stop spending all my time trying to
>> deal with new, crazy LSM hooks. There are enough old ones to
>> keep me entertained, thank you very much.
> I agree.  We need a roadmap of where we want the LSM infrastructure to go.
> Without such a guide, LSM code is going to end up as a rats nest of
> confusing, partially implemented, partially supported code.

We've achieved rat's nest already. I'm working to untangle it as
part of the stacking work.

> Here's my suggestion for starters. According to kernel documentation, new 
> LSMs must be documented before being accepted.  Perhaps we need a 
> similar requirement for LSM hooks.

That would be handy. The documentation would need to cover
the purpose for the hook and how a security module would be
expected to use it.

> As I see it, LSMs are security additions,
> not functionality patches for the rest of the kernel or for special hardware or
> whatever.  Therefore, I also suggest that all new hooks be implemented in 
> at least two LSMs before being accepted.

I can't say this makes sense. The binder hooks are only
useful for Android, and requiring Smack or AppArmor hooks
be implemented isn't reasonable. It would be reasonable for
the kernfs hook, as the kernfs hook is a workaround for the
fact that kernfs doesn't use inodes.


  reply	other threads:[~2019-02-05 19:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-05 17:40 New LSM hooks Casey Schaufler
2019-02-05 18:15 ` Paul Moore
2019-02-05 20:04   ` Casey Schaufler
2019-02-06  0:01     ` Paul Moore
2019-02-06  1:11       ` James Morris
2019-02-06 13:20         ` Stephen Smalley
2019-02-06 17:24           ` Casey Schaufler
2019-02-06 17:44             ` Stephen Smalley
2019-02-06 18:18               ` Casey Schaufler
2019-02-06 16:30         ` Casey Schaufler
2019-02-06 17:06           ` Stephen Smalley
2019-02-06 17:44             ` Casey Schaufler
2019-02-06 17:48               ` Stephen Smalley
2019-02-05 18:28 ` Edwin Zimmerman
2019-02-05 19:25   ` Casey Schaufler [this message]
2019-02-05 19:58     ` Paul Moore
2019-02-05 20:10     ` Edwin Zimmerman

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=c15e8f04-df2e-40f4-d227-754d03de3dd0@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=edwin@211mainstreet.net \
    --cc=linux-security-module@vger.kernel.org \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).