Current/Future Plans to Support Stacking LSM Modules

Current/Future Plans to Support Stacking LSM Modules

[Tom Fortmann]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Are their any current or future plans to support stacking additional
security modules on the LSM interface?

 

Alternatively, are there any current or future plans to allow the SELinux
framework to be expanded with third party loadable modules?

 

We are working on some enhanced security solutions that require access to
the LSM interface, but we do not want to preclude the use of SELinux by our
customers.

 

Thank you in advance for your insight into these plans.

 

Tom Fortmann

Xcape Solutions, Inc.


[-- Attachment #2: Type: text/html, Size: 2457 bytes --]

Re: Current/Future Plans to Support Stacking LSM Modules

[Stephen Smalley]

On Tue, 2007-01-16 at 12:08 -0600, Tom Fortmann wrote:
> Are their any current or future plans to support stacking additional
> security modules on the LSM interface?

That's more of a question for linux-security-module rather than this
list.  We don't have any plans to introduce such support to LSM, as we
think it is a bad idea.  Last time it came up (at 2006 kernel summit),
that seemed to be the consensus view.

> Alternatively, are there any current or future plans to allow the
> SELinux framework to be expanded with third party loadable modules?

Not loadable modules, no.  But adding further security models to the
SELinux security server or extending the ones that are already there is
certainly open to discussion, if a case can be made for it.  However,
you may find that the existing models are sufficient to support the
right set of goals at the kernel level, and then you can build
additional infrastructure in userspace without needing to modify the
kernel's model.

> We are working on some enhanced security solutions that require access
> to the LSM interface, but we do not want to preclude the use of
> SELinux by our customers.

What do you need that you can't obtain from SELinux or other kernel
subsystems (e.g. audit) today?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Casey Schaufler]

--- Tom Fortmann <tfortmann@xcapesolutions.net> wrote:

> Are their any current or future plans to support
> stacking additional
> security modules on the LSM interface?

It has certainly been considered from
time to time. David Wheeler's early work
came pretty close.

> Alternatively, are there any current or future plans
> to allow the SELinux
> framework to be expanded with third party loadable
> modules?

SELinux does currently, although somewhat
begrudgingly, allow limited stacking in
support of a particular set of modules. 

It wasn't but a year ago that the SELinux
community was arguing that LSM ought to be
dispensed with, as they argued that:
  - No one else was using LSM
  - SELinux does everything that a rational
    being might want done anyway.

> We are working on some enhanced security solutions
> that require access to
> the LSM interface, but we do not want to preclude
> the use of SELinux by our
> customers.

You might take this onto the LSM list (I've
added it to the CC here) as there are a (very)
few people who follow LSM that do not subscribe
here.

Just out of curiosity, what's your module
going to do?


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Stephen Smalley]

On Thu, 2007-01-18 at 22:08 +1100, Crispin Cowan wrote:
> Casey Schaufler wrote:
> > --- Tom Fortmann <tfortmann@xcapesolutions.net> wrote:
> >   
> >> Are their any current or future plans to support
> >> stacking additional
> >> security modules on the LSM interface?
> >>     
> > It has certainly been considered from
> > time to time. David Wheeler's early work
> > came pretty close.
> >   
> There is a module waiting in the wings called Stacker
> <http://sourceforge.net/projects/lsm-stacker> that is designed to
> automatically stack multiple modules. Considerable design,
> implementation, and measurement has gone into Stacker. The main thing
> stalling the upstreaming of Stacker is for some modules other than
> SELinux to be accepted upstream. With the number of modules vying for
> that, it seems just a matter of time.

Except that at the last kernel summit, the topic came up during the LSM
panel, and everyone on the panel, including the AppArmor person, agreed
that stacking wasn't necessary or desirable.
 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Stephen Smalley]

