LSM conversion to static interface

LSM conversion to static interface

[Thomas Fricaccia]

Like many of us who earn a good living with Linux (for over a decade now) and follow the kernel developer discussions with waxing and waning interest depending on topic, I noticed James Morris' proposal to eliminate the LSM in favor of ordaining SELinux as THE security framework forever and amen, followed by the definitive decision by Linus that LSM would remain.

Well, good, I thought.  Linux should continue to represent freedom for anyone to use basic technology in any way he sees fit.  I turned my attention back to my prosaic day-to-day concerns, thinking that the choice of which security framework to deploy would remain in the hands of the user, regardless of which distributor he chose.

But then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks.  Yikes!  Since then, I've been following the rush to put SMACK, TOMOYO and AppArmor "in-tree". 

Since I know that the people behind these security frameworks are serious and worthy folk of general good repute, I've reluctantly come to the tentative conclusion that the fix is in.  There seem to be powers at work that want LSM closed, and they don't want much public discussion about it.

I think this is bad technology.  I've done due diligence by reviewing the LKML discussion behind closing LSM (and there isn't much).  The technical arguments seem to be (1) some people use the LSM interface for "non-security" purposes, which is frowned upon, (2) it's difficult to properly secure a system with an open-ended interface like LSM, and (3) my security framework should be all any fair-minded person would ever want, so we won't let you use something else.

Exactly. 

Well, any system that permits loading code into "ring 0" can't be made completely secure, so argument 2 reduces to argument 3, which is transparently self-serving (and invalid).

I submit for discussion the idea that a free and open operating system should preserve as much freedom for the end user as possible.  To this end, the kernel should cleanly permit and support the deployment of ANY security framework the end user desires, whether "in-tree" or "out-of-tree".  I agree that any out-of-tree LSM module should be licensed under the GPL (if for no other reason than many current commercial support contracts require non-tainted kernels).

But restricting security frameworks to "in-tree" only is bad technology.

"Freedom" includes the power to do bad things to yourself by, for example, making poor choices in security frameworks.  This possible and permitted end result shouldn't be the concern of kernel developers.  Making configuration and installation of user-chosen frameworks as clean and safe as possible should be.

In my opinion.

Though not sure why, I expect to be scorched by this.  Try not to patronize or condescend.  Give me technical arguments backed by real data.  Show me why a home user or 10,000 node commercial enterprise shouldn't be able to choose what he wants for security without having to jump through your hoops.  Show me why you shouldn't make his use of technology up to him, and as safely and conveniently as you can contrive.

Thanks for a really great operating system, I really love it,

 Tommy F.

Re: LSM conversion to static interface

[Casey Schaufler]

--- Thomas Fricaccia <thomas_fricacci@yahoo.com> wrote:

> ...
> 
> But then I noticed that, while the LSM would remain in existence, it was
> being closed to out-of-tree security frameworks.  Yikes!  Since then, I've
> been following the rush to put SMACK, TOMOYO and AppArmor "in-tree". 
> 
> Since I know that the people behind these security frameworks are serious and
> worthy folk of general good repute,

I make no claims to worthyness, strongly deny being serious,
and challenge you to demonstrate my good repute.

> I've reluctantly come to the tentative
> conclusion that the fix is in. 

Nope. I remain carefully neutral regarding the static/dynamic LSM
issue. I was involved with the LSM when SELinux was still known as
the Flask port and my development group proposed the first
implementation, featuring authoritative hooks. Believe me, this
is nothing compared to what we went through as a community then.

> There seem to be powers at work that want LSM
> closed, and they don't want much public discussion about it.

The thing that killed authoritative hooks and that could kill LSM
is the notion (which I refuse to take a side on) that out of tree
facilities can use it to avoid the stated intent of the GPL.

> I think this is bad technology.  I've done due diligence by reviewing the
> LKML discussion behind closing LSM (and there isn't much).

I think the primary parties have gotten to the point where they
just call out the arguments by number we've been over them so many
times.

> The technical
> arguments seem to be (1) some people use the LSM interface for "non-security"
> purposes, which is frowned upon,

It goes way beyond frowned upon. The first use proposed for LSM was
an audit implementation and that was throughly shredded. Additional
restrictions on accesses only.

> (2) it's difficult to properly secure a
> system with an open-ended interface like LSM, and 

Which is pure feldercarb.

> (3) my security framework
> should be all any fair-minded person would ever want, so we won't let you use
> something else.

That argument makes Linus mad.

> Exactly. 
> 
> Well, any system that permits loading code into "ring 0" can't be made
> completely secure, so argument 2 reduces to argument 3, which is
> transparently self-serving (and invalid).
> 
> I submit for discussion the idea that a free and open operating system should
> preserve as much freedom for the end user as possible.  To this end, the
> kernel should cleanly permit and support the deployment of ANY security
> framework the end user desires, whether "in-tree" or "out-of-tree".  I agree
> that any out-of-tree LSM module should be licensed under the GPL (if for no
> other reason than many current commercial support contracts require
> non-tainted kernels).
> 
> But restricting security frameworks to "in-tree" only is bad technology.
> 
> "Freedom" includes the power to do bad things to yourself by, for example,
> making poor choices in security frameworks.  This possible and permitted end
> result shouldn't be the concern of kernel developers.  Making configuration
> and installation of user-chosen frameworks as clean and safe as possible
> should be.
> 
> In my opinion.
> 
> Though not sure why, I expect to be scorched by this.  Try not to patronize
> or condescend.  Give me technical arguments backed by real data.  Show me why
> a home user or 10,000 node commercial enterprise shouldn't be able to choose
> what he wants for security without having to jump through your hoops.  Show
> me why you shouldn't make his use of technology up to him, and as safely and
> conveniently as you can contrive.

The in-tree vs out-of-tree discussion is independent of LSM.


Casey Schaufler
casey@schaufler-ca.com

Re: LSM conversion to static interface

[Linus Torvalds]

On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
> 
> But then I noticed that, while the LSM would remain in existence, it was 
> being closed to out-of-tree security frameworks.  Yikes!  Since then, 
> I've been following the rush to put SMACK, TOMOYO and AppArmor 
> "in-tree".

Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE 
people were ok with it (AppArmor), but I'm with you - I applied it, but 
I'm also perfectly willing to unapply it if there actually are valid 
out-of-tree users that people push for not merging.

So Í don't think this is settled in any way - please keep discussing, and 
bringing it up. I'm definitely not in the camp that thinks that LSM needs 
to be "controlled", but on the other hand, I'm also not going to undo that 
commit unless there are good real arguments for undoing it (not just 
theoretical ones).

For example, I do kind of see the point that a "real" security model might 
want to be compiled-in, and not something you override from a module. Of 
course, I'm personally trying to not use any modules at all, so I'm just 
odd and contrary, so whatever..

Real usage scenarios with LSM modules, please speak up!

		Linus

Re: LSM conversion to static interface

[Linus Torvalds]

On Wed, 17 Oct 2007, Casey Schaufler wrote:
> 
> The in-tree vs out-of-tree discussion is independent of LSM.

Indeed. I think there is certainly likely to be some small overlap, but I 
*think* they are largely independent issues - "do we want choice in 
securitu models" (a very emphatic YES as far as I'm concerned) vs "do we 
necessarily want to do them as out-of-tree modules" (I'd like people who 
actually *do* things like that to educate us on why and what they are 
doing).

Hmm?

		Linus

Re: LSM conversion to static interface

[Arjan van de Ven]

On Wed, 17 Oct 2007 18:34:16 -0700
"Thomas Fricaccia" <thomas_fricacci@yahoo.com> wrote:
> 
> But then I noticed that, while the LSM would remain in existence, it
> was being closed to out-of-tree security frameworks.  Yikes!  Since
> then, I've been following the rush to put SMACK, TOMOYO and AppArmor
> "in-tree". 

I think your statement isn't quite correct: it's not closed to out of
tree security frameworks; it's no longer possible to do MODULES. You
can easily patch any of the ones you mention in (and in fact, this is
how distros that use apparmor will use it anyway). You are totally free
to compile whatever security module you want into your kernel and use
it... I would actually highly encourage that; the freedom to do that is
what Linux is about.

The problem with "loadable security modules" is actually fundamental,
and afaik even the AppArmor people mostly agree with this: The security
any such system provides is generally based on being in a "Safe" state
from the start, so knowing all objects that go through the system, being
able to label them (or at least do something with them, I realize the
term "label" is maybe seen as SELinux specific, but I mean it in a
generic way; the SELinux people will tell you I'm not a fan of their
approach *at all*), check them etc etc. A loadable-module approach can't
do that, it would, at load time, have to inspect the system, make sure
no operations are in "half process" when the LSM hooks go into effect
(just think of it: if you have an operation that gets 3 LSM checks done
to it, and you load and activate your module after the first one is
done as NOP, and your code only sees the 2nd and 3rd... showing that
that gives you sane behavior.... unpleasant no matter what you do) and
on unload, undo all it's work in a semi atomic way (just try doing it
race free is already impossible).

This is the prime motivation behind the change as I understand it: It
wasn't really an option to get this correct, the distros who deploy
these frameworks tend to compile them in anyway as a result, and there
are real downsides as well (see below).

> technical arguments seem to be (1) some people use the LSM interface
> for "non-security" purposes, which is frowned upon, (2) it's
> difficult to properly secure a system with an open-ended interface
> like LSM, and (3) my security framework should be all any fair-minded
> person would ever want, so we won't let you use something else.


you missed another one: the curent (now merged) patch allows a new
option (which is under development and will be proposed for 2.6.25): A
config option to compile the kernel such that the security framework of
your choice gets compiled as "exclusive" for your binary kernel, and
such that the code doesn't go via the LSM function pointers anymore, but
just via preprocessor rules, does direct calls instead. (And gets
patched out if you issue kernel commandline options to disable security
entirely). This takes away one of the main performance overheads of LSM
(many many function pointer calls) for those who know which LSM module
they'll be using.

That option obviously doesn't mean that you can't have multiple LSM
drivers anymore in the kernel, again it is an option that IF you know
you'll only use one, you can get rid of all the overhead of needing to
be ready to do multiple.

While this strict technically isn't in conflict with the non-modular
LSM (modular-LSM can obviously be a config option in itself as well),
it does make it a lot easier and cleaner to do things this way.

Re: LSM conversion to static interface

[Andreas Gruenbacher]

On Thursday 18 October 2007 04:18, Linus Torvalds wrote:
> On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
> > 
> > But then I noticed that, while the LSM would remain in existence, it was 
> > being closed to out-of-tree security frameworks.  Yikes!  Since then, 
> > I've been following the rush to put SMACK, TOMOYO and AppArmor 
> > "in-tree".
> 
> Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE 
> people were ok with it (AppArmor), but I'm with you - I applied it, but 
> I'm also perfectly willing to unapply it if there actually are valid 
> out-of-tree users that people push for not merging.

The patch doesn't hurt AppArmor, but it's still a step in the wrong direction.

Quoting from commit 20510f2f (Convert LSM into a static interface):
> In a nutshell, there is no safe way to unload an LSM.  The modular interface
> is thus unecessary and broken infrastructure.  It is used only by
> out-of-tree modules, which are often binary-only, illegal, abusive of the
> API and dangerous, e.g.  silently re-vectoring SELinux.

This is idiotic. Just because there is no safe way to unload SELinux

 - doesn't mean there is no safe way to unload other LSMs: if nothing
   but that, unloading is handy during development.

 - doesn't mean that module *loading* is unsafe. The patch removes module
   loading as well, which hurts more than removing module unloading.

