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
>
next prev parent 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