On Fri, 2007-01-19 at 00:29 +1100, Crispin Cowan wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-01-18 at 22:08 +1100, Crispin Cowan wrote:
> >   
> >> There is a module waiting in the wings called Stacker
> >> <http://sourceforge.net/projects/lsm-stacker> that is designed to
> >> automatically stack multiple modules. Considerable design,
> >> implementation, and measurement has gone into Stacker. The main thing
> >> stalling the upstreaming of Stacker is for some modules other than
> >> SELinux to be accepted upstream. With the number of modules vying for
> >> that, it seems just a matter of time.
> >>     
> > Except that at the last kernel summit, the topic came up during the LSM
> > panel, and everyone on the panel, including the AppArmor person, agreed
> > that stacking wasn't necessary or desirable.
> >   
> Hmmm, that is surprising. I have to assume you meant " ... at this
> time."

That wasn't my impression - the question raised was along the lines of
"even if we can't settle the LSM issue once for all, can we at least
settle the issue of LSM stacking."  And the consensus view seemed to be
that generic stacking of security modules is not the way to go; security
modules need to be aware of the composition and its implications, as in
the existing manual stacking of SELinux with capabilities or AppArmor
with capabilities.

>  With relatively few modules around, a full blown stacking
> architecture is excessive. But as the number and variety of modules
> grows, the need for Stacker will increase. That stacking was given such
> limited support in the LSM design was precisely because I saw it as a
> "later" kind of thing, and we could avoid the initial complexity.

I only know of one other security module that is under consideration for
upstream, slim.

> Clearly stacking AppArmor and SELinux together is pointless, but if
> Stacker was upstream, then perhaps the LSPP work going on could be done
> as a pure LSM module that can stack with something else, so it could
> compose with SELinux, AppArmor, LIDS, etc. instead of just with SELinux.
> By now, of course, all sorts of SELinux-specific assumptions are built
> into the work, but I doubt that they are fundamental.

To the contrary, the LSPP work significantly leverages the work already
done to integrate SELinux and makes use of the SELinux interfaces for
applications.  It also leverages SELinux TE to address aspects such as
MLS overrides.  By doing it within the context of SELinux, it gained the
benefit of a unified security model and interface.  Which one doesn't
get from LSM.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:


> To the contrary, the LSPP work significantly
> leverages the work already
> done to integrate SELinux and makes use of the
> SELinux interfaces for
> applications.  It also leverages SELinux TE to
> address aspects such as
> MLS overrides.  By doing it within the context of
> SELinux, it gained the
> benefit of a unified security model and interface. 
> Which one doesn't get from LSM.

There are others who would argue that SELinux
has abandoned the Linux privilege model and
thus disrupted the unity of the existing
security model.

I don't understand why the SELinux crew seems
so intent on making it difficult to implement
alternatives. Last year it was "let's ditch LSM".
Now it's "Everyone hates stacking". Give it a
rest already.


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Karl MacMillan]

Casey Schaufler wrote:
> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> 
>> To the contrary, the LSPP work significantly
>> leverages the work already
>> done to integrate SELinux and makes use of the
>> SELinux interfaces for
>> applications.  It also leverages SELinux TE to
>> address aspects such as
>> MLS overrides.  By doing it within the context of
>> SELinux, it gained the
>> benefit of a unified security model and interface. 
>> Which one doesn't get from LSM.
> 
> There are others who would argue that SELinux
> has abandoned the Linux privilege model and
> thus disrupted the unity of the existing
> security model.
> 

No clue what this means.

> I don't understand why the SELinux crew seems
> so intent on making it difficult to implement
> alternatives. Last year it was "let's ditch LSM".
> Now it's "Everyone hates stacking". Give it a
> rest already.
> 

1) Stacking is possible now, just not arbitrary stacking by an admin.

2) Not having arbitrary stacking in no way limits alternatives. It just 
forces the use of a single alternative at a time or explicit development 
to make alternatives work together.

3) The objections, if you read them, are about whether the correctness 
of arbitrarily stacked modules can be reasonably expected or verified. 
It is not an effort to limit alternatives.

There are real disagreements here, but please stop overstating the 
differences and misconstruing (willfully?) peoples positions.