LSM can be abused ... so what, this doesn't mean the interface is bad. Non-LSM 
loadable modules have been known to do lots of bad things, and yet nobody 
made them non-loadable either (yet).

> [...]
> For example, I do kind of see the point that a "real" security model might 
> want to be compiled-in, and not something you override from a module.

Non-trivial modules (i.e., practically everything beyond capabilities) become 
effective only after loading policy, anyway. If you can load policy, you can 
as well first load a security module without making the system insecure.

Thanks,
Andreas

Re: LSM conversion to static interface

[Linus Torvalds]

On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
> 
> Non-trivial modules (i.e., practically everything beyond capabilities) become 
> effective only after loading policy, anyway. If you can load policy, you can 
> as well first load a security module without making the system insecure.

I'd like to note that I asked people who were actually affected, and had 
examples of their real-world use to step forward and explain their use, 
and that I explicitly mentioned that this is something we can easily 
re-visit.

But I also note that you did no such thing, neither has anybody else.

The fact is, security people *are* insane. You just argue all the time, 
instead fo doing anything productive. So please don't include me in the Cc 
on your insane arguments - instead do something productive and I'm 
interested.

Ok? That was the whole point of LSM in the first place. I'm *not* 
interested in getting roped into your insane arguments. I'm interested in 
moving forward and having real examples of real use and code. Until then, 
this issue is closed. I thought I had made that clear already, but 
apparently not clear enough.

So I repeat: we can undo that commit, but I will damn well not care one 
whit about yet another pointless security model flamewar.

		Linus

Re: LSM conversion to static interface

[James Morris]

On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:

> Quoting from commit 20510f2f (Convert LSM into a static interface):
> > In a nutshell, there is no safe way to unload an LSM.  The modular interface
> > is thus unecessary and broken infrastructure.  It is used only by
> > out-of-tree modules, which are often binary-only, illegal, abusive of the
> > API and dangerous, e.g.  silently re-vectoring SELinux.
> 
> This is idiotic. Just because there is no safe way to unload SELinux
> 
>  - doesn't mean there is no safe way to unload other LSMs: if nothing
>    but that, unloading is handy during development.

Can you provide an example of a real LSM which can be safely unloaded and 
also needs to be unloaded?

Why should we maintain infrastructure and extra complexity in the kernel 
for theoretical or unknown modules ?

Linus has asked for any valid out of tree users who need a dynamic 
interface to step forward.  Where are they?

As one of the people who actually maintains LSM (rather than simply 
speculates about it), I object to maintaining infrastructure which, to the 
best of my knowledge, is only used by out of tree, binary, broken junk.

If you recall, the original motivation for this patch was when the idea 
of adding a new capability to control security model unload was raised.  

That is, new security infrastructure was being proposed merely to cater to 
some other existing unnecessary security infrastructure.  So, rather than 
doing that, I proposed removing the unnecessary infrastructure.

I agree with Linus: if you can demonstrate a valid, concrete use for 
dynamic LSMs, then the infrastructure to support them can easily be 
reinstated.

But until then, it seems both reasonable and in keeping with good kernel 
development practices, to not maintain unused infrastructure.


- James
-- 
James Morris
<jmorris@namei.org>

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 19 2007 13:40, Linus Torvalds wrote:
>On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
>> 
>> Non-trivial modules (i.e., practically everything beyond capabilities) become 
>> effective only after loading policy, anyway. If you can load policy, you can 
>> as well first load a security module without making the system insecure.
>
>I'd like to note that I asked people who were actually affected, and had 
>examples of their real-world use to step forward and explain their use, 
>and that I explicitly mentioned that this is something we can easily 
>re-visit.
>

I do have a pseudo LSM called "multiadm" at 
http://freshmeat.net/p/multiadm/ , quoting:

	The MultiAdmin security framework kernel module provides a means 
	to have multiple "root" users with unique UIDs. This bypasses 
	collation order problems with NSCD, allows you to have files 
	with unique owners, and allows you to track the quota usage for 
	every "real" user. It also implements a "sub-admin", a partially 
	restricted root user who has full read-only access to most 
	subsystems, but write rights only to a limited subset, for 
	example writing to files or killing processes only of certain 
	users.

The use case is so that profs (taking the role of sub-admins), can 
operate on student's data/processes/etc. (quite often needed), but 
without having the full root privileges.

Policy is dead simple since it is based on UIDs. The UID ranges can be 
set on module load time or during runtime (sysfs params). This LSM is 
basically grants extra rights unlike most other LSMs[1], which is why 
modprobe makes much more sense here. (It also does not have to do any 
security labelling that would require it to be loaded at boot time 
already.)

Does that sound productive?


>The fact is, security people *are* insane. You just argue all the time, 
>instead fo doing anything productive. So please don't include me in the Cc 
>on your insane arguments - instead do something productive and I'm 
>interested.

[1] SELinux: What I remember from coker.com.au's selinux test machine, 
everyone had UID 0 and instead had powers revoked.

Re: LSM conversion to static interface

[James Morris]

On Sat, 20 Oct 2007, Jan Engelhardt wrote:

> >I'd like to note that I asked people who were actually affected, and had 
> >examples of their real-world use to step forward and explain their use, 
> >and that I explicitly mentioned that this is something we can easily 
> >re-visit.
> >
> 
> I do have a pseudo LSM called "multiadm" at 
> http://freshmeat.net/p/multiadm/ , quoting:
> 

Based on Linus' criteria, this appears to be a case for reverting the 
static LSM patch.

Jan, I remember you posting this last year and IIRC, there were really 
only coding style issues to be addressed.  There were some review queries 
and suggestions (e.g. decomposing CAP_SYS_ADMIN), but no deal-breakers -- 
certainly not now that security architecture and security model objections 
are out of bounds.

So, I would suggest reposting the code for upstream inclusion, which 
would be better at least in terms of upstream maintenance, as your code 
will be visible in the tree.


- James
-- 
James Morris
<jmorris@namei.org>

Re: LSM conversion to static interface

[Adrian Bunk]

On Sun, Oct 21, 2007 at 08:57:06AM +1000, James Morris wrote:
> On Sat, 20 Oct 2007, Jan Engelhardt wrote:
> 
> > >I'd like to note that I asked people who were actually affected, and had 
> > >examples of their real-world use to step forward and explain their use, 
> > >and that I explicitly mentioned that this is something we can easily 
> > >re-visit.
> > 
> > I do have a pseudo LSM called "multiadm" at 
> > http://freshmeat.net/p/multiadm/ , quoting:
> 
> Based on Linus' criteria, this appears to be a case for reverting the 
> static LSM patch.
>...

If you take it that strictly, the in-kernel root_plug LSM could have 
been considered enough reason for reverting...

The interesting question is IMHO still:

Were Greg and Jan the only people to write such LSMs, or how many 
non-abusive users that make sense as modules do really exist after
5 years?

Either you can count such real-world users with your fingers or there's 
a reason why these modules didn't get included.

IOW:
Either the API has proven to not attract enough modular users or we are 
having a to-be-fixed problem with getting the LSMs submitted and 
included.

> - James

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: LSM conversion to static interface

[Thomas Fricaccia]

Yes, I think Crispin has succinctly summed it up:  irrevocably closing
the LSM prevents commercial customers from using security modules other
than that provided by their Linux distributor.  As Sarbanes-Oxley and
other regulatory laws require these customers to use "standard
kernels", the result is a rather dreary form of vendor lock-in, where the
security framework is coupled to the distribution.

Though it would require a somewhat undesirable complexity of CONFIG_
flags, it should be possible to construct flexibility enough for everyone
to get what he wants.  For example, it should be possible to configure
kernels with a single security framework hard-linked, AND it should
also be possible to configure kernels such that the default security
framework could be completely replaced at boot time by another, be it
out-of-tree module, or other.

I agree entirely that preserving this form of freedom for the end user
makes Linux a much stronger technology than not.  For one thing, the
consequences of closing LSM are fairly certain to irritate enterprise
commercial customers, which is probably a sign that the technology has
taken a wrong turn.

Tommy F.


Crispin Cowan <crispin@crispincowan.com> wrote:

> So the net impact of this patch is:
> 
>    * It takes a deployment practice (static compiled-in security) that
>      is arguably good in many circumstances and makes it mandatory at
>      all times.
>    * It takes a development practice that is very convenient and
>      slightly risky, and forces you into the pessimal inconvenient
>      development practice at all times.
>    * It prevents enterprise users, and in fact anyone who isn't
>      comfortable compiling their own kernel, from ever trying out any
>      security module that their distro vendor of choice did not ship.
>
> This strikes me as a rather anti-choice position to take. It says that
> because candy is bad for you, you only ever get to eat vegetables. I
> don't understand why Linux would want to do this to its users.
>
> It doesn't hurt me or AppArmor. Since AppArmor is now shipping with
> SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer
> modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise
> users. So I don't think I am being self-serving in arguing against this
> patch. I just think it is bad for Linux.
>
> Crispin
>
> -- 
> Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
>         Itanium. Vista. GPLv3. Complexity at work

Re: LSM conversion to static interface

[Greg KH]

On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
> the LSM prevents commercial customers from using security modules other
> than that provided by their Linux distributor.

Any "customer" using a security model other than provided by their Linux
distributor instantly voided all support from that distro by doing that.

So, since the support is gone, they can easily build their own kernels,
with their own LSM interfaces, and get the exact same lack of support :)

And, what are these "other LSM modules" you speak of that people rely on
to run their businesses?

> As Sarbanes-Oxley and
> other regulatory laws require these customers to use "standard
> kernels", the result is a rather dreary form of vendor lock-in, where the
> security framework is coupled to the distribution.

Wait, what?

Since when does Sarbanes-Oxley decree that a company must use a
"standard kernel"?  And just exactly what defines such "standard
kernel"?  Can you point out where in that bill it requires such a thing?

Totally confused,

greg k-h

Re: LSM conversion to static interface

[Alan Cox]

On Sun, 21 Oct 2007 19:24:42 -0700
"Thomas Fricaccia" <thomas_fricacci@yahoo.com> wrote:

> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
> the LSM prevents commercial customers from using security modules other
> than that provided by their Linux distributor.  As Sarbanes-Oxley and
> other regulatory laws require these customers to use "standard
> kernels", the result is a rather dreary form of vendor lock-in, where the
> security framework is coupled to the distribution.

Crispin at least is providing genuine discussion points. Sarbox has
nothing to say on "using vendor linux kernels".

Re: LSM conversion to static interface

[Crispin Cowan]

Alan Cox wrote:
> On Sun, 21 Oct 2007 19:24:42 -0700
> "Thomas Fricaccia" <thomas_fricacci@yahoo.com> wrote
>> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
>> the LSM prevents commercial customers from using security modules other
>> than that provided by their Linux distributor.  As Sarbanes-Oxley and
>> other regulatory laws require these customers to use "standard
>> kernels", the result is a rather dreary form of vendor lock-in, where the
>> security framework is coupled to the distribution.
>>     
> Crispin at least is providing genuine discussion points. Sarbox has
> nothing to say on "using vendor linux kernels".
>   
I agree that SarBox is not really the issue here. Partially related is
enterprise rules about what kernels one is allowed to load. More
generally, this change forces users who want to use a different LSM than
their vendor provides to recompile their kernel, where they did not have
to recompile before. It forces LSM module developers who want to modify
their LSM to reboot, where they didn't necessarily have to reboot before.

