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 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.