Karl




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Fri, 2007-01-19 at 00:29 +1100, Crispin Cowan wrote:
> > Stephen Smalley wrote:
> > > On Thu, 2007-01-18 at 22:08 +1100, Crispin Cowan wrote:
> > >
> > >> There is a module waiting in the wings called Stacker
> > >> <http://sourceforge.net/projects/lsm-stacker> that is designed to
> > >> automatically stack multiple modules. Considerable design,
> > >> implementation, and measurement has gone into Stacker. The main thing
> > >> stalling the upstreaming of Stacker is for some modules other than
> > >> SELinux to be accepted upstream. With the number of modules vying for
> > >> that, it seems just a matter of time.
> > >>
> > > Except that at the last kernel summit, the topic came up during the LSM
> > > panel, and everyone on the panel, including the AppArmor person, agreed
> > > that stacking wasn't necessary or desirable.
> > >
> > Hmmm, that is surprising. I have to assume you meant " ... at this
> > time."
> 
> That wasn't my impression - the question raised was along the lines of
> "even if we can't settle the LSM issue once for all, can we at least
> settle the issue of LSM stacking."  And the consensus view seemed to be
> that generic stacking of security modules is not the way to go; security

Yup, that was the conclusion at kernel summit.

> modules need to be aware of the composition and its implications, as in
> the existing manual stacking of SELinux with capabilities or AppArmor
> with capabilities.

That's always been one of the cons to stacker, but I think at kernel
summit the main reason for the decision was simply the lack of users.
Now it's possible that if we end up with legitimate users, the issue
will be revisited, but even I understand the meaning of the word
'futility' and have stopped maintaining stacker.

> >  With relatively few modules around, a full blown stacking
> > architecture is excessive. But as the number and variety of modules
> > grows, the need for Stacker will increase. That stacking was given such
> > limited support in the LSM design was precisely because I saw it as a
> > "later" kind of thing, and we could avoid the initial complexity.
> 
> I only know of one other security module that is under consideration for
> upstream, slim.
> 
> > Clearly stacking AppArmor and SELinux together is pointless, but if
> > Stacker was upstream, then perhaps the LSPP work going on could be done
> > as a pure LSM module that can stack with something else, so it could
> > compose with SELinux, AppArmor, LIDS, etc. instead of just with SELinux.
> > By now, of course, all sorts of SELinux-specific assumptions are built
> > into the work, but I doubt that they are fundamental.
> 
> To the contrary, the LSPP work significantly leverages the work already
> done to integrate SELinux and makes use of the SELinux interfaces for
> applications.  It also leverages SELinux TE to address aspects such as
> MLS overrides.  By doing it within the context of SELinux, it gained the
> benefit of a unified security model and interface.  Which one doesn't
> get from LSM.

Yup, and in addition to pre-existing userspace and kernel pieces, the
selinux community was very helpful in development during the lspp work.

-serge

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Casey Schaufler]

--- Karl MacMillan <kmacmill@redhat.com> wrote:

> > There are others who would argue that SELinux
> > has abandoned the Linux privilege model and
> > thus disrupted the unity of the existing
> > security model.
> > 
> 
> No clue what this means.

Pre-SE Linux has a rational and well
established security model that includes
DAC and Privilege. The capability scheme
is designed to fit that model, adding the
logical extention from the POSIX statements
of "appropruate privilege" to defining what
those privileges would be.

SELinux does not use capabilities to identify
where "policy" is excepted, rather it defines
policy in such a way as to make the notion of
exception unnecessary. Many people think this
is good. I personally like the traditional
scheme, and would be happier with SELinux if
it held to it.

> > I don't understand why the SELinux crew seems
> > so intent on making it difficult to implement
> > alternatives. Last year it was "let's ditch LSM".
> > Now it's "Everyone hates stacking". Give it a
> > rest already.
> > 
> 
> 1) Stacking is possible now, just not arbitrary
> stacking by an admin.

True enough, although I have to say that it
isn't a pleasant exercise.

> 2) Not having arbitrary stacking in no way limits
> alternatives. It just 
> forces the use of a single alternative at a time or
> explicit development 
> to make alternatives work together.

Funny thing is that I would agree with you 100%
if LSM implemented authoritative hooks. Since
LSM implements a scheme that is supposed to
provide strictly for additional restrictions
it should be simple to stack modules safely.
 