That is not a catastrophe, it is just tedious. It does not kill baby
seals, and it does not make Linux utterly useless. OTOH, I think it is
strictly negative: it takes away user choice in 2 dimensions, and adds
zero value. So apply it if you must to bake the kernel developer's lives
easier, but it really is a net loss in Linux kernel capability.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
	       Itanium. Vista. GPLv3. Complexity at work

Re: LSM conversion to static interface

[Alan Cox]

> > Crispin at least is providing genuine discussion points. Sarbox has
> > nothing to say on "using vendor linux kernels".
> >   
> I agree that SarBox is not really the issue here. Partially related is
> enterprise rules about what kernels one is allowed to load. More
> generally, this change forces users who want to use a different LSM than
> their vendor provides to recompile their kernel, where they did not have
> to recompile before. It forces LSM module developers who want to modify
> their LSM to reboot, where they didn't necessarily have to reboot before.

The moment they load a module from a third party they usually hit support
issues, unless there is some kind of arrangement between the parties.

> 
> That is not a catastrophe, it is just tedious. It does not kill baby
> seals, and it does not make Linux utterly useless. OTOH, I think it is
> strictly negative: it takes away user choice in 2 dimensions, and adds
> zero value. So apply it if you must to bake the kernel developer's lives
> easier, but it really is a net loss in Linux kernel capability.

Frankly I don't care about apparmor, I don't see it as a serious project.
Smack is kind of neat but looks like a nicer way to specify selinux rules.

What I do care about is that at some point something is going to appear
which is based on all the same good practice and experience and forty
years of research that leads towards SELinux, and which is much better. At
that point there will be a changeover phase and the LSM is exactly what
is needed for this.

The fact it allows people to play with toy security systems, propose new
ones like SMACK, and do research and PhD work on Linux into security is a
convenient and very good side effect.

For that reason I think keeping LSM is the right thing to do.

Alan

Re: LSM conversion to static interface

[Greg KH]

On Mon, Oct 22, 2007 at 05:50:43PM +0100, Alan Cox wrote:
> 
> For that reason I think keeping LSM is the right thing to do.

Wait, we aren't talking about dropping LSM at all, just the "LSM is a
module" option.  That's it.  And by making LSM not a module, we can then
go on to fix some of the reported speed issues that are present with the
LSM option enabled right now.

thanks,

greg k-h

Re: LSM conversion to static interface

[Thomas Fricaccia]

Some well-respected contributors have taken exception my amplification
of Crispin Cowan's point about the patch that closes LSM.

Crispin Cowan <crispin@crispincowan.com> wrote:
>     * It prevents enterprise users, and in fact anyone who isn't
>       comfortable compiling their own kernel, from ever trying out any
>       security module that their distro vendor of choice did not ship.

I extended this point by observing that regulatory laws make it difficult
for enterprise customers to compile their own kernels, mentioning one
of the more invasive statutes, Sarbanes-Oxley.

In reply, "Alan Cox" <alan@lxorguk.ukuu.org.uk> writes:
> Crispin at least is providing genuine discussion points. Sarbox has
> nothing to say on "using vendor linux kernels".

And just previously, "Greg KH" <greg@kroah.com> had written:
> Since when does Sarbanes-Oxley decree that a company must use a
> "standard kernel"?  And just exactly what defines such "standard
> kernel"?  Can you point out where in that bill it requires such a
> thing?

I was actually talking about the *effects* of regulatory law, rather
than the wording in the text of the statutes.  The misunderstanding
could be partially my fault, as my exact words were 

   As Sarbanes-Oxley and other regulatory laws require these
   customers to use "standard kernels" ....

which may not have been as unambiguously clear as I intended.

But as long as we're here, let me elaborate on the point I tried to make.

SOX and other laws require enterprise customers to keep specified
controls on their internal processing procedures, and keep documentation
that can be audited to prove compliance.  The auditing requirements
are extensive and detailed, and certainly include the kernel of an
operating system used to process business and/or financial transactions.

It is within this framework that enterprise customers conclude something
like (and this is vernacular, not the language within the statutes) "if
we use any kernel other than that supplied by our distributor, the
SOX auditing paperwork will be a nightmare."  (I've actually heard
statements similar to this, and so believe that it is an accurate
portrayal of the perception of the effects of regulatory law.  I'm not
a lawyer.)

As I said at the beginning, I meant to amplify Crispin's observation
that enterprise customers are reluctant to compile their own kernels
with the additional observation that the complexities of regulatory
law create obstacles that are significant contributors to that reluctance.

I'll not belabor the unfortunate non sequitur further.  You can find
plenty of documentation of auditing requirements with by Googling
combinations of "Sarbanes-Oxley," "operating system integrity", etc.
This is a big-business topic of wide concern.

 =========

So where were we before that detour?  Oh yes, 

The point of contention:  closing LSM significantly reduces the freedom
of an important class of Linux users, the commercial enterprises, to
use whatever security framework they desire.  Greg and Alan didn't
address this, and neither has anyone else.  Crispin's concluding remark
on the patch closing LSM to modules has also not been addressed:

> So I don't think I am being self-serving in arguing against this
> patch. I just think it is bad for Linux.

Yes.  Why indeed should Linux, justly famous for being configurable
to many disparate purposes, close down an important subsystem so that
only a few types of security frameworks are possible?

Why can't a CONFIG_ system be developed that can give everyone pretty
much what he wants?  It should be possible to develop a system
permitting much flexibility wrt security frameworks:
 1.  a kernel configured with statically-linked hooks into exactly
      one framework.
                     --- OR ---
 2.  a kernel configured with an in-tree framework, but which uses
      an LSM "security_operations" table.  (This is what we pretty much
      have in 2.6.23).  In addition, a new boot parameter could let the
      end user name the framework to use, which would completely
      replace the in-tree default framework at boot time.


To possibly save bandwidth, I'll also respond to another of Greg's points:

"Greg KH" <greg@kroah.com> wrote:
> Any "customer" using a security model other than provided by their Linux
> distributor instantly voided all support from that distro by doing that.

This isn't necessarily true.  In fact, I don't think it's even _remotely_
likely to be typical.

Security is big business, as is compliance with regulatory law.  Large
enterprise customers are NOT going to either void their system support
contracts, or place themselves in jeopardy of failing a SOX audit.
Much more likely would be negotiated collaboration between some Linux
distributors and security software firms that will permit enterprise
customers to purchase, in a bundle, the security software products
they require, along with the documentation needed to prove compliance
with regulatory law.

At least, this seems to be what the market demands, or is beginning to
demand.  Will there be a supply?  Probably, as there is money ready to buy
it.  Can closure of the LSM stop it?  Probably not, but I think that closing
LSM to out-of-tree security modules substantially reduces the viability
of Linux technology, as it fails to address the the needs of an important
class of Linux user, the commercial enterprises.  As I said previously,
I think it will irritate them quite a lot.

Is this really a good idea?  Why is it a good idea to strip important
freedoms from _any_ end user?  Much less a whole class of commercially
important end users?

Furthermore, I don't think it's **necessary** to do an absolute closure in
order to meet the stringent needs of those who demand a single, hard-wired
security framework, such as has been proposed by James Morris.  The KBuild
system seems aptly suited to address the different needs of different users.

 ==========

This just in.  On the issue of making LSM much less available (please
forgive me if I've inaccurately summarized), Crispin just now wrote:

> That is not a catastrophe, it is just tedious. It does not kill baby
> seals, and it does not make Linux utterly useless. OTOH, I think it is
> strictly negative: it takes away user choice in 2 dimensions, and adds
> zero value. So apply it if you must to bake the kernel developer's lives
> easier, but it really is a net loss in Linux kernel capability.

I think that's a pretty good formulation of my points:  user choice is
taken away, leaving a net loss in the capability of Linux, and that
it's not at all necessary.

In the same note, he agreed with Alan that "SarBox is not really the issue
here."  Well, I'm pretty certain that regulatory law strongly shapes
market forces and enterprise needs.  In particular, I've heard several
times that enterprises users  really want to just BUY all their security
products, and that these products must be accompanied by documentation for
any audits.  So, I'm pretty sure that if it is "not ... the issue", it
strongly influences the issue.

Thanks for your consideration,

Tommy F.

Re: LSM conversion to static interface

[Alan Cox]

> The point of contention:  closing LSM significantly reduces the freedom
> of an important class of Linux users, the commercial enterprises, to
> use whatever security framework they desire.  Greg and Alan didn't

No it doesn't. Strange interpretations of peculiar US laws may be doing
that. Thats [with Linux community hat on] _not_our_problem_.

> Why can't a CONFIG_ system be developed that can give everyone pretty
> much what he wants?  It should be possible to develop a system
> permitting much flexibility wrt security frameworks:
>  1.  a kernel configured with statically-linked hooks into exactly
>       one framework.
>                      --- OR ---
>  2.  a kernel configured with an in-tree framework, but which uses
>       an LSM "security_operations" table.  (This is what we pretty much
>       have in 2.6.23).  In addition, a new boot parameter could let the
>       end user name the framework to use, which would completely
>       replace the in-tree default framework at boot time.

Send patches.

> In the same note, he agreed with Alan that "SarBox is not really the issue
> here."  Well, I'm pretty certain that regulatory law strongly shapes
> market forces and enterprise needs.  In particular, I've heard several
> times that enterprises users  really want to just BUY all their security
> products, and that these products must be accompanied by documentation for
> any audits.  So, I'm pretty sure that if it is "not ... the issue", it
> strongly influences the issue.

Corporations practice "liability dumping" so that would be expected. They
want to dumb liability onto their suppliers, their customers and anyone
else they can find. Its the logical commercial practice faced by any
rational body evolving in the US marketplace.

But thats still their issue, no the community's issue. 

Alan

Re: LSM conversion to static interface

[Greg KH]

On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote:
> To possibly save bandwidth, I'll also respond to another of Greg's points:
> 
> "Greg KH" <greg@kroah.com> wrote:
> > Any "customer" using a security model other than provided by their Linux
> > distributor instantly voided all support from that distro by doing that.
> 
> This isn't necessarily true.  In fact, I don't think it's even _remotely_
> likely to be typical.

But that is completly true _today_ and is the way that the "enterprise"
distros work.  Do you have any evidence of it not being the case?

> Security is big business, as is compliance with regulatory law.  Large
> enterprise customers are NOT going to either void their system support
> contracts, or place themselves in jeopardy of failing a SOX audit.

I agree, that is why customers do not load other random security modules
in their kernel today, and why they will not do so tomorrow.  So,
because of that, this whole point about compliance with regulatory law
seems kind of moot :)

Again, LSM isn't going away at all, this is just one config option for
allowing LSM to work as a module that is changing.  If a customer
demands that this feature come back, I'm sure that the big distros will
be the first to push for it.  But currently, given that there are no
known external LSMs being used by customers demanding support, I don't
see what the big issue here really is.

thanks,

greg k-h

Re: LSM conversion to static interface

[Avi Kivity]

Greg KH wrote:
> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
>   
>> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
>> the LSM prevents commercial customers from using security modules other
>> than that provided by their Linux distributor.
>>     
>
> Any "customer" using a security model other than provided by their Linux
> distributor instantly voided all support from that distro by doing that.
>
> So, since the support is gone, they can easily build their own kernels,
> with their own LSM interfaces, and get the exact same lack of support :)
>
>   

