public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Eric Paris <eparis@redhat.com>,
	James Morris <james.l.morris@oracle.com>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: Stupid VFS name lookup interface..
Date: Sun, 26 May 2013 11:23:01 -0700	[thread overview]
Message-ID: <51A25305.90101@schaufler-ca.com> (raw)
In-Reply-To: <20130526120251.GA32729@thunk.org>

On 5/26/2013 5:02 AM, Theodore Ts'o wrote:
> On Sat, May 25, 2013 at 11:33:46AM -0700, Casey Schaufler wrote:
>> Now I'll put on my Smack maintainer hat. Performance improvement is
>> always welcome, but I would rather see attention to performance of
>> the LSM architecture than SELinux specific hacks. The LSM blob
>> pointer scheme is there so that you (Linus) don't have to see the
>> dreadful things that we security people are doing. Is it time to
>> get past that level of disassociation? Or, and I really hate asking
>> this, have you fallen into the SELinux camp?
> What part of the LSM architecture are you proposing be optimized?

Secids are an inherent performance issue.

This thread is all about a performance problem with
the security blob pointer scheme. I don't know what
would be better and general, but I'm willing to learn.


> The
> LSM layer is pretty thin, partially because the various different
> security approaches don't agree with each other on fairly fundamental
> issues.  What sort of optimization opportunities you are suggesting?
> Are there changes that can be made that all of the major security LSM
> maintainers would actually agree with?

As you point out, the various existing LSMs use a variety of
mechanisms to perform their access checks. A big part of what
I see as the "problem" is that the LSM hooks grew organically,
at a time when there was exactly one project being funded.
By the time other LSMs came in to the mainstream we had a
collection of hooks, not an architecture. The LSM architecture
has not been seriously revisited since.

Can we come to agreement? I don't know. I expect so.

>
> I've been re-reading the thread on LKML which was spawned when SMACK
> was proposed for upstream inclusion:
>
>     http://thread.gmane.org/gmane.linux.kernel/585903/focus=586412
>
> Have any of the arguments over the proper security models changed over
> or have gotten resolved over the past six years, while I haven't been
> looking?

I believe that Yama points to a serious change in the way
"operating systems" are being developed. The desktop is not
the sweet spot for Linux development, nor is the enterprise
server. Six years ago the Bell & LaPadula subject/object models
still made sense. Today, we're looking at applications, services
and resources. We don't have LSMs that support those* natively.
We are going to have new LSMs, and soon, if Linux is going to
remain relevant.

---
* SEAndriod is trying. We'll see where that goes.


>
> 						- Ted
>


  reply	other threads:[~2013-05-26 18:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-21 22:22 Stupid VFS name lookup interface Linus Torvalds
2013-05-21 22:34 ` Al Viro
2013-05-21 22:37   ` Linus Torvalds
2013-05-25  3:21 ` Linus Torvalds
2013-05-25 16:57   ` Al Viro
2013-05-25 17:26     ` Linus Torvalds
2013-05-25 18:33     ` Casey Schaufler
2013-05-26  3:22       ` Linus Torvalds
2013-05-26  5:04         ` James Morris
2013-05-26  5:19           ` Linus Torvalds
2013-05-26 17:59             ` Casey Schaufler
2013-05-26 18:17               ` Linus Torvalds
2013-05-26 18:41                 ` Casey Schaufler
2013-05-30  1:28             ` Eric Paris
2013-05-30  3:05               ` Linus Torvalds
2013-05-26 12:02       ` Theodore Ts'o
2013-05-26 18:23         ` Casey Schaufler [this message]
2013-05-26 19:11           ` Theodore Ts'o
2013-05-26 19:32             ` Linus Torvalds
2013-05-28 16:26               ` Casey Schaufler
2013-05-29  0:17         ` Valdis.Kletnieks
2013-05-26  5:03     ` James Morris

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=51A25305.90101@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=eparis@redhat.com \
    --cc=james.l.morris@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --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: 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