> 3) The objections, if you read them, are about
> whether the correctness 
> of arbitrarily stacked modules can be reasonably
> expected or verified. 
> It is not an effort to limit alternatives.

Restictive LSM modules ought to be completely
stackable if they are in fact strictly
restrictive. That there are issues says that
the scheme may not be being used correctly.
I honestly don't know if that's worth the
trouble of fixing.

> There are real disagreements here, but please stop
> overstating the 
> differences and misconstruing (willfully?) peoples
> positions.

SELinux is a Good Thing for any number of
reasons. There are also other schemes that
have merit. Just as I encouraged the NSA to
adopt Linux and do their own security work
back in the late 20th century I hope to
encourage newcomers to LSM to follow through
with their ideas and come up with the next
great thing. Assimilation into SELinux can
come later if it's of value. Maybe you can
do a bunch of this stuff using SELinux as
a framework instead of LSM, but I think
that if someone wants to use LSM as a base
that is their call, and I personally would
like to see what they do because I don't
believe for a minute that the "problem"
of system security is solved.


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Serge E. Hallyn]

Quoting Casey Schaufler (casey@schaufler-ca.com):
> 
> --- Karl MacMillan <kmacmill@redhat.com> wrote:
> 
> > > There are others who would argue that SELinux
> > > has abandoned the Linux privilege model and
> > > thus disrupted the unity of the existing
> > > security model.
> > >
> >
> > No clue what this means.
> 
> Pre-SE Linux has a rational and well
> established security model that includes
> DAC and Privilege. The capability scheme
> is designed to fit that model, adding the
> logical extention from the POSIX statements
> of "appropruate privilege" to defining what
> those privileges would be.
> 
> SELinux does not use capabilities to identify
> where "policy" is excepted, rather it defines
> policy in such a way as to make the notion of
> exception unnecessary. Many people think this
> is good. I personally like the traditional
> scheme, and would be happier with SELinux if
> it held to it.
> 
> > > I don't understand why the SELinux crew seems
> > > so intent on making it difficult to implement
> > > alternatives. Last year it was "let's ditch LSM".
> > > Now it's "Everyone hates stacking". Give it a
> > > rest already.
> > >
> >
> > 1) Stacking is possible now, just not arbitrary
> > stacking by an admin.
> 
> True enough, although I have to say that it
> isn't a pleasant exercise.
> 
> > 2) Not having arbitrary stacking in no way limits
> > alternatives. It just
> > forces the use of a single alternative at a time or
> > explicit development
> > to make alternatives work together.
> 
> Funny thing is that I would agree with you 100%
> if LSM implemented authoritative hooks. Since
> LSM implements a scheme that is supposed to
> provide strictly for additional restrictions
> it should be simple to stack modules safely.

An example where that is not the case is if LSM 2 needs to label
a file as 'toptopsecret noone may touch this', but LSM 1 has
marked claimed that the user may not write an xattr.  So now
the user's info can be leaked.

-serge

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Casey Schaufler]

--- "Serge E. Hallyn" <serue@us.ibm.com> wrote:


> > Funny thing is that I would agree with you 100%
> > if LSM implemented authoritative hooks. Since
> > LSM implements a scheme that is supposed to
> > provide strictly for additional restrictions
> > it should be simple to stack modules safely.
> 
> An example where that is not the case is if LSM 2
> needs to label
> a file as 'toptopsecret noone may touch this', but
> LSM 1 has
> marked claimed that the user may not write an xattr.
>  So now
> the user's info can be leaked.

This is only an issue if LSM 2 puts "toptop..."
data into the file prior to setting the label
on the file, which I would argue ought not
happen. If you're refering to the case where
someone discovers toptop... data in an existing
'sure go ahead everyone read this' file and
they want to relabel it I say that the described
behavior is, however unfortunate, correct. There
have been sucessful MLS systems on which users
were not allowed to relabel files.

If an LSM is correct within its own rules,
such as the MLS reality that the container
has to be labeled before the data goes in,
and that the creation would fail if it
couldn't live up to its rules, the situation
described will not be a security problem.
It will be a operational problem, and the
admin who decided that she wanted both
mechanisms may have a tough choice, just
as she does when she puts too many layers
of spam filtering in place and nothing from
lkml gets through anymore.