Running a vendor kernel has the advantage of reusing all the QA work 
that has gone into that kernel.  It is very different from running 
2.6.24-rc1 (or 2.6.22.x).  Hence projects like centos: you don't get any 
support, but the likelihood of actually requiring support is lower than 
running some random kernel.

[but I agree that someone who has somehow determined that they need a 
specific LSM will probably have determined that they need vendor support 
as well]

-- 
error compiling committee.c: too many arguments to function

Re: LSM conversion to static interface

[Crispin Cowan]

Greg KH wrote:
> On Mon, Oct 22, 2007 at 10:00:46AM -0700, Thomas Fricaccia wrote:
>   
>> Security is big business, as is compliance with regulatory law.  Large
>> enterprise customers are NOT going to either void their system support
>> contracts, or place themselves in jeopardy of failing a SOX audit.
>>     
> I agree, that is why customers do not load other random security modules
> in their kernel today,
That "random" module could be a module supplied by a vendor other than
the distro supplier, such as a security vendor. It could be a research
prototype that the user wants to try out on their enterprise-supported
kernel. It could even be an in-house developed module that a local site
wants to run on his larger organization's blessed kernel.

So far from "random", these modules are motivated by circumstances
radically different than yours. In particular, rebuilding a kernel for
you (GregKH, many LKML developers) is a casual thing to be done before
breakfast, but is a scary obstacle to many others. It is an obstacle to
people who are skilled at computers but deliberately *not* kernel
developers (the whole world does not need to be a Linux kernel
developer) and it is an obstacle to large enterprise admins who have
organizational pressure to use specific, pre-built kernels.

>  and why they will not do so tomorrow.  So,
> because of that, this whole point about compliance with regulatory law
> seems kind of moot :)
>   
I think the specific stuff about regulatory compliance is tangential.
SarBox and friends don't specify Linux kernel versions, they are
incredibly vague and subject to interpretation. But they are part of
what drive organizations to have self-imposed rules about only running
blessed kernel versions.

Suffice it to say that there are a variety of reasons why someone either
cannot re-compile a kernel, or just does not want to recompile a kernel.
This change to LSM removes their choice to use modules others than those
provided by their distro vendor.

> Again, LSM isn't going away at all, this is just one config option for
> allowing LSM to work as a module that is changing.  If a customer
> demands that this feature come back, I'm sure that the big distros will
> be the first to push for it.  But currently, given that there are no
> known external LSMs being used by customers demanding support, I don't
> see what the big issue here really is.
>   
As I said, it is a medium issue, not a big one, which is why I didn't
speak out before.

I am opposed to this change because I see zero benefit to it, and a lot
of down-side in loss of user choice.

Because that is what this does: it does not help the kernel get better.
It *definitely* does not help the kernel become more secure. It mostly
just removes user's choice, by making it difficult to do things that
some people don't approve of.

As I've said, it doesn't hurt AppArmor, because 3 major distros ship it.
But it will hurt user choice and innovation, by making anything not
shipped by a distro more difficult to access.

There is some performance gains to be had by doing something to the LSM
interface. Certainly a configuration option that statically inlines all
the hooks and points them at a compiled in module would yield some
performance gain, but I don't know how much. But that raises 2 questions:

   1. Was *performance* really the reason this patch was proposed? Or
      was it because James really did want the restrictive effect of
      preventing people from choosing after-market modules and
      dynamically unloading them if they want? I believe that James was
      well-intentioned in trying to block these actions because he
      believes them to be insecure, and he's right, they are insecure.
      However, these actions are also very practically useful in many
      circumstances. I disagree with the change because an individual
      LSM can block both such actions if you wish, so imposing it on all
      LSM modules is restricting choice unnecessarily.
   2. Is the performance issue that this might address really big enough
      to bother fixing at all? Maybe, but I don't know. Again, I'm
      strictly opposed to the loss of flexibility until the performance
      issue is documented, and then I would rather see it be a
      configuration option you can choose to inline your module of
      choice, rather than the default behavior.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
	       Itanium. Vista. GPLv3. Complexity at work

Re: LSM conversion to static interface

[david]

On Mon, 22 Oct 2007, Crispin Cowan wrote:

>
> Suffice it to say that there are a variety of reasons why someone either
> cannot re-compile a kernel, or just does not want to recompile a kernel.
> This change to LSM removes their choice to use modules others than those
> provided by their distro vendor.
>
one reason to not be willing to rebuild the kernel is that they may rely 
on a module from a different third party that is shipped/tested for the 
specific pre-compiled kernels from the distro.

David Lang

Re: LSM conversion to static interface

[Giacomo Catenazzi]

Jan Engelhardt wrote:

> I do have a pseudo LSM called "multiadm" at 
> http://freshmeat.net/p/multiadm/ , quoting:

> Policy is dead simple since it is based on UIDs. The UID ranges can be 
> set on module load time or during runtime (sysfs params). This LSM is 
> basically grants extra rights unlike most other LSMs[1], which is why 
> modprobe makes much more sense here. (It also does not have to do any 
> security labelling that would require it to be loaded at boot time 
> already.)

But his is against LSM design (and first agreements about LSM):
LSM can deny rights, but it should not give extra permissions
or bypass standard unix permissions.

ciao
	cate

Re: LSM conversion to static interface

[Giacomo Catenazzi]

Thomas Fricaccia wrote:
> Some well-respected contributors have taken exception my amplification
> of Crispin Cowan's point about the patch that closes LSM.
> 
> Crispin Cowan <crispin@crispincowan.com> wrote:
>>     * It prevents enterprise users, and in fact anyone who isn't
>>       comfortable compiling their own kernel, from ever trying out any
>>       security module that their distro vendor of choice did not ship.
> 
> I extended this point by observing that regulatory laws make it difficult
> for enterprise customers to compile their own kernels, mentioning one
> of the more invasive statutes, Sarbanes-Oxley.
> 
> In reply, "Alan Cox" <alan@lxorguk.ukuu.org.uk> writes:
>> Crispin at least is providing genuine discussion points. Sarbox has
>> nothing to say on "using vendor linux kernels".
> 
> And just previously, "Greg KH" <greg@kroah.com> had written:
>> Since when does Sarbanes-Oxley decree that a company must use a
>> "standard kernel"?  And just exactly what defines such "standard
>> kernel"?  Can you point out where in that bill it requires such a
>> thing?
> 
> I was actually talking about the *effects* of regulatory law, rather
> than the wording in the text of the statutes.  The misunderstanding
> could be partially my fault, as my exact words were 
> 
>    As Sarbanes-Oxley and other regulatory laws require these
>    customers to use "standard kernels" ....
> 
> which may not have been as unambiguously clear as I intended.
> 
> But as long as we're here, let me elaborate on the point I tried to make.
> 
> SOX and other laws require enterprise customers to keep specified
> controls on their internal processing procedures, and keep documentation
> that can be audited to prove compliance.  The auditing requirements
> are extensive and detailed, and certainly include the kernel of an
> operating system used to process business and/or financial transactions.
> 
> It is within this framework that enterprise customers conclude something
> like (and this is vernacular, not the language within the statutes) "if
> we use any kernel other than that supplied by our distributor, the
> SOX auditing paperwork will be a nightmare."  (I've actually heard
> statements similar to this, and so believe that it is an accurate
> portrayal of the perception of the effects of regulatory law.  I'm not
> a lawyer.)
> 
> As I said at the beginning, I meant to amplify Crispin's observation
> that enterprise customers are reluctant to compile their own kernels
> with the additional observation that the complexities of regulatory
> law create obstacles that are significant contributors to that reluctance.
> 
> I'll not belabor the unfortunate non sequitur further.  You can find
> plenty of documentation of auditing requirements with by Googling
> combinations of "Sarbanes-Oxley," "operating system integrity", etc.
> This is a big-business topic of wide concern.

What do technical and regulatory differences have "driver/LSM module" that
is build-in and one that is modular?
It seems to me silly to find difference.  A kernel with a new kernel module
is a new kernel.

ciao
	cate

Re: LSM conversion to static interface

[Crispin Cowan]

Giacomo Catenazzi wrote:
> What do technical and regulatory differences have "driver/LSM module" that
> is build-in and one that is modular?
> It seems to me silly to find difference.  A kernel with a new kernel module
> is a new kernel.
>   
*I* understand that, from a security and logic integrity point of view,
there is not much difference between a rebuilt-from-source kernel, and a
standard kernel from the distro with a new module loaded.

However, there is a big difference for other people, depending on their
circumstances.

    * Some people live in organizations where the stock kernel is
      required, even if you are allowed to load modules. That may not
      make sense to you, but that doesn't change the rule.
    * Some people are not comfortable building kernels from source. It
      doesn't matter how easy *you* think it is, it is a significant
      barrier to entry for a lot of people. Especially if their day job
      is systems or security administration, and not kernel hacking.

Think of it like device drivers: Linux would be an enterprise failure if
you had to re-compile the kernel from source every time you added a new
kind of device and device driver.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
	       Itanium. Vista. GPLv3. Complexity at work

Re: LSM conversion to static interface

[Giacomo A. Catenazzi]

Crispin Cowan wrote:
> Giacomo Catenazzi wrote:
>> What do technical and regulatory differences have "driver/LSM module" that
>> is build-in and one that is modular?
>> It seems to me silly to find difference.  A kernel with a new kernel module
>> is a new kernel.
>>   
> *I* understand that, from a security and logic integrity point of view,
> there is not much difference between a rebuilt-from-source kernel, and a
> standard kernel from the distro with a new module loaded.
> 
> However, there is a big difference for other people, depending on their
> circumstances.
> 
>     * Some people live in organizations where the stock kernel is
>       required, even if you are allowed to load modules. That may not
>       make sense to you, but that doesn't change the rule.

[read also the very last commentary: don't take to seriously my
arguments]

ok, but why simplifying life of company with such silly rule?
Are not the same people that required commercial UNIX kernel?
So don't worry about internal company rules.  In one year a lot
of things changes.
Anyway it is a good motivation to delay the conversion, if there
are really so many external LSM modules used in production environment.
(but see next point)

>     * Some people are not comfortable building kernels from source. It
>       doesn't matter how easy *you* think it is, it is a significant
>       barrier to entry for a lot of people. Especially if their day job
>       is systems or security administration, and not kernel hacking.

Configuring a new kernel is not "kernel hacking" and IIRC is considered
in the very first level of LPI.

Anyway where you will find the new module?  It should be very specific
on the actual kernel installed.  I find few differences to distribute
a module or a kernel.  Distributions have/had a lot of kernels
(versions, SMP, processor specific, vserver, xen, readhat, clusteres, 
...), so why not distribute a new kernel?


 > Think of it like device drivers: Linux would be an enterprise
 > failure if you had to re-compile the kernel from source every
 > time you added a new kind of device and device driver.

This is a frequent argument, but I don't believe it ;-)
I see more time this argument that new devices on an enterprise.
The real argument is:
: Think of it like device drivers: Linux would be an enterprise
: failure if you had to *compile* the kernel from source for
: *every machine*.
Which is a good point to have modules.  Is it still a good point
to have LSM modules?  And to obey the "Sarbanes-Oxley"


Don't take me wrong, the above commentaries are not so serious,
and my point was not about modules, but why "Sarbanes-Oxley"
tell us that new modules are simpler then new kernel.

I like kernel without modules, so I want to understand all motivations
why people need modules (and this thread showed me other (non-classical)
reasons).  I know that the modules are necessary in most situation, but
I like to see if some reasons can be solved in other ways, so to
simplify also the life of "build-in" peoples.

ciao
	cate

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
>
>> I do have a pseudo LSM called "multiadm" at 
>> http://freshmeat.net/p/multiadm/ , quoting:
>
>> Policy is dead simple since it is based on UIDs. The UID ranges can be 
>> set on module load time or during runtime (sysfs params). This LSM is 
>> basically grants extra rights unlike most other LSMs[1], which is why 
>> modprobe makes much more sense here. (It also does not have to do any 
>> security labelling that would require it to be loaded at boot time 
>> already.)
>
>But his is against LSM design (and first agreements about LSM):
>LSM can deny rights, but it should not give extra permissions
>or bypass standard unix permissions.

It is just not feasible to add ACLs to all million files in /home,
also because ACLs are limited to around 25 entries.
And it is obvious I do not want <prof> to have UID 0, because
then you cannot distinguish who created what file.
So the requirement to the task is to have unique UIDs.
The next logical step would be to give capabilities to those UIDs.

*Is that wrong*? Who says that only UID 0 is allowed to have
all 31 capability bits turned on, and that all non-UID 0 users
need to have all 31 capability bits turned off?

So, we give caps to the subadmins (which is IMHO a natural task),
and then, as per LSM design (wonder where that is written) deny
some of the rights that the capabilities raised for subadmins grant,
because that is obviously too much.

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 21 2007 08:57, James Morris wrote:
>> >I'd like to note that I asked people who were actually affected, and had 
>> >examples of their real-world use to step forward and explain their use, 
>> >and that I explicitly mentioned that this is something we can easily 
>> >re-visit.
[...]

I looked at commit 20510f2f4e2dabb0ff6c13901807627ec9452f98
[havenot done much kernel activity recently] where you
transform the security interface, and what I see is that
all the static inline functions are replaced by an extern one, with the
same content. That actually seems to include more performance hit
than the (un)registering fluff. Why is that, actually?

Re: LSM conversion to static interface

[Giacomo A. Catenazzi]

Jan Engelhardt wrote:
> On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
>>> I do have a pseudo LSM called "multiadm" at 
>>> http://freshmeat.net/p/multiadm/ , quoting:
>>> Policy is dead simple since it is based on UIDs. The UID ranges can be 
>>> set on module load time or during runtime (sysfs params). This LSM is 
>>> basically grants extra rights unlike most other LSMs[1], which is why 
>>> modprobe makes much more sense here. (It also does not have to do any 
>>> security labelling that would require it to be loaded at boot time 
>>> already.)
>> But his is against LSM design (and first agreements about LSM):
>> LSM can deny rights, but it should not give extra permissions
>> or bypass standard unix permissions.
> 
> It is just not feasible to add ACLs to all million files in /home,
> also because ACLs are limited to around 25 entries.
> And it is obvious I do not want <prof> to have UID 0, because
> then you cannot distinguish who created what file.
> So the requirement to the task is to have unique UIDs.
> The next logical step would be to give capabilities to those UIDs.
> 
> *Is that wrong*? Who says that only UID 0 is allowed to have
> all 31 capability bits turned on, and that all non-UID 0 users
> need to have all 31 capability bits turned off?
> 
> So, we give caps to the subadmins (which is IMHO a natural task),
> and then, as per LSM design (wonder where that is written) deny
> some of the rights that the capabilities raised for subadmins grant,
> because that is obviously too much.

Nothing wrong.  I only said that it was against (IIRC) the
principle of LSM in kernel (we should only remove capacities).
I've nothing against the changing the design or rules.
It was only a commentary, to be sure that we know what we do ;-)

ciao
	cate

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 23 2007 11:14, Giacomo A. Catenazzi wrote:
>> So, we give caps to the subadmins (which is IMHO a natural task),
>> and then, as per LSM design (wonder where that is written) deny
>> some of the rights that the capabilities raised for subadmins grant,
>> because that is obviously too much.
>
> Nothing wrong.  I only said that it was against (IIRC) the
> principle of LSM in kernel (we should only remove capacities).

Leave my capacitance alone! :)
[i hope you get the joke]

Anyway - I see your point. But what would give the user the capabilities
in the first place, if not a security module that implements this-and-that
capability-raising scheme?

Re: LSM conversion to static interface

[Simon Arlott]

On Mon, October 22, 2007 18:13, Greg KH wrote:
> I agree, that is why customers do not load other random security modules
> in their kernel today, and why they will not do so tomorrow.  So,
> because of that, this whole point about compliance with regulatory law
> seems kind of moot :)
>
> Again, LSM isn't going away at all, this is just one config option for
> allowing LSM to work as a module that is changing.  If a customer
> demands that this feature come back, I'm sure that the big distros will
> be the first to push for it.  But currently, given that there are no
> known external LSMs being used by customers demanding support, I don't
> see what the big issue here really is.

I have an out of tree module to do per-port (tcp/udp) bind permissions,
it works fine with the "capability" module as secondary and I can load
or unload both of them at any time... this recent change completely
breaks that. (I had to #include dummy.c though).

Why should I now need to:
1. reboot every time I change the code when I could just reload modules before?
2. put it into my kernel source tree to use it?

-- 
Simon Arlott

Re: LSM and Containers (was: LSM conversion to static interface)

[Serge E. Hallyn]

Quoting Crispin Cowan (crispin@crispincowan.com):
> Peter, I may be mistaken, but I think you are talking about an entirely
> different issue than the LSM static interface issue, so I've changed the
> subject.
> 
> Peter Dolding wrote:
> > You are all focusing on vendors.  I am thinking server farm or people
> > running many different distros side by side using containers.
> This right here is a challenging goal.
> 
> It completely surprises me that anyone would consider trying to run
> different distros in different containers.

It seems reasonable to me.

> It would especially surprise
> me if one tried to run different kernels in different containers.

That's not just unreasonable, it's impossible :)

> It is my understanding of containers that they are intended to be a
> *lightweight* virtualization technique, giving each container
> effectively a private copy of identical instances of the host OS.
> 
> If you want to rent out divergent distros, kernels, etc. then it seems
> to me that heavier virtualization like Xen, KVM, VMware, etc. are the
> right answer, rather than trying to force difficult kernel solutions
> into the container and LSM features into the kernel.

For different kernels, yes, but unless you pick two distros which
require incompatible kernel features (?) I don't see running, say,
gentoo, fedora, and ubuntu under different containers as a problem.

Perhaps the biggest reason not to do that, speaking practically, is that
you miss out on some of the ability to share /usr, /lib, etc readonly
among containers to save overall disk space.

> I call it "difficult" because you would have to build a great big switch
> into the LSM interface, so that each hook is dispatched to the LSM
> module being used by the current container. This will impose some
> complexity and overhead, making each hook slower. Worse,the semantics
> become painfully undefined if a syscall by one container touches an
> object owned by a different container; which LSM gets called to mediate
> the access?

At first my thought was this is worse than dealing with stacker.

But on the other hand, perhaps introducing some sort of 'personality' to
objects and subjects, where the personality decides which LSM is invoked
for access, can be done more optimally than one would think.  It would
probably require strict enforcement that two "things" with different
personalities can NOT mix, ever.

> What makes a *lot* more sense to me is for individual LSMs to try to
> "containerize" themselves. This is actually the AppArmor plan: we hope
> to eventually support having a private AppArmor policy per container.

Agreed, that had been my assumption.  That, and that the configuring
of LSM policies inside a container would simply be disabled if say
loading a suse container under a fedora host.

> Thus all of the containers on the physical machine will be running
> identical kernels, and all will use AppArmor, but each one can have a
> different AppArmor policy set, so that e.g. my private Apache process
> instance is confined in my container different than your Apache process
> is confined in your container.
> 
> I see no barrier to SELinux or SMACK or TOMOYO doing the same thing. But
> I see *big* barriers to trying to support multiple LSM modules in the
> kernel at the same time with each container using the LSM of its choice.

It's not as clear to me how SMACK (or the MLS/MCS portion of selinux)
would be handled.

-serge

Re: LSM conversion to static interface

[Serge E. Hallyn]

Quoting Jan Engelhardt (jengelh@computergmbh.de):
> 
> On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
> >
> >> I do have a pseudo LSM called "multiadm" at 
> >> http://freshmeat.net/p/multiadm/ , quoting:
> >
> >> Policy is dead simple since it is based on UIDs. The UID ranges can be 
> >> set on module load time or during runtime (sysfs params). This LSM is 
> >> basically grants extra rights unlike most other LSMs[1], which is why 
> >> modprobe makes much more sense here. (It also does not have to do any 
> >> security labelling that would require it to be loaded at boot time 
> >> already.)
> >
> >But his is against LSM design (and first agreements about LSM):
> >LSM can deny rights, but it should not give extra permissions
> >or bypass standard unix permissions.
> 
> It is just not feasible to add ACLs to all million files in /home,
> also because ACLs are limited to around 25 entries.
> And it is obvious I do not want <prof> to have UID 0, because
> then you cannot distinguish who created what file.
> So the requirement to the task is to have unique UIDs.
> The next logical step would be to give capabilities to those UIDs.
> 
> *Is that wrong*? Who says that only UID 0 is allowed to have
> all 31 capability bits turned on, and that all non-UID 0 users
> need to have all 31 capability bits turned off?
> 
> So, we give caps to the subadmins (which is IMHO a natural task),
> and then, as per LSM design (wonder where that is written) deny
> some of the rights that the capabilities raised for subadmins grant,
> because that is obviously too much.