Reminds me of changing planes at Heathrow,
where half the people had too much luggage
to go through security, but had already
gone through once at the previous airport.


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Stephen Smalley]

On Thu, 2007-01-18 at 10:12 -0800, Casey Schaufler wrote:
> --- Karl MacMillan <kmacmill@redhat.com> wrote:
> 
> > > There are others who would argue that SELinux
> > > has abandoned the Linux privilege model and
> > > thus disrupted the unity of the existing
> > > security model.
> > > 
> > 
> > No clue what this means.
> 
> Pre-SE Linux has a rational and well
> established security model that includes
> DAC and Privilege. The capability scheme
> is designed to fit that model, adding the
> logical extention from the POSIX statements
> of "appropruate privilege" to defining what
> those privileges would be.
> 
> SELinux does not use capabilities to identify
> where "policy" is excepted, rather it defines
> policy in such a way as to make the notion of
> exception unnecessary. Many people think this
> is good. I personally like the traditional
> scheme, and would be happier with SELinux if
> it held to it.

If the argument is that we should favor the traditional over the good,
then I think you've lost your case.  Besides, Type Enforcement has quite
a bit of history behind it, coming from at least the LOCK work in the
early 80s, with the underlying origins traceable to the Lampson ('71)
and Linden ('76) papers, so let's compare traditions, shall we?

> Restictive LSM modules ought to be completely
> stackable if they are in fact strictly
> restrictive.

Strictly restrictive relative to base Linux DAC, but not necessarily to
one another.  See the issues noted in the next-to-last para of:
http://www.nsa.gov/selinux/papers/module/x341.html

Also, getting the stacker module correct even for the "simple"
combination of capabilities and SELinux was surprisingly difficult - see
the lsm list archives for the history of that.  Serge made a valiant
effort of fixing each issue as I discovered them, but the history shows
that it isn't as trivial as one might think.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:



> If the argument is that we should favor the
> traditional over the good,
> then I think you've lost your case.

Ah, but you see, the fact that something
is traditional does not necessarily make
it bad! Call me an old fuddy duddy, but I
actually prefer MAC+Cap to TE. I
understand that many people prefer TE and
that's OK with me.

> Besides, Type Enforcement has quite
> a bit of history behind it, coming from
> at least the LOCK work in the
> early 80s, with the underlying origins traceable to
> the Lampson ('71)
> and Linden ('76) papers, so let's compare
> traditions, shall we?

If you like, although we really should have
a couple beers and an audience for that.

> > Restictive LSM modules ought to be completely
> > stackable if they are in fact strictly
> > restrictive.
> 
> Strictly restrictive relative to base Linux DAC, but
> not necessarily to
> one another.  See the issues noted in the
> next-to-last para of:
> http://www.nsa.gov/selinux/papers/module/x341.html

Yup, the shared blob is the trick to stacking.

> Also, getting the stacker module correct even for
> the "simple"
> combination of capabilities and SELinux was
> surprisingly difficult - see
> the lsm list archives for the history of that. 
> Serge made a valiant
> effort of fixing each issue as I discovered them,
> but the history shows
> that it isn't as trivial as one might think.

It's true that the Capabilities stacking in
SELinux points out some important issues.
Given the mixture of privilege models its
tough to see a better approach.


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Russell Coker]

On Friday 19 January 2007 08:32, Casey Schaufler <casey@schaufler-ca.com> 
wrote:
> > and Linden ('76) papers, so let's compare
> > traditions, shall we?
>
> If you like, although we really should have
> a couple beers and an audience for that.

Casey vs sds at the next SE Linux Symposium dinner?  Should be more exciting 
than Casey vs Joshua at the first SE Linux Symposium dinner!

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Current/Future Plans to Support Stacking LSM Modules

[Paul Moore]

On Tuesday, January 23 2007 6:24 pm, Russell Coker wrote:
> Casey vs sds at the next SE Linux Symposium dinner?  Should be more
> exciting than Casey vs Joshua at the first SE Linux Symposium dinner!

Where is Don King when you need him ;)

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.