Once the per-process capability bounding set is accepted
(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
like:

	1. Create user 'jdoe' with uid 0
	2. write a pam module which, when jdoe logs in, takes
	   CAP_NET_ADMIN out of his capability bounding set
	3. Now jdoe can log in with the kind of capabilities subset
	   you describe.

It's not a perfect solution, since it doesn't allow jdoe any way at all
to directly execute a file with more caps (setuid and file capabilities
are subject to the capbound).  So there is certainly still a place for
multiadm.

-serge

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 23 2007 10:20, Serge E. Hallyn wrote:
>
>Once the per-process capability bounding set is accepted
>(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
>like:
>
>	1. Create user 'jdoe' with uid 0

UID 0 is _not_ acceptable for me.

>	2. write a pam module which, when jdoe logs in, takes
>	   CAP_NET_ADMIN out of his capability bounding set
>	3. Now jdoe can log in with the kind of capabilities subset
>	   you describe.

It is not that easy.
CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security
checks in kernel code, and then the detailed implementation of
limitation is done inside multiadm.
This is not just raising or lowering capabilities.

>It's not a perfect solution, since it doesn't allow jdoe any way at all
>to directly execute a file with more caps (setuid and file capabilities
>are subject to the capbound).  So there is certainly still a place for
>multiadm.

A normal user can execute suid binaries today, and so can s/he with mtadm.
I do not see where that will change - it does not need any caps atm.

Re: LSM conversion to static interface

[Serge E. Hallyn]

Quoting Jan Engelhardt (jengelh@computergmbh.de):
> 
> On Oct 23 2007 10:20, Serge E. Hallyn wrote:
> >
> >Once the per-process capability bounding set is accepted
> >(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
> >like:
> >
> >	1. Create user 'jdoe' with uid 0
> 
> UID 0 is _not_ acceptable for me.

I'm aware.

> >	2. write a pam module which, when jdoe logs in, takes
> >	   CAP_NET_ADMIN out of his capability bounding set
> >	3. Now jdoe can log in with the kind of capabilities subset
> >	   you describe.
> 
> It is not that easy.
> CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security
> checks in kernel code, and then the detailed implementation of
> limitation is done inside multiadm.

You mean the read/write split?

> This is not just raising or lowering capabilities.

Nope, but it's related, and as I pointed out below it fits in pretty
nicely.

> >It's not a perfect solution, since it doesn't allow jdoe any way at all
> >to directly execute a file with more caps (setuid and file capabilities
> >are subject to the capbound).  So there is certainly still a place for
> >multiadm.
> 
> A normal user can execute suid binaries today, and so can s/he with mtadm.
> I do not see where that will change - it does not need any caps atm.

And he will still be able to *run* the suid binary, but if cap_bound is
reduced he won't be able to use capabilities taken out of the bounding
set, multiadm loaded or not.

-serge

Re: LSM conversion to static interface

[Adrian Bunk]

On Mon, Oct 22, 2007 at 07:47:36PM +0200, Avi Kivity wrote:
> Greg KH wrote:
>> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
>>   
>>> Yes, I think Crispin has succinctly summed it up:  irrevocably closing
>>> the LSM prevents commercial customers from using security modules other
>>> than that provided by their Linux distributor.
>>>     
>>
>> Any "customer" using a security model other than provided by their Linux
>> distributor instantly voided all support from that distro by doing that.
>>
>> So, since the support is gone, they can easily build their own kernels,
>> with their own LSM interfaces, and get the exact same lack of support :)
>
> Running a vendor kernel has the advantage of reusing all the QA work that 
> has gone into that kernel.  It is very different from running 2.6.24-rc1 
> (or 2.6.22.x).  Hence projects like centos: you don't get any support, but 
> the likelihood of actually requiring support is lower than running some 
> random kernel.

You can also get the QA work by building your own kernel from vendor 
kernel sources.

E.g. the Debian distribution ships a package linux-source-2.6.18 that 
contains a linux-source-2.6.18.tar.bz2 with the patched 2.6.18 kernel 
sources Debian uses for building its kernels.

> [but I agree that someone who has somehow determined that they need a 
> specific LSM will probably have determined that they need vendor support as 
> well]

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: LSM conversion to static interface

[Geert Uytterhoeven]

On Sun, 21 Oct 2007, Greg KH wrote:
> On Sun, Oct 21, 2007 at 07:24:42PM -0700, Thomas Fricaccia wrote:
> > As Sarbanes-Oxley and
> > other regulatory laws require these customers to use "standard
> > kernels", the result is a rather dreary form of vendor lock-in, where the
> > security framework is coupled to the distribution.
> 
> Wait, what?
> 
> Since when does Sarbanes-Oxley decree that a company must use a
> "standard kernel"?  And just exactly what defines such "standard
> kernel"?  Can you point out where in that bill it requires such a thing?

Simple, these days Sarbanes-Oxley is the default argument behind anything being
pushed down your throat in a company.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: LSM and Containers

[Crispin Cowan]

Serge E. Hallyn wrote:
> Quoting Crispin Cowan (crispin@crispincowan.com):
>   
>> It is my understanding of containers that they are intended to be a
>> *lightweight* virtualization technique, giving each container
>> effectively a private copy of identical instances of the host OS.
>>
>> If you want to rent out divergent distros, kernels, etc. then it seems
>> to me that heavier virtualization like Xen, KVM, VMware, etc. are the
>> right answer, rather than trying to force difficult kernel solutions
>> into the container and LSM features into the kernel.
>>     
> For different kernels, yes, but unless you pick two distros which
> require incompatible kernel features (?) I don't see running, say,
> gentoo, fedora, and ubuntu under different containers as a problem.
>
> Perhaps the biggest reason not to do that, speaking practically, is that
> you miss out on some of the ability to share /usr, /lib, etc readonly
> among containers to save overall disk space.
>   
This is why it just doesn't seem very reasonable. People who want to do
that will just use KVM or Xen. People who want the efficiency of
lightweight containers, and have enough load pressure to care, can just
have one Fedora physical box with many containers all running Fedora,
and another openSUSE physical box with many containers all running openSUSE.

I can see how you *could* manage to run different distros in different
containers, but you would have to make many compromises. No sharing of
read-only disk as Serge said. You would have to pick one kernel, as no 2
distros I know of actually run the same kernel. You would have to pick
one set of device drivers, and one LSM. By the time you deal with all
this crap, just using KVM or Xen starts to look good :-)

>> I call it "difficult" because you would have to build a great big switch
>> into the LSM interface, so that each hook is dispatched to the LSM
>> module being used by the current container. This will impose some
>> complexity and overhead, making each hook slower. Worse,the semantics
>> become painfully undefined if a syscall by one container touches an
>> object owned by a different container; which LSM gets called to mediate
>> the access?
>>     
> At first my thought was this is worse than dealing with stacker.
>
> But on the other hand, perhaps introducing some sort of 'personality' to
> objects and subjects, where the personality decides which LSM is invoked
> for access, can be done more optimally than one would think.  It would
> probably require strict enforcement that two "things" with different
> personalities can NOT mix, ever.
>   
Yes, that's what you would have to do. But I basically don't think it is
a good idea; use full virtualization if you don't want to share kernel
features among your virtual guests.

>> What makes a *lot* more sense to me is for individual LSMs to try to
>> "containerize" themselves. This is actually the AppArmor plan: we hope
>> to eventually support having a private AppArmor policy per container.
>>     
> Agreed, that had been my assumption.  That, and that the configuring
> of LSM policies inside a container would simply be disabled if say
> loading a suse container under a fedora host.
>   
This is why running an openSUSE container under a Fedora host (or vice
versa) seems daft to me.

>> Thus all of the containers on the physical machine will be running
>> identical kernels, and all will use AppArmor, but each one can have a
>> different AppArmor policy set, so that e.g. my private Apache process
>> instance is confined in my container different than your Apache process
>> is confined in your container.
>>
>> I see no barrier to SELinux or SMACK or TOMOYO doing the same thing. But
>> I see *big* barriers to trying to support multiple LSM modules in the
>> kernel at the same time with each container using the LSM of its choice.
>>     
> It's not as clear to me how SMACK (or the MLS/MCS portion of selinux)
> would be handled.
>   
That actually seems easier to me. You may not need to do anything at all
to the MLS/MCS code. There is no actual "policy" in MLS, it is just a
single policy (label dominance) and all of your "policy" is expressed
through labeling. So what you do is make the container ID be part of the
label schema, and poof! none of the containers are permitted to touch
objects belonging to any others, because they cannot dominate each other.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
	       Itanium. Vista. GPLv3. Complexity at work

Re: LSM and Containers

[Peter Dolding]

Crispin Cowan wrote:
> Serge E. Hallyn wrote:
>   
>> Quoting Crispin Cowan (crispin@crispincowan.com):
>>   
>>     
>>> It is my understanding of containers that they are intended to be a
>>> *lightweight* virtualization technique, giving each container
>>> effectively a private copy of identical instances of the host OS.
>>>
>>> If you want to rent out divergent distros, kernels, etc. then it seems
>>> to me that heavier virtualization like Xen, KVM, VMware, etc. are the
>>> right answer, rather than trying to force difficult kernel solutions
>>> into the container and LSM features into the kernel.
>>>     
>>>       
>> For different kernels, yes, but unless you pick two distros which
>> require incompatible kernel features (?) I don't see running, say,
>> gentoo, fedora, and ubuntu under different containers as a problem.
>>
>> Perhaps the biggest reason not to do that, speaking practically, is that
>> you miss out on some of the ability to share /usr, /lib, etc readonly
>> among containers to save overall disk space.
>>   
>>     
> This is why it just doesn't seem very reasonable. People who want to do
> that will just use KVM or Xen. People who want the efficiency of
> lightweight containers, and have enough load pressure to care, can just
> have one Fedora physical box with many containers all running Fedora,
> and another openSUSE physical box with many containers all running openSUSE.
>
> I can see how you *could* manage to run different distros in different
> containers, but you would have to make many compromises. No sharing of
> read-only disk as Serge said. You would have to pick one kernel, as no 2
> distros I know of actually run the same kernel. You would have to pick
> one set of device drivers, and one LSM. By the time you deal with all
> this crap, just using KVM or Xen starts to look good :-)
>   
Sorry the reason for doing it is 1 set of driver.  In particular 
Opengl.   KVM, Xen, Lguest... All virtual machines cannot handle it 
effectively so you have one very high comprise.  Containers can.

Same with other devices some devices don't take well at all being 
wrapped up in KVM,  Xen and other systems.  Running the same kernel is 
not a issue to me.

Most distributions I have run with standard from kernel.org with there 
LSM.   Nothing else added to kernel.   So the different kernel is null 
and void.   If LSM are rebuild we will see distro kernels with support 
for a broad range of distro support.   You may have a distro that allows 
like the top 10 server Distributions to be run under it.  Of course you 
are not going to be using any stock kernel from those Distros if they 
don't support running other distros.   I would not bring it up if I had 
not run OpenSuse Fedora and Debian and other distros of the same kernel 
before.   How simple in initrd load the LSM for the Distro that was 
it.   There is no technical problem at the kernel for doing it.  Also 
part of the reason why I despise static LSM's becoming only option cross 
distro performance testing of a kernel to see if there is a difference 
will be made harder since I will have to build the kernel more than 
once.    Now when I get to containers you are now saying I cannot do the 
same thing.

I know current LSM model does not fit well for this.   Because its a 
giant hooking solution.   This solution is not suitable to exist well 
with containers and massively limiting on security improvements to the 
over all os that can be done..

The LSM model needs ripping in two to work great with containers and 
along the way allow applications and users to take care of there own 
problems.

Enforcement modules and Controllers.

Controllers work on threads and processors created to allocate security 
limitations.   LSM level controller can grant higher security access to 
threads and processors than what they all ready have to the level of the 
LSM.  User/program level controllers can only remove permissions to do 
things this is most likely better as a feature of the Enforcement 
modules.   LSM level controllers have to be attached to kernel or a 
security containers.  Since a container could all ready have limits from 
another LSMs put on it could only allocate permissions inside those limts.

Enforcement is exactly that.    Enforcement modules would be like posix 
file caps and so on.  An option has to be choose here if  Enforcement 
modules have to report to LSM level controller on secuirty change 
request to lower and expand or only to expand or not at all.  Not at all 
being default because it could be a new feature the controller does not 
know how to handle or want to handle.   Most likely this would be 
controller option on what if any information it wants out of the 
Enforcement modules.   Default operation of all enforcement modules is 
like posix file caps is lower only.     No option to expand what has all 
ready been given.   With a LSM controller asking to be given notice of 
change of a Enforcement section it can allow raising or forbid 
lowering.  Applications developers like GUI Filemanagers wine... Can 
depend on the Enforcement parts always being there.

This is a overall system wide upgrade of security  that does not fail 
completely just because you disable the contoller.   Because if all 
applications are doing there own internal thread based and process id 
based enforcements what can be far tighter than what any controller can 
do since they know what the application should be doing where.

I hear different people asking for a LSM to be build into kernel.   This 
is not a  requirement.    The enforcement features of LSM's are.  Each 
one of the enforcement features is a upgrade to the overall security of 
the operating system no matter the LSM loaded or even if LSM is loaded.

Basically just like containers take responsibility for parts 
individually when put  into once piece become a virtual server.   The 
same needs to be done with LSM's.    The controller is the final thing 
that joins the parts up.   Not coming with the parts in one huge blob as 
LSM do now.  The huge blob problem is why they don't want to work right 
containers.  Over head is small with
Controllers.  From Enforcement module to Controller is always the same 
depth.  When Controller goes to change permissions its checked against 
the list its allowed.   At this point does not matter if you are 1 deep 
or 1000 deep.   Since there is no need to go any deeper or run other 
Controllers to get information.   Just the first Controller the one you 
might statically build in gets told it has every permission to do 
whatever it sees fit maybe.   The first Controller at build time could 
have its rights limited.  Just like selinux strict mode for all.  As you 
can see 100 percent the same path level no matter what.  Only thing that 
changes in what controller you are in.

As bad as it sounds to some people doing this will lower the security 
difference between selinux apparmor or other LSM's .  This forces user 
and security friendly solutions out of LSM makers.  Yes true completion 
to produce the best and leave users as least exposed as able.   Not my 
LSM is better than yours arguments with complexity of comparing.  It 
will be simpler to compare LSM's ok what enforcement modules does it 
control.   Does that cover the area I need.   Then look at how it 
controls them and choose.

Note LSM controllers could be Security Containers.   Just one Container 
is set default off the start line.

Peter Dolding

Re: LSM conversion to static interface

[Greg KH]

On Tue, Oct 23, 2007 at 12:12:11AM -0700, Crispin Cowan wrote:
>     * Some people are not comfortable building kernels from source. It
>       doesn't matter how easy *you* think it is, it is a significant
>       barrier to entry for a lot of people. Especially if their day job
>       is systems or security administration, and not kernel hacking.

That's why I wrote a whole book about how to do just that.  And it's
free, print it out and give it to all your friends!
	www.kroah.com/lkn/

thanks,

greg k-h

Re: LSM and Containers

[Peter Dolding]

The other thing you have not though of and is critical.  If LSM is the
same LSM across all containers.  What happens if that is breached and
tripped to disable.  You only want to loss one container to a breach
not the whole box and dice in one hit.  Its also the reason why my
design does not have a direct link between controllers.  No cascade
threw system to take box and dice.

The more I look at it more holes I find why the current LSM model just
cannot keep on existing with Containers.   Its not the best option.
Hacking it to work with containers is only creating risks of more
problems.  The LSM model as also breed that problem of not sharing
security tech advantages to everyone.  Ie if they don't use our LSM
they don't need/deserve our defense.

Different LSM per container from a security point of view appears
critical.  Sorry to say redesign from the ground up time everyone.
Its a round peg into a square hole yes you can bash it in but it will
never fit right.

Peter Dolding

ps sorry for going on so long I just see this as a major problem.   If
you have a solution to it tell me.  Since a cut line has be put
somewhere with containers.

Re: LSM and Containers

[Crispin Cowan]

Peter Dolding wrote:
> The other thing you have not though of and is critical.  If LSM is the
> same LSM across all containers.  What happens if that is breached and
> tripped to disable.  You only want to loss one container to a breach
> not the whole box and dice in one hit.  Its also the reason why my
> design does not have a direct link between controllers.  No cascade
> threw system to take box and dice.
>   
Sorry, but I totally disagree.

If you obtain enough privilege to disable the LSM in one container, you
also obtain enough privilege to disable *other* LSMs that might be
operating in different containers. This is a limitation of the
Containers feature, not of LSM.

The purpose of LSM would be to manage privilege such that you cannot do
damage, and in particular, any LSM that fails to prevent an attacker
from disabling the LSM itself has failed, either in design, or in having
an inadequate policy in place.

> The more I look at it more holes I find why the current LSM model just
> cannot keep on existing with Containers.   Its not the best option.
> Hacking it to work with containers is only creating risks of more
> problems.  The LSM model as also breed that problem of not sharing
> security tech advantages to everyone.  Ie if they don't use our LSM
> they don't need/deserve our defense.
>   
Again, I completely disagree.

Well, I agree that the hacking you proposed to permit different LSMs in
different containers is a bad idea, so lets not do that :)

I see no need to support different LSMs in different containers. The
complexity of such a feature would be very high. The utility strikes me
as being very low; people who want that degree of separation of
containers should be using Xen or KVM, not Containers.

> Different LSM per container from a security point of view appears
> critical.  Sorry to say redesign from the ground up time everyone.
> Its a round peg into a square hole yes you can bash it in but it will
> never fit right.
>   
I have no idea how you can support such assertions. Absolutely not. It
is quite clear that the way to address security for containers is to
enhance individual LSM modules to be container-aware so that you can
have separate policies in the separate containers. That is in keeping
with the spirit of sharing the kernel, and providing separate instances
to the users.

> ps sorry for going on so long I just see this as a major problem.   If
> you have a solution to it tell me.  Since a cut line has be put
> somewhere with containers.
>   
Where as I see it as a very minor problem, and very easy to fix without
any re-design of LSM, or of Containers. It only requires container-aware
LSM modules.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
	       Itanium. Vista. GPLv3. Complexity at work

Re: LSM and Containers

[Peter Dolding]

On 10/25/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> Peter Dolding wrote:
> > The other thing you have not though of and is critical.  If LSM is the
> > same LSM across all containers.  What happens if that is breached and
> > tripped to disable.  You only want to loss one container to a breach
> > not the whole box and dice in one hit.  Its also the reason why my
> > design does not have a direct link between controllers.  No cascade
> > threw system to take box and dice.
> >
> Sorry, but I totally disagree.
>
> If you obtain enough privilege to disable the LSM in one container, you
> also obtain enough privilege to disable *other* LSMs that might be
> operating in different containers. This is a limitation of the
> Containers feature, not of LSM.
>
That is not a Container feature.   If you have enough privilege does
not mean you can.  Root user in a Container does not mean you can play
with other containers applications.  There is a security split at the
container edge when doing Virtual Servers what by using one LSM you
are disregarding.

Simple point if one LSM is disabled in a container it can only get the
max rights of that Container.  So cannot see the other LSM's on the
system bellow it.  Reason also why in my model its the same layout if
there is 1 or 1000 stacked so attack cannot tell how deep they are in
and if there is anything to be gained by digging.  You have to break
the Security Container as well to get higher.   Of course breaking the
base LSM you would have problems the one with full powers of the
system and the right to kill and control the containers bellow it.
Most likely it would be wise to run that just for limited operations.
Really limited operations.

I think you need to go any play with Solaris some time what containers
can do is quite impressive.  Right upto changing the syscalls and
device names inside them.  Now its only going to get tricker if
someone brings in Freebsd and Solaris emulation containers into linux.
 Yes this is still just using the Linux kernel.  Because LSM's don't
exist on them you will want to plug in a module to suit the platform
contained inside the container.  In particular something different to
process the security configs even if the same enforcement code is
used.

You are dealing with something far more powerful current model is not
going to fit.  I look long term and I just cannot find what you are
doing is going to fit in anyway shape or form.  Just different Linux
distros is the simple form of containers not is fully grown form.
This is the problem if you cannot do that  future of containers will
have problems because LSM will be limiting its forms.

To rebuild a security framework takes time.  Its time to pull head out
sand that containers are not simple thing that what has worked in past
with small alterations will work with it in future.

Containers are completely new system with completely new problems.
LSM's should not interfere with its development.

What you are doing is having each LSM create its own outer shield.
With its own weaknesses.    Common Security Container makes only one
shield at edge of containers to maintain and look after.    Does not
different  weakness to track down and fix on a LSM by LSM base.

Peter Dolding

Re: LSM and Containers

[Serge E. Hallyn]

Quoting Peter Dolding (oiaohm@gmail.com):
> On 10/25/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> > Peter Dolding wrote:
> > > The other thing you have not though of and is critical.  If LSM is the
> > > same LSM across all containers.  What happens if that is breached and
> > > tripped to disable.  You only want to loss one container to a breach
> > > not the whole box and dice in one hit.  Its also the reason why my
> > > design does not have a direct link between controllers.  No cascade
> > > threw system to take box and dice.
> > >
> > Sorry, but I totally disagree.
> >
> > If you obtain enough privilege to disable the LSM in one container, you
> > also obtain enough privilege to disable *other* LSMs that might be
> > operating in different containers. This is a limitation of the
> > Containers feature, not of LSM.
> >
> That is not a Container feature.   If you have enough privilege does
> not mean you can.  Root user in a Container does not mean you can play
> with other containers applications.  There is a security split at the
> container edge when doing Virtual Servers what by using one LSM you
> are disregarding.
> 
> Simple point if one LSM is disabled in a container it can only get the
> max rights of that Container.  So cannot see the other LSM's on the
> system bellow it.  Reason also why in my model its the same layout if
> there is 1 or 1000 stacked so attack cannot tell how deep they are in
> and if there is anything to be gained by digging.  You have to break

You're sometimes hard to parse, but here are a few basic facts within
which to constrain our discussions:

	1. LSMs are a part of the kernel.  The entire kernel is in the
	   same trusted computing base
	2. containers all run on the same kernel
	3. whether an lsm is compromised, or a tty driver, or anything
	   else which is in the TCB, all containers are compromised
	4. it is very explicitly NOT a goal to hide from a container
	   the fact that it is in a container.  So your 'cannot tell how
	   deep they are' is not a goal.

If you want to be able to 'plug' lsms in per container, by all means
feel free to write a proof of concept.  It is kind of a cool idea.  But
be clear about what you'll gain:  You allow the container admin to
contrain data access within his container in the way he chooses using
the model with which he is comfortable.  It does nothing to protect one
container from another, does nothing to protect against kernel exploits,
and absolutely does nothing to protect a container from the 'host'.

Also please keep in mind that the container security framework is not
only not yet complete, it's pretty much not started.  My own idea for
how to best do it are outlined in emails which are in the containers
list archive.  But in terms of LSM they follow the idea Crispin
outlines, namely that the LSMs support containers themselves.  And, in
a proces in a container started without CAP_NS_OVERRIDE (which does not
yet exist :) in its capability bounding set will only be able to access
files in another container as DAC user 'other' (i.e if perms are 754, it
will get read access, if 750, then none), even if it has
CAP_DAC_OVERRIDE.  (unless it gets an authorization key for the owning
user in the target namespace, but *that's* probably *years* off)

-serge

Re: LSM and Containers

[Peter Dolding]

> You're sometimes hard to parse, but here are a few basic facts within
> which to constrain our discussions:
>
>         1. LSMs are a part of the kernel.  The entire kernel is in the
>            same trusted computing base
>         2. containers all run on the same kernel
>         3. whether an lsm is compromised, or a tty driver, or anything
>            else which is in the TCB, all containers are compromised
>         4. it is very explicitly NOT a goal to hide from a container
>            the fact that it is in a container.  So your 'cannot tell how
>            deep they are' is not a goal.
You are missing what I am saying.

I am breaking the LSM in two.  Kernel level comprise that is out of my hands.

If you wished in mine the controller could be user space run outside
kernel does not have to stay in the TCB.  Since its not having any
direct control on the approval or rejection of access.  Its only
queried when needed like when a process breaches the rules applied to
it or when processes start or changing security.   So breaching it
turning it off and so on.  This is to reduce the risk of someone
trying to customize a LSM can cause a security flaw of hell
level(Inside kernel space).

With Intel's and Amd new memory table splitting yes the controller
could be put away from the main kernel in time with the rest of the
container only data.  Yes less bits trusted.  This includes when
sending the container between machines the controller with it current
state could be sent with it.  If the interface to controller is
standard of course.  Ok apparmor and selinux will cope with your
system but some of the more complex state based need to transfer state
as well this should be in the controller bit of a LSM and not mixed up
with the state of the overall machine either.

Over all this is making it simpler to do advanced container things
like sending between servers.

The permission enforcement parts stay the same no matter the
controller in use.  Breaching the enforcement parts still remain a
problem.  Allows running many controllers unlike LSM's where they can
fight and on way around that cleanly.  Just like LSM two controllers
controlling the same space would still fight so guess how many each
container take 1.   Since a different controller has to be give its
own zone.  So people cannot complain about not being able to run there
preferred controller if they want a different one they have to give it
a different zone.  Yes this is getting on top of a lot of long term
problems of people wanting a or b LSM. Stuff it have both and be
happy.

Its also removing the single overall kill switch.   And replacing them
with a per container kill switches.   So someone does what will
normally turn X controller off and it does.   Yet still the outside
security is applied to everything run in the container.   Security is
lowed but not off.

The controllers don't need to keep track of how deep they are.  They
just don't need to know.  From there point of view the world ends from
there startup security settings.  Only time the controller would have
to be give notice is if those outside security settings were changed
so it could update the programs under it to the way it wanted.  Even
that the security settings if they were lower would have just been
brute forced applied.  Basically its  have you done containers running
containers is you model Serge E. Hallyn.  This avoids have to much
around with flags for the next container in.  Only thing in mine are
you doing is changing the path back to the controller from the
security enforcing modules.  Enforcing modules process not doing
permissions were told to allow I report that to x secuirty container
that reports it to contoller.  Note the security container only hands
out what its allowed nothing more the controller is not trusted.   No
processing to work out what security files it should be using since
the controller only knows the files it should be using.

Yes there is overhead in my system.  But were able the system is
avoiding traveling in a perfectly functioning system controller could
be only being bothered when new processors were being created the rest
of the time the enforcement modules just do there job as they were
configured.

Traveling down a tree of stacked LSM is going to cause massive lag. Ie
knowing that something is below you.  Not knowing reduces travel and
time to resolve.  And allows security to be controlled over the
complete container from one spot.  The problem with running many LSM
again having to tweek them all to get it locked down on container.  Ie
enabling some disabling others so simple to loss track and have big
problems.  No problem here the secuirty model is applied to the
container and if you want to lock its outside down you just do and the
controller inside has to cope.  Yes it will be possible to take too
much away from a security container.  Ok this security container
should not have access to that device slam not a question.  With
running many LSM the question what one does that container own to so I
do turn that device off and not have another LSM turn it back on.

Besides having selinux and apparmor installed side by side is going to
lag the system due to overlapping hooks.   This what I am avoiding.
The enforcement modules are only hooked in once no reason at all to
overlap them.  This overlapping is what makes running many LSM
problematic.

The outside security on a container will stay on even if the host LSM
is turned off in the design I am look at.  It was set when the
container started and would have to be directly updated.  The outside
security defined to a container would be everything selinux could do
to a program and then some. Just like selinux opt in.

Over lapping I am handling differently in this design.   The outside
security set on the container covers overlaps.  Far more flex able
option.  Using directory filtering and other options are on the table
as well as far more complex cap options.  My design depends on the
common protective modules.   Not the bit that says this is Mac or Role
based or State or so on.

Basically apparmor and selinux would be sitting on the same engine
that everyone can use to build solid controllers.  If you want a new
enforcement feature you would add it for everyone.  Since altering the
controller would be toothless only can tweak what already exists since
you can never be sure its even in kernel space no direct tweaking no
hooking no bad stuff with controllers.

There is a security advantage from the design change even for people
not using containers or LSM.   Everything in system can apply LSM
style restrictions lower than what it has to what it wants to run even
if a controller is present or not.   The controller is to provide the
security model in use.  With the enforcement system you could almost
do any security model with user space code.  The difference being not
catching process starts to apply security to them.  This is useful for
programs running untrusted content web browers that java program
running from web does not need all the access I am cut it back.
Application level security something LSM overlook and it not wise to
use different interfaces for it.

Yes these are major changes in design.  Yes they will force clear
designs and more sharing so everyone can take advantage of
advancements.  As well should kill off lots of problems of  poor
quality LSM's and LSM limitations.  Basically my design and LSM cannot
live side by side effectively.

Peter Dolding

Re: LSM conversion to static interface

[Valdis.Kletnieks]

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

On Tue, 23 Oct 2007 10:34:09 CDT, "Serge E. Hallyn" said:

> And he will still be able to *run* the suid binary, but if cap_bound is
> reduced he won't be able to use capabilities taken out of the bounding
> set, multiadm loaded or not.

I am willing to bet that there's still a *lot* of unaudited set[ug]id code
out there that's vulnerable to the same sorts of attacks as the one that
hit Sendmail a few back.  As such, I have to agree with your original
post of the patch that CAP_SYS_ADMIN should be required to lower the set,
as there's just too much danger of an exploit if users can create their
own reduced-set processes.

I'm debating whether we should have a printk if we detect that a removed
capability caused an -EPERM.  Yes, it can be used to spam the logs.  On the
other hand, I as the sysadmin would like to know if it's happening. Looks like
time for a sysctl or something....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: LSM conversion to static interface

[Jan Engelhardt]

As I read through LWN today, I noted the following comment, 
http://lwn.net/Articles/255832/ :

	Personally, I think it's absolutely essential to be able to 
	build a kernel with dynamic LSM. Whether we like it or not, 
	people do want to add in runtime loadable security modules for 
	things like virus scanners, and until upstream offers these 
	folks a viable alternative to LSM...well, they'll use it.

Which reminded me of the TuxGuardian LSM[1] - another of the real-world 
uses to meet Linus's criteria? ("had examples of their real-world use to 
step forward and explain their use")

In this specific project, LSM is used to collect up calls to bind() and 
connect() and pass them to userspace, e.g. do it ZoneAlarm-style and 
display a dialog window. Its codebase is probably not too up-to-date 
(website says last change last April - but I guess that's a no-brainer 
to update it).

[1] http://tuxguardian.sf.net/

Re: LSM conversion to static interface

[Samir Bellabes]

Jan Engelhardt <jengelh@computergmbh.de> writes:

> Which reminded me of the TuxGuardian LSM[1] - another of the real-world 
> uses to meet Linus's criteria? ("had examples of their real-world use to 
> step forward and explain their use")
>
> In this specific project, LSM is used to collect up calls to bind() and 
> connect() and pass them to userspace, e.g. do it ZoneAlarm-style and 
> display a dialog window. Its codebase is probably not too up-to-date 
> (website says last change last April - but I guess that's a no-brainer 
> to update it).
>
> [1] http://tuxguardian.sf.net/

It's not exactly true, tuxguardian is only dealing with .socket_create
and .socket_listen from the struct security_operations, and not
socket_bind

I have done some work in this area since last year, and mailed the
netdev list about it. [1]

the project is 'network events connector' [2]. It's using the LSM
hooks to get interesting informations from syscalls, to push them to
userpace. So differences between projects will be on features and the
code itself.

Before getting a more infos on the project, as a 'LSM user', my main
concern is not that we can unload/load dynamically the security modules,
or have to reboot to do that. I don't have any point on this.

My point is more that the 'user' have to be able to choose which system
is better for him, and by 'user' we can hear linux distros. If
security's modules don't do the same thing, we have to accept to have
multiple modules, ie for example 'the 'network event connector' as a
personnal firewall, and why not another security module for checking 
filesystem. Whitout this approach, tools like mine are pointless for 
linux distros, because there are already working on SELinux, Appamor,
etc.. Not thinking this, is to think that on day, we will have the
perfect and standard security module, but this won't happen, because
users don't want the same thing: "I only want a personnal firewall at
first place, and not a entire role based model".

Now here is more infos on the project, so if not interested so you can
escape now :)

A/ for features:
1/ more hooks
static struct security_operations snet_security_ops = {
        .socket_create          = snet_socket_create,
        .socket_bind            = snet_socket_bind,
        .socket_connect         = snet_socket_connect,
        .socket_listen          = snet_socket_listen,
        .socket_accept          = snet_socket_accept,     
        .socket_post_accept     = snet_socket_post_accept,
        .socket_sendmsg         = snet_socket_sendmsg,
        .socket_recvmsg         = snet_socket_recvmsg,     
        .socket_sock_rcv_skb    = snet_socket_sock_rcv_skb,
};

2/ global control
the main idea behind tuxguardian is preventing rootkit applications 
to execute listen(), so it's warning userspace.

This is really interesting, but I think we can do more than just
that. We can allow in a simple/dynamical way such iptables rules :

iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 --syn -m state --state NEW -j ACCEPT 

just by detecting the sys_listen() call which has been execute by sshd,
and for example only by /usr/bin/sshd (path name based) or 'sshd' role
group (ie SELinux approach), and let packets coming from the network for
this socket to bypass the firewall (of course the user/admin is
controlling it from the userspace).

But we also can control the sys_connect() dynamically from userspace for
example, and prevent application using connect(), regarding the
destination IP address/port, protocol, uid, application (and why not
time, etc).

The main problem and interesting part is the sys_accept(), because only
the LSM hook socket_accept can make the syscall failling. But what
could be interesting is to block/accept the syscall regarding the
remote socket informations (ie which IP address is connecting ?). And
this approch is not possible with the socket_accept hook (it comes too
early) 

Tomoyo tried to solve this by moving the security_socket_post_accept()
before the fd_install() [3]. This is bad for at least two reasons: 
 - this hook was historically not added for this kind of filtering [4]
 - we already have a netfilter tool to help us: libnetfilter_queue [5]

The idea is to send informations about the sys_listen() syscall,
so inform the userspace that a application is maybe waiting for
packets, then using libnetfilter_queue, check packets that match the
socket involved on the sys_listen(). If we have such packet, we can ask
the user to accept or deny this packets.
This approach don't require a modification in the LSM architecture, and 
it's better to use netfilter to deal with packets.

B/ for the code itself:
1/
I'm moving the code from the netlink connector to use generic
netlink/libnl. Tuxguardian is using sock_sendmsg/sock_recvmsg directly

2/
for receiving answers from userspace (I call that "verdict"),
tuxguardian is using sock_recvmsg(), so there is no timeout. I'm using
waitqueue and timers for each "events" sent and "verdict". I'm calling a
event the couple (protocol, syscall) for example (TCP, connect).

there is a documentation/information here [2]. I'm planning to release
next version with genetlink and updated docs on the next week.

thanks,
sam

[1] http://www.spinics.net/lists/netdev/msg24437.html
[2] http://www.synack.fr/project/cn_net/cn_net.html

[3] http://www.mail-archive.com/linux-security-module@vger.kernel.org/msg01393.html

--- linux-2.6.orig/net/socket.c 2007-10-02 11:11:51.000000000 +0900
+++ linux-2.6/net/socket.c      2007-10-02 11:26:23.000000000 +0900
@@ -1434,13 +1434,16 @@ asmlinkage long sys_accept(int fd, struc
                        goto out_fd;
        }
 
+       /* Filter connections from unwanted peers like TCP Wrapper. */
+       err = security_socket_post_accept(sock, newsock);
+       if (err)
+               goto out_fd;
+
        /* File flags are not inherited via accept() unlike another
        OSes. */
 
        fd_install(newfd, newfile);
        err = newfd;
 
-       security_socket_post_accept(sock, newsock);
-
 out_put:
        fput_light(sock->file, fput_needed);
 out:

[4] http://copilotconsulting.com/mail-archives/security-module.2002/msg00186.html
[5] http://www.netfilter.org/projects/libnetfilter_queue/index.html