Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Simon Arlott]

On 24/10/07 13:55, Adrian Bunk wrote:
> On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
>> I currently have an LSM that only handles permissions for socket_bind
>> and socket_listen, I load it and then "capability" as secondary on
>> boot - but now I can't because the LSM framework is now just the LS
>> framework.
>> 
>> Why can't this "static LSM" change be a Kconfig option?
>> (I don't want to have to maintain my own reverted copy of security/,
>> or compile this into the kernel because then I can't ever modify and
>> reload it without rebooting.)
> 
> Let's start with the more important questions:
> 
> Did you submit your LSM for inclusion into the kernel?

No, because the interface for configuring it would be rejected... I have 
a /proc file which I write a binary configuration file to. This works 
fine for me but it would take a lot of work to write a proper interface 
- which I'm still not sure how to do*.

That doesn't solve the problem that it's no longer possible to reload LSM 
modules to make changes at runtime. Why should I have to reboot to change 
something from now on when it works ok? The reasoning seems to be based 
around a dislike of some out of tree modules. (Although it doesn't look 
like there's appropriate locking around the register/unregister process.)


* (I've got a list of access rules which are scanned in order until one of 
them matches, and an array of one bit for every port for per-port default 
allow/deny - although the latter could be removed.
http://svn.lp0.eu/simon/portac/trunk/)

-- 
Simon Arlott

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Oct 24 2007 19:11, Simon Arlott wrote:
>
>* (I've got a list of access rules which are scanned in order until one of 
>them matches, and an array of one bit for every port for per-port default 
>allow/deny - although the latter could be removed.
>http://svn.lp0.eu/simon/portac/trunk/)

Besides the 'feature' of inhibiting port binding,
is not this task of blocking connections something for a firewall?

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Simon Arlott]

On 24/10/07 19:51, Jan Engelhardt wrote:
> On Oct 24 2007 19:11, Simon Arlott wrote:
>>
>>* (I've got a list of access rules which are scanned in order until one of 
>>them matches, and an array of one bit for every port for per-port default 
>>allow/deny - although the latter could be removed.
>>http://svn.lp0.eu/simon/portac/trunk/)
> 
> Besides the 'feature' of inhibiting port binding,
> is not this task of blocking connections something for a firewall?

The firewall blocks incoming connections where appropriate, yes, but it 
doesn't stop one user binding to a port that another user expected to be able 
to use. "Ownership" of ports (1-1023) shouldn't be something only root (via 
CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports 
below 1024 and it's useful to be able to prevent users from binding to them 
too.

-- 
Simon Arlott

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Oct 24 2007 19:59, Simon Arlott wrote:
>On 24/10/07 19:51, Jan Engelhardt wrote:
>> On Oct 24 2007 19:11, Simon Arlott wrote:
>>>
>>>* (I've got a list of access rules which are scanned in order until one of 
>>>them matches, and an array of one bit for every port for per-port default 
>>>allow/deny - although the latter could be removed.
>>>http://svn.lp0.eu/simon/portac/trunk/)
>> 
>> Besides the 'feature' of inhibiting port binding,
>> is not this task of blocking connections something for a firewall?
>
>The firewall blocks incoming connections where appropriate, yes, but it 
>doesn't stop one user binding to a port that another user expected to be able 
>to use. "Ownership" of ports (1-1023) shouldn't be something only root (via 
>CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports 
>below 1024 and it's useful to be able to prevent users from binding to them 
>too.

Indeed.


There has been a feature in the security framework that probably did
not get much attention. It looks like YAGNI first, but on a closer look,
it becomes useful pretty quick - secondary_register.

As more and more simple LSM plugins pop up, stacking/chaining by means
of secondary_register becomes attractive again, especially if these LSMs
target different actions. This is probably the most useful thing why
the LSM interface should remain modular:

# Secure my files
modprobe apparmor
# -*- assuming apparmor implemented secondaries -*-
# Secure my ports
modprobe portac
# More rights to users
modprobe multiadm
# -*- whatever else comes along -*-

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Crispin Cowan]

Jan Engelhardt wrote:
> On Oct 24 2007 19:11, Simon Arlott wrote:
>   
>> * (I've got a list of access rules which are scanned in order until one of 
>> them matches, and an array of one bit for every port for per-port default 
>> allow/deny - although the latter could be removed.
>> http://svn.lp0.eu/simon/portac/trunk/)
>>     
> Besides the 'feature' of inhibiting port binding,
> is not this task of blocking connections something for a firewall?
>   
So now you are criticizing his module. Arguing about the merits of
security semantics. This is exactly why Linus wanted LSM, so we don't
have to have these kinds of discussions, at least not on LKML :)

It seems to me that LSM used to be an open API. Anyone could code to it,
so you could at least try to ship a module that will load into a major
vendor's stock kernel for an important release.

Now with this change, it is effectively a closed API. You can only load
the modules that the distro vendor shipped to you. If you want
*anything* other than what RH or Novell or Canonical or Mandriva etc.
says you should want, then you have to hack the source code for your kernel.

Open source is great, and it is wonderful that you *can* hack the source
if you need to, but demanding that end users patch their source code
when all they want to do is load a module is really, really sad.

Please revert this patch. Its benefits are no where near its costs.

Crispin

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

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Oct 24 2007 13:18, Crispin Cowan wrote:
>Jan Engelhardt wrote:
>> On Oct 24 2007 19:11, Simon Arlott wrote:
>>   
>>> * (I've got a list of access rules which are scanned in order until one of 
>>> them matches, and an array of one bit for every port for per-port default 
>>> allow/deny - although the latter could be removed.
>>> http://svn.lp0.eu/simon/portac/trunk/)
>>>     
>> Besides the 'feature' of inhibiting port binding,
>> is not this task of blocking connections something for a firewall?
>>   
>So now you are criticizing his module. Arguing about the merits of
>security semantics. This is exactly why Linus wanted LSM, so we don't
>have to have these kinds of discussions, at least not on LKML :)

This was a question. I was perfectly aware that iptables alone
does not prohibit binding, and there are reasons to inhibit binding.

But sometimes, a coder does not know where to start - chances are,
that someone else wanting to do bind(2) inhibiting is doing it
with a syscall table change. Or coder did not notice that a firewall
is sufficient for the task to be achieved (which is not always the
case - hence the question).

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[David P. Quigley]

On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> On Oct 24 2007 19:59, Simon Arlott wrote:
> >On 24/10/07 19:51, Jan Engelhardt wrote:
> >> On Oct 24 2007 19:11, Simon Arlott wrote:
> >>>
> >>>* (I've got a list of access rules which are scanned in order until one of 
> >>>them matches, and an array of one bit for every port for per-port default 
> >>>allow/deny - although the latter could be removed.
> >>>http://svn.lp0.eu/simon/portac/trunk/)
> >> 
> >> Besides the 'feature' of inhibiting port binding,
> >> is not this task of blocking connections something for a firewall?
> >
> >The firewall blocks incoming connections where appropriate, yes, but it 
> >doesn't stop one user binding to a port that another user expected to be able 
> >to use. "Ownership" of ports (1-1023) shouldn't be something only root (via 
> >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports 
> >below 1024 and it's useful to be able to prevent users from binding to them 
> >too.
> 
> Indeed.
> 
> 
> There has been a feature in the security framework that probably did
> not get much attention. It looks like YAGNI first, but on a closer look,
> it becomes useful pretty quick - secondary_register.
> 
> As more and more simple LSM plugins pop up, stacking/chaining by means
> of secondary_register becomes attractive again, especially if these LSMs
> target different actions. This is probably the most useful thing why
> the LSM interface should remain modular:
> 
> # Secure my files
> modprobe apparmor
> # -*- assuming apparmor implemented secondaries -*-
> # Secure my ports
> modprobe portac
> # More rights to users
> modprobe multiadm
> # -*- whatever else comes along -*-

There is an issue that you overlook here and it is the successful
composition of security models. While your idea is appealing it presents
several problems. In your example you have 3 models with 3 policies.
AppArmor which has its own port security mechanisms is a MAC model that
from what I have seen appears to have a targeted least privilege policy.
This means that AppArmor picks applications it wishes to secure and
makes sure it can't do anything except what it needs to get its job
done. Your module multiadm takes a user which is completely orthogonal
to the concepts that AppArmor uses and gives him extra privileges. From
what I have read and correct me if I am wrong portac deals with users
instead of programs. Now lets try to reconcile this in a way that is
sane to the user/administrator.

Apparmor wants to lock down some application, it gives the application
access to a particular port, and the minimal set of privileges needed to
execute the application. Since Apparmor is "easy to use" (note the
quotes are to indicate they aren't my words not sarcasm) and SUSE comes
with a targeted policy the user isn't concerned with it. Now multiadm
comes along and an administrator wishes to grant extra rights to a user.
This is fine with multiadm alone since it is the main security module,
however we now have to compose this with AppArmor. So an administrator
runs into an error running his application. Is this because his user
isn't granted the proper escalated privileges? Is it because AppArmor
needs an extra rule to run the application?  It could also be that our
third module has blocked the application because it determined that even
though multiadm specified that the user should have the elevated
privileges to run the application that user shouldn't be able to bind to
that port. 

There might be a better example to illustrate the problem however, this
simple example shows the interdependency of three seemingly simple
modules. Imagine what happens when people really let loose and implement
all sorts of crazy ideas and stack them on top of each other. Stacking
works in things such as file systems because we have a clearly defined
interface with fixed solid semantics. You could attempt to do that but
once you have modules that step on each others toes you have to figure
out a way to reconcile that. It seems to me that you're going to
introduce usability problems that are hard to deal with.

Dave Quigley

> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

I have written Smack.
I need an LSM infrastructure.
I would prefer the old dynamic version.
I no trouble with the static version.

I think that a dynamic version is more useful, but I didn't want
what I'm doing to have it as a dependency, so I made sure that
it isn't. The debate about the inclusion of Smack can remain
blissfully separate from the dynamic/static LSM debate. This is
by design.

I have had a couple people suggest changes to Smack that would be
very elegently handled as stacked modules. These include "owned"
ports and additional uid restrictions. Since Smack is a MAC module
these other security features are not really appropriate to include
(if you want the Security Monolith there is SELinux) in it, but
certainly make sense to combine with it.

A stacker that does not require module participation could be quite
interesting. In the old day I felt that a security solution had to
include all aspects of control, but today I see the value provided
by independent mechanisms such as IPtables.



Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Serge E. Hallyn]

Quoting David P. Quigley (dpquigl@tycho.nsa.gov):
> On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > On Oct 24 2007 19:59, Simon Arlott wrote:
> > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > >>>
> > >>>* (I've got a list of access rules which are scanned in order until one of 
> > >>>them matches, and an array of one bit for every port for per-port default 
> > >>>allow/deny - although the latter could be removed.
> > >>>http://svn.lp0.eu/simon/portac/trunk/)
> > >> 
> > >> Besides the 'feature' of inhibiting port binding,
> > >> is not this task of blocking connections something for a firewall?
> > >
> > >The firewall blocks incoming connections where appropriate, yes, but it 
> > >doesn't stop one user binding to a port that another user expected to be able 
> > >to use. "Ownership" of ports (1-1023) shouldn't be something only root (via 
> > >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports 
> > >below 1024 and it's useful to be able to prevent users from binding to them 
> > >too.
> > 
> > Indeed.
> > 
> > 
> > There has been a feature in the security framework that probably did
> > not get much attention. It looks like YAGNI first, but on a closer look,
> > it becomes useful pretty quick - secondary_register.
> > 
> > As more and more simple LSM plugins pop up, stacking/chaining by means
> > of secondary_register becomes attractive again, especially if these LSMs
> > target different actions. This is probably the most useful thing why
> > the LSM interface should remain modular:
> > 
> > # Secure my files
> > modprobe apparmor
> > # -*- assuming apparmor implemented secondaries -*-
> > # Secure my ports
> > modprobe portac
> > # More rights to users
> > modprobe multiadm
> > # -*- whatever else comes along -*-
> 
> There is an issue that you overlook here and it is the successful
> composition of security models. While your idea is appealing it presents
> several problems. In your example you have 3 models with 3 policies.
> AppArmor which has its own port security mechanisms is a MAC model that
> from what I have seen appears to have a targeted least privilege policy.
> This means that AppArmor picks applications it wishes to secure and
> makes sure it can't do anything except what it needs to get its job
> done. Your module multiadm takes a user which is completely orthogonal
> to the concepts that AppArmor uses and gives him extra privileges. From
> what I have read and correct me if I am wrong portac deals with users
> instead of programs. Now lets try to reconcile this in a way that is
> sane to the user/administrator.
> 
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> with a targeted policy the user isn't concerned with it. Now multiadm
> comes along and an administrator wishes to grant extra rights to a user.
> This is fine with multiadm alone since it is the main security module,
> however we now have to compose this with AppArmor. So an administrator
> runs into an error running his application. Is this because his user
> isn't granted the proper escalated privileges? Is it because AppArmor
> needs an extra rule to run the application?  It could also be that our
> third module has blocked the application because it determined that even
> though multiadm specified that the user should have the elevated
> privileges to run the application that user shouldn't be able to bind to
> that port. 
> 
> There might be a better example to illustrate the problem however, this

The scariest thing to consider is programs which don't appropriately
handle failure.  So I don't know, maybe the system runs a remote logger
to which the multiadm policy gives some extra privs, but now the portac
module prevents it from sending its data.  And maybe, since the authors
never saw this failure as possible, the program happens to dump
sensitive data in a public readable place.  I *could* be more vague but
it'd be tough :)  But you get the idea.

Or, a better example, a privileged program reads some sensitive data -
as allowed by multiadm, writes it to a file, but apparmor prevented it
from chowning the file to the right user before writing, the program
kept writing anyway, and now the calling user hallyn, rather than the
privileged user sensitive_log_t, owns the file.

I ran into examples of this with the stacker module.  For instance
suddenly the capability module had to be changed so that it would allow
selinux xattrs to be written - leaving that arbitration to selinux.
That hadn't been necessary before since selinux simply didn't explicitly
call the secondary->inode_setxattr() hook.

Note I'm not arguing for or against, only arguing for caution :)

-serge

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Oct 24 2007 17:02, David P. Quigley wrote:
>> 
>> There has been a feature in the security framework that probably did
>> not get much attention. It looks like YAGNI first, but on a closer look,
>> it becomes useful pretty quick - secondary_register.
>> 
>> As more and more simple LSM plugins pop up, stacking/chaining by means
>> of secondary_register becomes attractive again, especially if these LSMs
>> target different actions. This is probably the most useful thing why
>> the LSM interface should remain modular:
>> 
>> # Secure my files
>> modprobe apparmor
>> # -*- assuming apparmor implemented secondaries -*-
>> # Secure my ports
>> modprobe portac
>> # More rights to users
>> modprobe multiadm
>> # -*- whatever else comes along -*-

>Apparmor wants to lock down some application, it gives the application
>access to a particular port, and the minimal set of privileges needed to
>execute the application. [...]
>however we now have to compose this with AppArmor. So an administrator
>runs into an error running his application. Is this because his user
>isn't granted the proper escalated privileges? Is it because AppArmor
>needs an extra rule to run the application?

Of course, the example I gave assumed that each LSM had disjunctive
features. Apparmor is primarily known for blocking file access,
and portac for blocking bind(2). If one of these gets additionaly
functionality, it would be nice that code gets combined so that
tracking down the piece of code that caused a particular syscall to
say nay is easier to pinpoint.

>It could also be that our third module has blocked the application
>because it determined that even though multiadm specified that the
>user should have the elevated privileges to run the application that
>user shouldn't be able to bind to that port.
>[...] Stacking works in things such as file systems because we have
>a clearly defined interface with fixed solid semantics. You could
>attempt to do that but once you have modules that step on each
>others toes you have to figure out a way to reconcile that.

I agree - if one does not get the magic behind LSM stacking, s/he
should not use it, or learn to use it.
However, if you grasp how it works (probably even easier to learn
than figuring out how to selinux), one should know that a pam_deny.so
even after a pam_permit.so will lock you down. Yeah, it's like PAM
stacking.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Oct 24 2007 16:37, Serge E. Hallyn wrote:
>
>Or, a better example, a privileged program reads some sensitive data -
>as allowed by multiadm, writes it to a file, but apparmor prevented it
>from chowning the file to the right user before writing,

Interesting find, I should pay attention to that :-)

But - note to dquigley - AFAICS, an LSM needs to _explicitly_ call
the next LSM's function. No one (just a minimal grep in
linux-2.6/security/) besides SELinux does that today. So
while you could load AppArmor ontop of MultiAdm, it would never
be invoked. This is what is known as "sufficient" in PAM parlance.
SELinux OTOH is in "required" mode [again PAM-speak].

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- "David P. Quigley" <dpquigl@tycho.nsa.gov> wrote:

> On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > On Oct 24 2007 19:59, Simon Arlott wrote:
> > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > >>>
> > >>>* (I've got a list of access rules which are scanned in order until one
> of 
> > >>>them matches, and an array of one bit for every port for per-port
> default 
> > >>>allow/deny - although the latter could be removed.
> > >>>http://svn.lp0.eu/simon/portac/trunk/)
> > >> 
> > >> Besides the 'feature' of inhibiting port binding,
> > >> is not this task of blocking connections something for a firewall?
> > >
> > >The firewall blocks incoming connections where appropriate, yes, but it 
> > >doesn't stop one user binding to a port that another user expected to be
> able 
> > >to use. "Ownership" of ports (1-1023) shouldn't be something only root
> (via 
> > >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports
> 
> > >below 1024 and it's useful to be able to prevent users from binding to
> them 
> > >too.
> > 
> > Indeed.
> > 
> > 
> > There has been a feature in the security framework that probably did
> > not get much attention. It looks like YAGNI first, but on a closer look,
> > it becomes useful pretty quick - secondary_register.
> > 
> > As more and more simple LSM plugins pop up, stacking/chaining by means
> > of secondary_register becomes attractive again, especially if these LSMs
> > target different actions. This is probably the most useful thing why
> > the LSM interface should remain modular:
> > 
> > # Secure my files
> > modprobe apparmor
> > # -*- assuming apparmor implemented secondaries -*-
> > # Secure my ports
> > modprobe portac
> > # More rights to users
> > modprobe multiadm
> > # -*- whatever else comes along -*-
> 
> There is an issue that you overlook here and it is the successful
> composition of security models. While your idea is appealing it presents
> several problems. In your example you have 3 models with 3 policies.
> AppArmor which has its own port security mechanisms is a MAC model that
> from what I have seen appears to have a targeted least privilege policy.
> This means that AppArmor picks applications it wishes to secure and
> makes sure it can't do anything except what it needs to get its job
> done. Your module multiadm takes a user which is completely orthogonal
> to the concepts that AppArmor uses and gives him extra privileges. From
> what I have read and correct me if I am wrong portac deals with users
> instead of programs. Now lets try to reconcile this in a way that is
> sane to the user/administrator.
> 
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> with a targeted policy the user isn't concerned with it. Now multiadm
> comes along and an administrator wishes to grant extra rights to a user.
> This is fine with multiadm alone since it is the main security module,
> however we now have to compose this with AppArmor. So an administrator
> runs into an error running his application. Is this because his user
> isn't granted the proper escalated privileges? Is it because AppArmor
> needs an extra rule to run the application?  It could also be that our
> third module has blocked the application because it determined that even
> though multiadm specified that the user should have the elevated
> privileges to run the application that user shouldn't be able to bind to
> that port. 
> 
> There might be a better example to illustrate the problem however, this
> simple example shows the interdependency of three seemingly simple
> modules. Imagine what happens when people really let loose and implement
> all sorts of crazy ideas and stack them on top of each other. Stacking
> works in things such as file systems because we have a clearly defined
> interface with fixed solid semantics. You could attempt to do that but
> once you have modules that step on each others toes you have to figure
> out a way to reconcile that. It seems to me that you're going to
> introduce usability problems that are hard to deal with.
> 
> Dave Quigley

Two very important things to consider:

The LSM is designed to be a restrictive mechanism. An LSM module
is not allowed to grant access that would be denied by usual
mechanisms. There are composition problems, but nothing that is
worse than the problems you have to deal with when a filesystem
is mounted read-only. True, one LSM module could muck with the
data used by another, but that's something you can do today with
setxattr() calls in an application.

Which brings up the second important point. The argument above
has nothing whatever to do with mechanisms provided by the kernel
and everything to do with the privileged applications used to
administer a system. Those applications need to be written so as
to deal properly with unexpected access failures, such as might
be induced by a filesystem mounted read-only or being full. I
am aware of the Holy Grail of a security package that does not
interfere with the operation of "normal" administration. How close
you can come to that in independent of wether your kernel is
an integrated "security solution" or a collection of composed
modules.

This discussion is amazingly disconnected from the issues of LSM.


Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[David P. Quigley]

On Wed, 2007-10-24 at 23:51 +0200, Jan Engelhardt wrote:
> On Oct 24 2007 16:37, Serge E. Hallyn wrote:
> >
> >Or, a better example, a privileged program reads some sensitive data -
> >as allowed by multiadm, writes it to a file, but apparmor prevented it
> >from chowning the file to the right user before writing,
> 
> Interesting find, I should pay attention to that :-)
> 
> But - note to dquigley - AFAICS, an LSM needs to _explicitly_ call
> the next LSM's function. No one (just a minimal grep in
> linux-2.6/security/) besides SELinux does that today. So
> while you could load AppArmor ontop of MultiAdm, it would never
> be invoked. This is what is known as "sufficient" in PAM parlance.
> SELinux OTOH is in "required" mode [again PAM-speak].

True but if we are talking about a true stackable architecture calling
down to your lower component shouldn't be an option it should be a
requirement of the semantics. I would hate to think some module which is
a subset of the restrictiveness of another could override it because its
"sufficient". If that was the case I could load in a module which just
returns 0 for everything and make it "sufficient" bypassing every other
module. This also introduces ordering dependencies. If you install
MultiAdm before AppArmor or SELinux and make it "sufficient" then you
defeated the point of having AppArmor or SELinux installed in the first
place. 

Dave

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[David P. Quigley]

On Wed, 2007-10-24 at 14:58 -0700, Casey Schaufler wrote:
> --- "David P. Quigley" <dpquigl@tycho.nsa.gov> wrote:
> 
> > On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > > On Oct 24 2007 19:59, Simon Arlott wrote:
> > > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > > >>>
> > > >>>* (I've got a list of access rules which are scanned in order until one
> > of 
> > > >>>them matches, and an array of one bit for every port for per-port
> > default 
> > > >>>allow/deny - although the latter could be removed.
> > > >>>http://svn.lp0.eu/simon/portac/trunk/)
> > > >> 
> > > >> Besides the 'feature' of inhibiting port binding,
> > > >> is not this task of blocking connections something for a firewall?
> > > >
> > > >The firewall blocks incoming connections where appropriate, yes, but it 
> > > >doesn't stop one user binding to a port that another user expected to be
> > able 
> > > >to use. "Ownership" of ports (1-1023) shouldn't be something only root
> > (via 
> > > >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports
> > 
> > > >below 1024 and it's useful to be able to prevent users from binding to
> > them 
> > > >too.
> > > 
> > > Indeed.
> > > 
> > > 
> > > There has been a feature in the security framework that probably did
> > > not get much attention. It looks like YAGNI first, but on a closer look,
> > > it becomes useful pretty quick - secondary_register.
> > > 
> > > As more and more simple LSM plugins pop up, stacking/chaining by means
> > > of secondary_register becomes attractive again, especially if these LSMs
> > > target different actions. This is probably the most useful thing why
> > > the LSM interface should remain modular:
> > > 
> > > # Secure my files
> > > modprobe apparmor
> > > # -*- assuming apparmor implemented secondaries -*-
> > > # Secure my ports
> > > modprobe portac
> > > # More rights to users
> > > modprobe multiadm
> > > # -*- whatever else comes along -*-
> > 
> > There is an issue that you overlook here and it is the successful
> > composition of security models. While your idea is appealing it presents
> > several problems. In your example you have 3 models with 3 policies.
> > AppArmor which has its own port security mechanisms is a MAC model that
> > from what I have seen appears to have a targeted least privilege policy.
> > This means that AppArmor picks applications it wishes to secure and
> > makes sure it can't do anything except what it needs to get its job
> > done. Your module multiadm takes a user which is completely orthogonal
> > to the concepts that AppArmor uses and gives him extra privileges. From
> > what I have read and correct me if I am wrong portac deals with users
> > instead of programs. Now lets try to reconcile this in a way that is
> > sane to the user/administrator.
> > 
> > Apparmor wants to lock down some application, it gives the application
> > access to a particular port, and the minimal set of privileges needed to
> > execute the application. Since Apparmor is "easy to use" (note the
> > quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> > with a targeted policy the user isn't concerned with it. Now multiadm
> > comes along and an administrator wishes to grant extra rights to a user.
> > This is fine with multiadm alone since it is the main security module,
> > however we now have to compose this with AppArmor. So an administrator
> > runs into an error running his application. Is this because his user
> > isn't granted the proper escalated privileges? Is it because AppArmor
> > needs an extra rule to run the application?  It could also be that our
> > third module has blocked the application because it determined that even
> > though multiadm specified that the user should have the elevated
> > privileges to run the application that user shouldn't be able to bind to
> > that port. 
> > 
> > There might be a better example to illustrate the problem however, this
> > simple example shows the interdependency of three seemingly simple
> > modules. Imagine what happens when people really let loose and implement
> > all sorts of crazy ideas and stack them on top of each other. Stacking
> > works in things such as file systems because we have a clearly defined
> > interface with fixed solid semantics. You could attempt to do that but
> > once you have modules that step on each others toes you have to figure
> > out a way to reconcile that. It seems to me that you're going to
> > introduce usability problems that are hard to deal with.
> > 
> > Dave Quigley
> 
> Two very important things to consider:
> 
> The LSM is designed to be a restrictive mechanism. An LSM module
> is not allowed to grant access that would be denied by usual
> mechanisms. There are composition problems, but nothing that is
> worse than the problems you have to deal with when a filesystem
> is mounted read-only. True, one LSM module could muck with the
> data used by another, but that's something you can do today with
> setxattr() calls in an application.
> 
> Which brings up the second important point. The argument above
> has nothing whatever to do with mechanisms provided by the kernel
> and everything to do with the privileged applications used to
> administer a system. Those applications need to be written so as
> to deal properly with unexpected access failures, such as might
> be induced by a filesystem mounted read-only or being full. I
> am aware of the Holy Grail of a security package that does not
> interfere with the operation of "normal" administration. How close
> you can come to that in independent of wether your kernel is
> an integrated "security solution" or a collection of composed
> modules.
> 
> This discussion is amazingly disconnected from the issues of LSM.

This branch of the tree seems to have gone in a direction similar to the
stackable netfilter like architecture that was suggested by someone last
time this came up.

> 
> 
> Casey Schaufler
> casey@schaufler-ca.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Adrian Bunk]

On Wed, Oct 24, 2007 at 07:11:17PM +0100, Simon Arlott wrote:
> On 24/10/07 13:55, Adrian Bunk wrote:
> > On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
> >> I currently have an LSM that only handles permissions for socket_bind
> >> and socket_listen, I load it and then "capability" as secondary on
> >> boot - but now I can't because the LSM framework is now just the LS
> >> framework.
> >> 
> >> Why can't this "static LSM" change be a Kconfig option?
> >> (I don't want to have to maintain my own reverted copy of security/,
> >> or compile this into the kernel because then I can't ever modify and
> >> reload it without rebooting.)
> > 
> > Let's start with the more important questions:
> > 
> > Did you submit your LSM for inclusion into the kernel?
> 
> No, because the interface for configuring it would be rejected... I have 
> a /proc file which I write a binary configuration file to. This works 
> fine for me but it would take a lot of work to write a proper interface 
> - which I'm still not sure how to do*.
>...

Generally, the goal is to get external modules included into the kernel.

You want to be able to have this functionality and you do not want to 
use SELinux for it.

But instead of working on getting your code into the kernel you are 
requesting that an API making it easier for you to maintain it 
externally comes back.

There are other points in this thread that might or might not warrant 
making LSM modular again, but even though it might sound harsh breaking 
external modules and thereby making people aware that their code should 
get into the kernel is IMHO a positive point.

> Simon Arlott

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: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Adrian Bunk <bunk@kernel.org> wrote:

> ...
> 
> There are other points in this thread that might or might not warrant 
> making LSM modular again, but even though it might sound harsh breaking 
> external modules and thereby making people aware that their code should 
> get into the kernel is IMHO a positive point.

Those proposing LSM modules over the past couple years have
been treated most harshly. I have personally taken the least
flak of anyone on my proposal, and at that there have been
times where I felt like pulling out the #5 clue stick and
taking a few swings. It's no wonder that people are afraid
to suggest a module. I didn't do it until I had combed through
the archives and prepared answers for the most common attacks.
I hope that Smack moving forward will defuse some of the bad
vibes that have clouded the LSM for so long. I don't blame
anyone who kept their module to themself given the hostility
which even successful products have encountered.

And don't give me the old "LKML is a tough crowd" feldercarb.
Security modules have been much worse. Innovation, even in
security, is a good thing and treating people harshly, even
"for their own good", is an impediment to innovation.


Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Oct 24 2007 18:02, David P. Quigley wrote:
>> 
>> But an LSM needs to _explicitly_ call the next LSM's function. No
>> one (just a minimal grep in linux-2.6/security/) besides SELinux
>> does that today. So while you could load AppArmor ontop of
>> MultiAdm, it would never be invoked. This is what is known as
>> "sufficient" in PAM parlance.
>
>I would hate to think some module which is a subset of the
>restrictiveness of another could override it because its
>"sufficient". If that was the case I could load in a module which
>just returns 0 for everything and make it "sufficient" bypassing
>every other module. This also introduces ordering dependencies. If
>you install MultiAdm before AppArmor or SELinux and make it
>"sufficient" then you defeated the point of having AppArmor or
>SELinux installed in the first place.

If I had to run mtadm and aa alongside each other, I would put aa
into the "secondary" LSM slot.

A number of people have said by now that LSM is supposed to be a
restrict-my-rights block of code. As such, I would put the special,
tiny, give-me-rights code at the front so that it be executed first.
This is what would be intended with mtadm. It really just gives you a
few caps when switching to UID 900 (or whatever), just as Linux
traditionally gives you full caps when switching to UID 0 (e.g. by
executing setuid files). From there on, it is just restrictions, and
the order in which LSMs restrict your actions is probably not so
important as long as they do restrict it.

Thankfully, Linux capabilities are so strangely designed that they
actually become useful - they give you so much power that you _can_
only restrict things afterwards again :-)

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Adrian Bunk]

On Wed, Oct 24, 2007 at 03:58:02PM -0700, Casey Schaufler wrote:
> 
> --- Adrian Bunk <bunk@kernel.org> wrote:
> 
> > ...
> > 
> > There are other points in this thread that might or might not warrant 
> > making LSM modular again, but even though it might sound harsh breaking 
> > external modules and thereby making people aware that their code should 
> > get into the kernel is IMHO a positive point.
> 
> Those proposing LSM modules over the past couple years have
> been treated most harshly. I have personally taken the least
> flak of anyone on my proposal, and at that there have been
> times where I felt like pulling out the #5 clue stick and
> taking a few swings. It's no wonder that people are afraid
> to suggest a module. I didn't do it until I had combed through
> the archives and prepared answers for the most common attacks.
> I hope that Smack moving forward will defuse some of the bad
> vibes that have clouded the LSM for so long. I don't blame
> anyone who kept their module to themself given the hostility
> which even successful products have encountered.
> 
> And don't give me the old "LKML is a tough crowd" feldercarb.
> Security modules have been much worse. Innovation, even in
> security, is a good thing and treating people harshly, even
> "for their own good", is an impediment to innovation.

What I'm giving you is "Linus has decreed there can be LSMs other than 
SELinux."

Getting LSMs included should no longer be harder than for other 
parts of the kernel.

And don't get me wrong, I'm not saying my point should decide this 
discussion. It's simply the point that making it harder for external 
code also has advantages.

> Casey Schaufler

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: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Linus Torvalds]

On Thu, 25 Oct 2007, Adrian Bunk wrote:
> 
> What I'm giving you is "Linus has decreed there can be LSMs other than 
> SELinux."
> 
> Getting LSMs included should no longer be harder than for other 
> parts of the kernel.

Well, despite my heart-felt feelings that we should support different 
people in trying out different things, one of the issues is also that I'm 
obviously not myself a security person. I can "decree" all I want, but in 
the end, I really want the people *involved* to merge security stuff. 

Right now Chris Wrigt is the documented maintainer for LSM, and quite 
frankly, I do not want to take it over. I really really really hope that
people that are interested in security can work this thing out, and my 
only requirement is that it doesn't end up being any kind of force-feeding 
of opinions and ideas, since clearly there is tons of room for 
disagreement in the area..

Do other people want to stand up and be "LSM maintainers" in the sense 
that they also end up being informed members who can also stand up for new 
modules and help merge them, rather than just push the existing one(s)? 
Chris? Casey? Crispin?

[ Ie there's the "core LSM hooks" on one side, but there's also the "what 
  modules make any sense at all to merge?" on the other, and I really 
  don't have the expertise to make any sensible judgements except for the 
  pure "process" judgement that we should not hardcode things to just one 
  module! ]

		Linus

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Chris Wright]

* Casey Schaufler (casey@schaufler-ca.com) wrote:
> And don't give me the old "LKML is a tough crowd" feldercarb.
> Security modules have been much worse. Innovation, even in
> security, is a good thing and treating people harshly, even
> "for their own good", is an impediment to innovation.

I agree that innovation is critical to the success of Linux, and security
is not immune to that.  The trouble is that most of the security modules
that have come forward have had some real serious shortcomings.  I do
believe it is prudent to keep in-tree security sensitive code under
high scrutiny because we do not want to create security holes by adding
problematic security code.

thanks,
-chris

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Ray Lee]

On 10/24/07, Chris Wright <chrisw@sous-sol.org> wrote:
> * Casey Schaufler (casey@schaufler-ca.com) wrote:
> > And don't give me the old "LKML is a tough crowd" feldercarb.
> > Security modules have been much worse. Innovation, even in
> > security, is a good thing and treating people harshly, even
> > "for their own good", is an impediment to innovation.
>
> I agree that innovation is critical to the success of Linux, and security
> is not immune to that.  The trouble is that most of the security modules
> that have come forward have had some real serious shortcomings.

Key-based masterlocks are easily broken with freon, and their combo
locks are easily brute-forced in about ten minutes. Yet, I'll still
use them to lock up my bike and garage.

The idea that poor security is worse than no security is fallacious,
and not backed up by common experience.

> I do
> believe it is prudent to keep in-tree security sensitive code under
> high scrutiny because we do not want to create security holes by adding
> problematic security code.

If security code actively *adds* holes, then that's obviously a deal breaker.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Chris Wright]

* Linus Torvalds (torvalds@linux-foundation.org) wrote:
> Do other people want to stand up and be "LSM maintainers" in the sense 
> that they also end up being informed members who can also stand up for new 
> modules and help merge them, rather than just push the existing one(s)? 
> Chris? Casey? Crispin?

Stephen and James, despite their clear bias towards SELinux, do try to
give good feedback.  But you are right, there's not enough active help
for people trying to make a contribution to get their code in shape.
Many of the modules that come along have been misguided conceptually,
but I think that e.g. apparmor, tomoyo, smack could use that kind
of constructive help to get into final mergable shape.  Personally,
I haven't spent nearly enough time reviewing those, my apologies to
those developers.  So, yes, help is welcome.

thanks,
-chris

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Thu, 25 Oct 2007, Adrian Bunk wrote:
> > 
> > What I'm giving you is "Linus has decreed there can be LSMs other than 
> > SELinux."
> > 
> > Getting LSMs included should no longer be harder than for other 
> > parts of the kernel.
> 
> Well, despite my heart-felt feelings that we should support different 
> people in trying out different things, one of the issues is also that I'm 
> obviously not myself a security person. I can "decree" all I want, but in 
> the end, I really want the people *involved* to merge security stuff. 
> 
> Right now Chris Wrigt is the documented maintainer for LSM, and quite 
> frankly, I do not want to take it over. I really really really hope that
> people that are interested in security can work this thing out, and my 
> only requirement is that it doesn't end up being any kind of force-feeding 
> of opinions and ideas, since clearly there is tons of room for 
> disagreement in the area..
> 
> Do other people want to stand up and be "LSM maintainers" in the sense 
> that they also end up being informed members who can also stand up for new 
> modules and help merge them, rather than just push the existing one(s)? 
> Chris? Casey? Crispin?

Count me in.

> [ Ie there's the "core LSM hooks" on one side, but there's also the "what 
>   modules make any sense at all to merge?" on the other, and I really 
>   don't have the expertise to make any sensible judgements except for the 
>   pure "process" judgement that we should not hardcode things to just one 
>   module! ]
> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 


Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

I have different deal breakers.

If a LSM is something simple/commonly required it should be made like
posix file capability's provided to all to use.   Sorry to say I see
the file protection in apparmor as something everyone should be able
to use at will like posix file capability's.  All enforcement features
should be common.

I see a LSM as a director commander its reason for existence is to
read security configs and hand them permissions and respond to
problems.   Any enforcement should be default in kernel.

So LSM could be roll based, mac or any other model.  Current problem
enforcement and guiding are mixed up in one block.  So evolution is
not happening.

The enforcing bits of LSM's should be a simple no brainier addons to
the Linux kernel.  The problem is at moment they are mixed up with Mac
....  A security model to use has to be picked to suit job.   Role
Based can be Better than Mac and Mac can be better than Role based.
It all depends on what you are defending.

Thing common all need to protect suid, file access, network access...
The bits you need to defend don't change if or if not you are running
a LSM.  So why are these bits bottled up inside LSM forcing people to
choose the wrong security model for there task to get protection at
times.

There can never be one LSM to do every job.   But the big but all the
common bits to protect every job could be in kernel.  Only thing
missing is the director.

This is exactly the same problem Virtual Server solutions had when
then wanted to get into the kernel.   At least the Virtual Server
solutions were not as pig headed as some of the LSM guys about it.
Where its all in or not in at all.   Little bits into kernel is better
than nothing.

Really this will sound bad if I had my way I would kick all LSM's out
of the main kernel tree until they learn to work with each other to
share bits.  We don't need 10 copies of protect files from access.  Or
10 copies of limit what .so a application and interface with and so
on.

It worked with Virtual Servers to get them to sit down and start
talking.  What we really need working on is system wide security.  No
bothering a lot about the little box of LSM.

Yes I am not nice to LSM.   I see them as bitrot.  They are going to
cause containers problems in there current form as containers evolve.
They are not improving the base line security level.  Yes selinux
saying make me default to improve secuity says that in selinux there
are parts that should be chopped out and made default.  But since it
contains a security model it cannot be all made default because it
just will not fit everywhere.

Basically a LSM should make it simpler to run security tight.  The big
all mighty but it should not alter achievable security.  If its
altering achievable security main kernel is missing features and
someone needs to slice and dice that LSM.

Peter Dolding

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Alan Cox]

> The idea that poor security is worse than no security is fallacious,
> and not backed up by common experience.

There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security at all.
In particular stuff which makes users think they are secure but is
worthless is very dangerous indeed.

When you know that security is limited you act appropriately, when you
believe security is good but it is not you take inappropriate risks and
get badly burned.

Alan

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Chris Wright <chrisw@sous-sol.org> wrote:

> * Casey Schaufler (casey@schaufler-ca.com) wrote:
> > And don't give me the old "LKML is a tough crowd" feldercarb.
> > Security modules have been much worse. Innovation, even in
> > security, is a good thing and treating people harshly, even
> > "for their own good", is an impediment to innovation.
> 
> I agree that innovation is critical to the success of Linux, and security
> is not immune to that.  The trouble is that most of the security modules
> that have come forward have had some real serious shortcomings.  I do
> believe it is prudent to keep in-tree security sensitive code under
> high scrutiny because we do not want to create security holes by adding
> problematic security code.

I agree that security code does need to provide security. What we
need to get away from is the automatic attacks that are based on 20th
century computer system assumptions. Things like "name based access
control is rediculous", and "a module can't be any good if it doesn't
deal with all objects", or "the granularity isn't fine enough". Look
at TOMOYO. It's chuck full of good ideas. Why spend so much energy
badgering them about not dealing with sockets? How about helping the
AppArmor crew come up with acceptable implementations rather than
whinging about the evils of hard links? And maybe, just maybe, we can
get away from the inevitable claim that you could do that with a few
minutes work in SELinux policy, but only if you're a security
professional of course.

Sure, some LSM proposals will be lousy, and some really will be
better done as an SELinux policy module. Some will even have merit
but require unreasonable interface changes. As people who care
about security (y'all who are only from the LKML are excused) it
is our obligation to look beyond the preconceived notions of what
is and isn't secure. Security is subjective. It's how you feel
about it.



Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[david]

On Wed, 24 Oct 2007, Serge E. Hallyn wrote:

> The scariest thing to consider is programs which don't appropriately
> handle failure.  So I don't know, maybe the system runs a remote logger
> to which the multiadm policy gives some extra privs, but now the portac
> module prevents it from sending its data.  And maybe, since the authors
> never saw this failure as possible, the program happens to dump
> sensitive data in a public readable place.  I *could* be more vague but
> it'd be tough :)  But you get the idea.
>
> Or, a better example, a privileged program reads some sensitive data -
> as allowed by multiadm, writes it to a file, but apparmor prevented it
> from chowning the file to the right user before writing, the program
> kept writing anyway, and now the calling user hallyn, rather than the
> privileged user sensitive_log_t, owns the file.
>
> I ran into examples of this with the stacker module.  For instance
> suddenly the capability module had to be changed so that it would allow
> selinux xattrs to be written - leaving that arbitration to selinux.
> That hadn't been necessary before since selinux simply didn't explicitly
> call the secondary->inode_setxattr() hook.
>
> Note I'm not arguing for or against, only arguing for caution :)

this sort of problem is possible with just a single LSM.

remember that unix doesn't try to make it impossible for the system owner 
to hang himself, becouse there are many other cases where the rope is used 
productivly. don't let the possibility that things can be done wrong 
prevent other people from being creative in ways that you never thought 
of.

David Lang

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[david]

On Thu, 25 Oct 2007, Alan Cox wrote:

>> The idea that poor security is worse than no security is fallacious,
>> and not backed up by common experience.
>
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.
> In particular stuff which makes users think they are secure but is
> worthless is very dangerous indeed.

there is also pleanty of evidence that you don't have to be perfect to be 
good enough.

in addition security is useually traded off for something else 
(useability, administrative effort, money, etc) and depending on what's 
being protected the cost that's appropriate is going to be different.

> When you know that security is limited you act appropriately, when you
> believe security is good but it is not you take inappropriate risks and
> get badly burned.

This is very true, but the solution isn't to try and eliminate everything 
other then perfect security, it's to properly document the limitations of 
various options and educate people about them.

David Lang

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Arjan van de Ven]

On Wed, 24 Oct 2007 17:41:28 -0700
Chris Wright <chrisw@sous-sol.org> wrote:

> * Linus Torvalds (torvalds@linux-foundation.org) wrote:
> > Do other people want to stand up and be "LSM maintainers" in the
> > sense that they also end up being informed members who can also
> > stand up for new modules and help merge them, rather than just push
> > the existing one(s)? Chris? Casey? Crispin?
> 
> Stephen and James, despite their clear bias towards SELinux, do try to
> give good feedback.  But you are right, there's not enough active help
> for people trying to make a contribution to get their code in shape.
> Many of the modules that come along have been misguided conceptually,
> but I think that e.g. apparmor, tomoyo, smack could use that kind
> of constructive help to get into final mergable shape.  Personally,
> I haven't spent nearly enough time reviewing those, my apologies to
> those developers.  So, yes, help is welcome.
> 

I'll be happy to help out; I'd consider my self neutral in this space
not having worked with any of the LSM out there. I do think we need to
be somewhat critical to what we accept; we should at least be able to
filter out "pretend security" somehow. (this is not the same as saying
that you're bad if you only provide a limited security, in the
contrary, I strongly believe in simple pieces. What I mean is that we
should be critical to things that appear/claim to be strong but are
not).

Secondly, we should make sure that no new holes are added (the original
SMACK series suffered from this, Al Viro helped getting that reviewed
bigtime).

In addition we probably should strive to getting some sort of rough
"this is sort of where we draw the line" guideline set up, just to keep
things more objective.

(Oh and of course, if a security module is deeply involved in another
kernel subsystem, say networking or the VFS, very obviously we should
consult and listen to the respective maintainers of that subsystem; LSM
is not there to be a big hook to bypass the process of well maintained
subsystems)

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Kyle Moffett]

On Oct 24, 2007, at 17:37:04, Serge E. Hallyn wrote:
> The scariest thing to consider is programs which don't  
> appropriately handle failure.  So I don't know, maybe the system  
> runs a remote logger to which the multiadm policy gives some extra  
> privs, but now the portac module prevents it from sending its  
> data.  And maybe, since the authors never saw this failure as  
> possible, the program happens to dump sensitive data in a public  
> readable place.  I *could* be more vague but it'd be tough :)  But  
> you get the idea.

Well, there *was* that problem with sendmail where it did not  
properly check the result of setuid() and just assumed it had  
succeeded.  So instead of running as "smtpd" it was running as  
"root".   Not a happy memory.

Cheers,
Kyle Moffett

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Bernd Petrovitsch]

On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
[....]
> Key-based masterlocks are easily broken with freon, and their combo
> locks are easily brute-forced in about ten minutes. Yet, I'll still
> use them to lock up my bike and garage.

The question is what the security threat is and the value of the secured
items.

> The idea that poor security is worse than no security is fallacious,
> and not backed up by common experience.

The common experience is, that common people just *feel* safer (just
because they have poor security).
With no security, they know that there is no security. With poor
security, they do not know (or can deny) that they have next to no real
security.
The prime example here is the usual (so-called) "personal firewall" on
Windows where people work normally as "administrator".

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Simon Arlott]

On Wed, October 24, 2007 22:02, David P. Quigley wrote:
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> with a targeted policy the user isn't concerned with it. Now multiadm
> comes along and an administrator wishes to grant extra rights to a user.
> This is fine with multiadm alone since it is the main security module,
> however we now have to compose this with AppArmor. So an administrator
> runs into an error running his application. Is this because his user
> isn't granted the proper escalated privileges? Is it because AppArmor
> needs an extra rule to run the application?  It could also be that our
> third module has blocked the application because it determined that even
> though multiadm specified that the user should have the elevated
> privileges to run the application that user shouldn't be able to bind to
> that port.
>
> There might be a better example to illustrate the problem however, this
> simple example shows the interdependency of three seemingly simple
> modules. Imagine what happens when people really let loose and implement
> all sorts of crazy ideas and stack them on top of each other. Stacking
> works in things such as file systems because we have a clearly defined
> interface with fixed solid semantics. You could attempt to do that but
> once you have modules that step on each others toes you have to figure
> out a way to reconcile that. It seems to me that you're going to
> introduce usability problems that are hard to deal with.

I agree that it can cause problems, but it's up to the modules themselves
to determine how to combine permissions with their immediate secondary
module.

Instead we now have a static LSM where combining features from one module
means duplicating it in another - then when two modules contain most of
the other's code, but perhaps vastly different configuration mechanisms,
someone will propose removing one of the two...

-- 
Simon Arlott

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Simon Arlott]

On Wed, October 24, 2007 23:31, Adrian Bunk wrote:
> On Wed, Oct 24, 2007 at 07:11:17PM +0100, Simon Arlott wrote:
>> On 24/10/07 13:55, Adrian Bunk wrote:
>> > On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
>> >> I currently have an LSM that only handles permissions for socket_bind
>> >> and socket_listen, I load it and then "capability" as secondary on
>> >> boot - but now I can't because the LSM framework is now just the LS
>> >> framework.
>> >>
>> >> Why can't this "static LSM" change be a Kconfig option?
>> >> (I don't want to have to maintain my own reverted copy of security/,
>> >> or compile this into the kernel because then I can't ever modify and
>> >> reload it without rebooting.)
>> >
>> > Let's start with the more important questions:
>> >
>> > Did you submit your LSM for inclusion into the kernel?
>>
>> No, because the interface for configuring it would be rejected... I have
>> a /proc file which I write a binary configuration file to. This works
>> fine for me but it would take a lot of work to write a proper interface
>> - which I'm still not sure how to do*.
>>...
>
> Generally, the goal is to get external modules included into the kernel.
>
> You want to be able to have this functionality and you do not want to
> use SELinux for it.

SELinux couldn't do it when I wrote my own module, it may do now but I
haven't checked - that's also far too much extra configuration overhead
to do something relatively simple.

> But instead of working on getting your code into the kernel you are
> requesting that an API making it easier for you to maintain it
> externally comes back.

It's also much harder to maintain it internally too since it can no
longer be compiled as a module. If it were possible to have to make LSM
usable as a module but without secondary support, that would make
development easier - although secondary support is so trivial I doubt
it makes a difference to the possibility of allowing it to be compiled
as a module again.

> There are other points in this thread that might or might not warrant
> making LSM modular again, but even though it might sound harsh breaking
> external modules and thereby making people aware that their code should
> get into the kernel is IMHO a positive point.

You're only going to be forcing me to spend *my* time developing it into
something that could be accepted into the kernel when it works fine for
me already. Then I'd have to convince the LSM maintainer(s) that it
should be merged - this isn't like an external hardware driver where
there's no existing support in the kernel.


>> Simon Arlott
>
> cu
> Adrian


-- 
Simon Arlott

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Ray Lee]

On 10/25/07, Bernd Petrovitsch <bernd@firmix.at> wrote:
> On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
> [....]
> > Key-based masterlocks are easily broken with freon, and their combo
> > locks are easily brute-forced in about ten minutes. Yet, I'll still
> > use them to lock up my bike and garage.
>
> The question is what the security threat is and the value of the secured
> items.
>
> > The idea that poor security is worse than no security is fallacious,
> > and not backed up by common experience.
>
> The common experience is, that common people just *feel* safer (just
> because they have poor security).

Do you lock your bike up when you leave it lying around? My point is
that real security comes in layers, not one perfect solution that will
always work everywhere for everyone. The latter is a pipe-dream.

> With no security, they know that there is no security. With poor
> security, they do not know (or can deny) that they have next to no real
> security.

The fallacy here is to believe that just because they have no
security, that it will *in*any*way* change their behavior. I deal with
real users daily, and *they*don't*care*. Further, there's no level of
education that we can instill into the community to make them aware of
the issues and change their habits accordingly, because real users
don't have the background to understand those lessons.

While you can teach them that running an executable from someone they
haven't heard of is obviously bad, they don't know why downloading an
image is potentially dangerous, "it's an image, right?" "Well, there's
these things called buffer overflows..." <eyes glaze over>

Security is not an all or nothing game, it's layers. And we have to
make sure that the layers are usable without taking a course from the
NSA. I'd love to see a poll of the kernel development community to
find out how many use SELinux on their machines, for example.

> The prime example here is the usual (so-called) "personal firewall" on
> Windows where people work normally as "administrator".

So your argument is that if there weren't a personal firewall on
Windows, that a significant number of people would then not run as
Administrator? I beg to differ.

Ray

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Arjan van de Ven]

On Thu, 25 Oct 2007 09:04:57 -0700
"Ray Lee" <ray-lk@madrabbit.org> wrote:


> Security is not an all or nothing game, it's layers. And we have to
> make sure that the layers are usable without taking a course from the
> NSA. I'd love to see a poll of the kernel development community to
> find out how many use SELinux on their machines, for example.

I absolutely agree it's a layer game.
HOWEVER, even in a layer game we need to have each layer to be
reasonably solid and not just fake security ("snakeoil").

So while I think it is entirely fair to judge a piece of software
against what it intends/claims to do, because other pieces in the layer
game will depend on it to function reasonably well. 

So most of the LSM fist-fights have been about disagreement of the
intent; and some about code not living up to its own intend, all mixed
up. Arguing about the intent is less productive imo (as long as it's at
least somewhat reasonable, intend like "I want to add rootkits" doesn't
count obviously), paying attention to check if the code lives up to its
stated intent/purpose on the other hand is immensely useful and needed;
for a given implementation it may mean reducing the scope of the intent
if the implementation just doesn't go as wide as originally thought, or
fixing some issues in the implementation to live up to the intent.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Ray Lee]

On 10/24/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > The idea that poor security is worse than no security is fallacious,
> > and not backed up by common experience.
>
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.

(So, I take it that you *don't* lock your bike up, as poor security is
worse than none?)

While I believe you, I'd love to see references as it doesn't match my
day-to-day experience with Win/Mac end-users over the past ten years.

> In particular stuff which makes users think they are secure but is
> worthless is very dangerous indeed.

I have no trouble believing that.

> When you know that security is limited you act appropriately, when you
> believe security is good but it is not you take inappropriate risks and
> get badly burned.

'Inappropriate risks' nowadays is surfing the web and opening up mail
attachments that claim to be movies of dancing bears. I'd argue that
users have a reasonable expectation that these are things that should
'just work,' and be safe, much as normal humans have an expectation
that their car isn't going to explode when they turn the ignition.

Perfect is the enemy of good, or words to that effect, right? My point
is that requiring perfection out of a security framework is a bar
that's going to be awfully difficult to reach (and when it supposedly
has been achieved, as in SELinux, mere mortals find it too troublesome
to run with as it's far too difficult to configure). Security can and
should be done in layers, and what one may miss, another may catch.

Ray

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Alan Cox]

> > There is a ton of evidence both in computing and outside of it which
> > shows that poor security can be very much worse than no security at all.
> 
> (So, I take it that you *don't* lock your bike up, as poor security is
> worse than none?)

On the contrary because I know it is not secure I would

a) Insure it
b) Not waste vast amounts of money on a useless expensive lock
c) Make sure the bike looked not worth stealing
d) Take the saddle with me

(or the software versions of that

a) Keep backups
b) Not waste vast amounts of money on bogus security software
c) Keep the system looking uninteresting
d) Encrypt the data)

> 'Inappropriate risks' nowadays is surfing the web and opening up mail
> attachments that claim to be movies of dancing bears. I'd argue that
> users have a reasonable expectation that these are things that should
> 'just work,' and be safe, much as normal humans have an expectation
> that their car isn't going to explode when they turn the ignition.

Yes and its very clear from the things said by politicians that if the
computer software people don't do this soon, the legislators will make
very sure they do by stripping away all the techniques used to hide from
liability for failure.

> Perfect is the enemy of good, or words to that effect, right? My point
> is that requiring perfection out of a security framework is a bar
> that's going to be awfully difficult to reach (and when it supposedly
> has been achieved, as in SELinux, mere mortals find it too troublesome
> to run with as it's far too difficult to configure). Security can and
> should be done in layers, and what one may miss, another may catch.

Absolutely - but those layers should do whatever they do *right* and
really do it, whether they are complex whole system controls like SELinux
or simple network security tools.

Alan

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Tilman Schmidt]

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

Am 25.10.2007 00:31 schrieb Adrian Bunk:
> Generally, the goal is to get external modules included into the kernel.
> [...] even though it might sound harsh breaking
> external modules and thereby making people aware that their code should 
> get into the kernel is IMHO a positive point.

This argument seems to start from the assumption that any externally
maintained kernel code *can* get into the kernel, which doesn't stand
up to  reality. Once you admit that there is code which, for very good
reasons, won't ever be accepted into the mainline kernel tree, what you
are saying amounts to: "Code that isn't fit to be included in the
mainline kernel isn't fit to exist at all."

I'm not sure I can agree with that.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Greg KH]

On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> > Generally, the goal is to get external modules included into the kernel.
> > [...] even though it might sound harsh breaking
> > external modules and thereby making people aware that their code should 
> > get into the kernel is IMHO a positive point.
> 
> This argument seems to start from the assumption that any externally
> maintained kernel code *can* get into the kernel, which doesn't stand
> up to  reality. Once you admit that there is code which, for very good
> reasons, won't ever be accepted into the mainline kernel tree, what you
> are saying amounts to: "Code that isn't fit to be included in the
> mainline kernel isn't fit to exist at all."

What kind of code is not accepted into the mainline kernel tree for good
reasons?  What are these reasons?  What specific code are you talking
about?

I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things.  If you know of any that are not on the list at:
	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
please feel free to add them, or email me with the needed information
and I will add them to the list.

thanks,

greg k-h

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[david]

On Thu, 25 Oct 2007, Alan Cox wrote:

>>> There is a ton of evidence both in computing and outside of it which
>>> shows that poor security can be very much worse than no security at all.
>>
>> (So, I take it that you *don't* lock your bike up, as poor security is
>> worse than none?)
>
> On the contrary because I know it is not secure I would
>
> a) Insure it

and the unsurance company would have a clause in the policy that wouldn't 
cover you unless you used a lock, becouse they recognise that while it 
wouldn't stop everyone there is a large group of potential thieves that it 
would stop.

> b) Not waste vast amounts of money on a useless expensive lock

who said the lock was expensive? and while you are not willing to spend 
money on a lock you are willing to spend (much more) money on an insurance 
policy.

David Lang

> c) Make sure the bike looked not worth stealing
> d) Take the saddle with me
>
> (or the software versions of that
>
> a) Keep backups
> b) Not waste vast amounts of money on bogus security software
> c) Keep the system looking uninteresting
> d) Encrypt the data)
>
>> 'Inappropriate risks' nowadays is surfing the web and opening up mail
>> attachments that claim to be movies of dancing bears. I'd argue that
>> users have a reasonable expectation that these are things that should
>> 'just work,' and be safe, much as normal humans have an expectation
>> that their car isn't going to explode when they turn the ignition.
>
> Yes and its very clear from the things said by politicians that if the
> computer software people don't do this soon, the legislators will make
> very sure they do by stripping away all the techniques used to hide from
> liability for failure.
>
>> Perfect is the enemy of good, or words to that effect, right? My point
>> is that requiring perfection out of a security framework is a bar
>> that's going to be awfully difficult to reach (and when it supposedly
>> has been achieved, as in SELinux, mere mortals find it too troublesome
>> to run with as it's far too difficult to configure). Security can and
>> should be done in layers, and what one may miss, another may catch.
>
> Absolutely - but those layers should do whatever they do *right* and
> really do it, whether they are complex whole system controls like SELinux
> or simple network security tools.
>
> Alan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

Ok lets get to a good point.

Lets define a key bit.   What is a good software security lock?

My define is that its available to be used everywhere its needed and
when ever its need without flaw.

This is where most LSM fall in a heap.  Because you have to have the
LSM loaded to have its security features and cannot always be mixed
with other LSM it failes the when ever it is needed test.

On top of this most LSM features don't provide any form of direct
control to non admin users or applications to lower there access
rights.  So it also fails to be used everywhere its needed.

Since the LSM design itself is flawed in my eyes.   These flaws make
it hard for LSM to share tech advantages with each other.   LSM are
very much like putting a lock threw the front wheel of a bike.   So
the thief removes the front wheel and walks off with the rest of the
bike.  The critical data is in the user accounts.

The big thing with most LSM how do they handle security inside a
application on a thread by thread base.  They don't reason it gets too
compex without known the internals of the application.

We are talking security here and design of LSM's are not offering the
option max security.

Max security has to get down to a single thread inside a application
with all the security blocking features LSM's offer.  Reason a flaw in
that thread could be made completely harmless even that the other
threads in the application has complete system rights.

Idea of Max is to keep application flaws to as minor security flaw as
they could have been.   Ie Hopefully no risk because the flaw happened
in a section of code with no rights.

This is virtually imposable for any form of profiling creating
security to ever do(LSM profile based security).  What is needed is
application controlled security with profile based security as fail
back.  I know this means ripping your LSM parts apart and designing in
application controls.  Allowing features to be shared between LSM and
even to be there when the LSM that feature came from is not being
used.

First goal should not be to get a LSM static linked into kernel or
anything else bar getting the security system to a point that max
security is on the table if people want it.

I will say this again in my eyes LSM's should be thrown out of the
kernel completely because they are only offering fake max security.
Selinux and other LSM's on max is not even close to what should be
offered.

Basically Linux is a sitting duck for data thief third party  that
steal from the users home directory personal information.   And its
not like application developers are being given the tools to prevent
that.  Cost and loss does not start only when applications normal
profile of access is breached.   It starts way before that.

Peter Dolding

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Oct 25 2007 19:56, Greg KH wrote:
>
>I'm trying to compile a list of all known external modules and drivers
>and work to get them included in the main kernel tree to help prevent
>these kinds of things.  If you know of any that are not on the list at:
>	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>please feel free to add them, or email me with the needed information
>and I will add them to the list.

Do I have to at least try to submit it to LKML first before it is
even considered for the OOT wiki page? :-)

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Tilman Schmidt]

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

On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
>> Am 25.10.2007 00:31 schrieb Adrian Bunk:
>> > Generally, the goal is to get external modules included into the kernel.
>> > [...] even though it might sound harsh breaking
>> > external modules and thereby making people aware that their code should 
>> > get into the kernel is IMHO a positive point.
>> 
>> This argument seems to start from the assumption that any externally
>> maintained kernel code *can* get into the kernel, which doesn't stand
>> up to  reality. Once you admit that there is code which, for very good
>> reasons, won't ever be accepted into the mainline kernel tree, what you
>> are saying amounts to: "Code that isn't fit to be included in the
>> mainline kernel isn't fit to exist at all."
> 
> What kind of code is not accepted into the mainline kernel tree for good
> reasons?

- proprietary code
- unmaintained code
- code conflicting with existing kernel structure or policy
- code in which the concerned subsystem maintainers see no benefit
- code which its author is unable and/or unwilling to convert to
  kernel coding standards
- code whose author is unable and/or unwilling to defend it on LKML

> What are these reasons?

The details vary, but the fundamental reason is always the same: to
maintain a sufficient level of code quality in the kernel. Point in
case, the recent discussion whether drivers not supporting
suspend/resume should be refused to merge.

> What specific code are you talking about?

Some examples, in no particular order: Reiser4, AppArmor, VMware,
the staircase deadline scheduler, the first version of ser_gigaset,
the Matrox HAL module, SuSE's "taint extension". Yes, some of these
are in the kernel now, or have been superseded by other code that
is, but that doesn't invalidate my concern.

> I'm trying to compile a list of all known external modules and drivers
> and work to get them included in the main kernel tree to help prevent
> these kinds of things.  If you know of any that are not on the list at:
> 	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> please feel free to add them, or email me with the needed information
> and I will add them to the list.

That's certainly helpful, but I still think there will always be
a number of external modules that cannot be merged right now or at
all, and deliberately making life difficult for out-of-tree code
maintainers in order to coerce them into submitting their code for
inclusion in the kernel will not work, it'll only create bad
feelings.

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Greg KH]

On Fri, Oct 26, 2007 at 09:09:05AM +0200, Jan Engelhardt wrote:
> 
> On Oct 25 2007 19:56, Greg KH wrote:
> >
> >I'm trying to compile a list of all known external modules and drivers
> >and work to get them included in the main kernel tree to help prevent
> >these kinds of things.  If you know of any that are not on the list at:
> >	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> >please feel free to add them, or email me with the needed information
> >and I will add them to the list.
> 
> Do I have to at least try to submit it to LKML first before it is
> even considered for the OOT wiki page? :-)

No, you can go hide on your own, that's what the majority of projects on
that page have done :)

But of course, it would be good for you to at least submit it and get
feedback.  Or, if you don't want to do it, the linuxdriverproject
developers would be glad to help you out...

thanks,

greg k-h

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Greg KH]

On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > I'm trying to compile a list of all known external modules and drivers
> > and work to get them included in the main kernel tree to help prevent
> > these kinds of things.  If you know of any that are not on the list at:
> > 	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> > please feel free to add them, or email me with the needed information
> > and I will add them to the list.
> 
> That's certainly helpful, but I still think there will always be
> a number of external modules that cannot be merged right now or at
> all, and deliberately making life difficult for out-of-tree code
> maintainers in order to coerce them into submitting their code for
> inclusion in the kernel will not work, it'll only create bad
> feelings.

Do you have examples of proof of this?  Read
Documentation/stable_api_nonsense.txt for how we already make
out-of-tree code developer's lives hell :)

thanks,

greg k-h

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Simon Arlott]

On 26/10/07 16:58, Greg KH wrote:
> On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
>> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
>> > I'm trying to compile a list of all known external modules and drivers
>> > and work to get them included in the main kernel tree to help prevent
>> > these kinds of things.  If you know of any that are not on the list at:
>> > 	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>> > please feel free to add them, or email me with the needed information
>> > and I will add them to the list.
>> 
>> That's certainly helpful, but I still think there will always be
>> a number of external modules that cannot be merged right now or at
>> all, and deliberately making life difficult for out-of-tree code
>> maintainers in order to coerce them into submitting their code for
>> inclusion in the kernel will not work, it'll only create bad
>> feelings.
> 
> Do you have examples of proof of this?  Read
> Documentation/stable_api_nonsense.txt for how we already make
> out-of-tree code developer's lives hell :)

The change makes it much harder to develop in tree too. Also, this really 
needs to be reverted and put in the feature removal schedule... unless 
you intend to deliberately make all out of tree LSMs unusable with no 
warning and no time to have them added to the kernel? We're already at 
2.6.24-rc1.

-- 
Simon Arlott

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Adrian Bunk]

On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> >> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> >> > Generally, the goal is to get external modules included into the kernel.
> >> > [...] even though it might sound harsh breaking
> >> > external modules and thereby making people aware that their code should 
> >> > get into the kernel is IMHO a positive point.
> >> 
> >> This argument seems to start from the assumption that any externally
> >> maintained kernel code *can* get into the kernel, which doesn't stand
> >> up to  reality. Once you admit that there is code which, for very good
> >> reasons, won't ever be accepted into the mainline kernel tree, what you
> >> are saying amounts to: "Code that isn't fit to be included in the
> >> mainline kernel isn't fit to exist at all."
> > 
> > What kind of code is not accepted into the mainline kernel tree for good
> > reasons?
> 
> - proprietary code

It's unclear whether distributing not GPL compatible modules is legal
at all.

And they are definitely not "very good reasons" for doing anything in 
the kernel.

> - unmaintained code

Unmaintained code in the kernel has a realistic chance of being usable 
for 5 years.

Unmaintained external code is quite likely to be unusable after
at most one year.

> - code conflicting with existing kernel structure or policy
> - code in which the concerned subsystem maintainers see no benefit

Let's fix the problems, not work around them.

There is a conflict between getting code included and ensuring some 
minimum quality of the kernel, but in many cases we could try better.

And when there's a good reason for a kernel policy, then code that
violates this policy is not a "very good reason" for anything.

> - code which its author is unable and/or unwilling to convert to
>   kernel coding standards
> - code whose author is unable and/or unwilling to defend it on LKML
>...

That's their fault, and definitely not a "very good reason" for making 
life easier for them.

> Thanks,
> Tilman

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: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Pavel Machek]

Hi!

> but require unreasonable interface changes. As people who care
> about security (y'all who are only from the LKML are excused) it
> is our obligation to look beyond the preconceived notions of what
> is and isn't secure. Security is subjective. It's how you feel
> about it.

<sarcasm>Hmm. So lets add automagic security module. It magically fixes
security holes, and you can feel good about it.</sarcasm>


							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Pavel Machek]

Hi!

> > > The idea that poor security is worse than no security is fallacious,
> > > and not backed up by common experience.
> >
> > There is a ton of evidence both in computing and outside of it which
> > shows that poor security can be very much worse than no security at all.
> 
> (So, I take it that you *don't* lock your bike up, as poor security is
> worse than none?)

I do lock my bike with combination lock I found somewhere and cracked
in five minutes... sometimes.

But do you suggest that I use paper tape to 'lock' my bike to
streetlight? You just said that poor security is better than none,
right?

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Hua Zhong]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Pavel Machek
> Sent: Saturday, October 27, 2007 11:29 AM
> To: Ray Lee
> Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
> linux-kernel@vger.kernel.org; linux-security-module@vger.kernel.org;
> Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
> Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
> Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
> static interface)
> 
> Hi!
> 
> > > > The idea that poor security is worse than no security is
> fallacious,
> > > > and not backed up by common experience.
> > >
> > > There is a ton of evidence both in computing and outside of it
> which
> > > shows that poor security can be very much worse than no security at
> all.
> >
> > (So, I take it that you *don't* lock your bike up, as poor security
> is
> > worse than none?)
> 
> I do lock my bike with combination lock I found somewhere and cracked
> in five minutes... sometimes.
> 
> But do you suggest that I use paper tape to 'lock' my bike to
> streetlight? You just said that poor security is better than none,
> right?
> 
> 							Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

RE: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Hua Zhong]

I think you may be misinterpreting the word "poor" here.

Many people in this thread consider a security solution "poor" because it's
not "complete" or "perfect": it may work against attack ABC but not attack
XYZ. The defendants say that XYZ isn't possible in the environment that it's
supposed to be used, or XYZ may be too expensive to be worth implementing,
or they just are rare enough to be ignored. Heck, all security solutions
could be broke given physical access.

Implementing a security solution has a cost. Bypassing it also has a cost.
Sometimes it's economy, not technique, decides whether a particular security
solution is a good one.

Locks are a good example for this. It has a low cost/effect ratio, and very
easy to use. Is it 100% safe? Definitely not. People lock their bikes to a
tree when they enter a supermarket because it's reasonably safe. But leaving
their bikes like that over a few nights on a downtown street? Probably not a
good idea. Don't assume all people are idiots who do not know that (ok, some
people are, so the lock's manual states "it can be bypassed by a skilled
thief").

But what tapes are good for? I don't know what kind of value it adds to the
discussion.

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Pavel Machek
> Sent: Saturday, October 27, 2007 11:29 AM
> To: Ray Lee
> Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
> linux-kernel@vger.kernel.org; linux-security-module@vger.kernel.org;
> Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
> Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
> Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
> static interface)
> 
> Hi!
> 
> > > > The idea that poor security is worse than no security is
> fallacious,
> > > > and not backed up by common experience.
> > >
> > > There is a ton of evidence both in computing and outside of it
> which
> > > shows that poor security can be very much worse than no security at
> all.
> >
> > (So, I take it that you *don't* lock your bike up, as poor security
> is
> > worse than none?)
> 
> I do lock my bike with combination lock I found somewhere and cracked
> in five minutes... sometimes.
> 
> But do you suggest that I use paper tape to 'lock' my bike to
> streetlight? You just said that poor security is better than none,
> right?
> 
> 							Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Crispin Cowan]

Alan Cox wrote:
>> The idea that poor security is worse than no security is fallacious,
>> and not backed up by common experience.
>>     
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.
> In particular stuff which makes users think they are secure but is
> worthless is very dangerous indeed.
>
> When you know that security is limited you act appropriately, when you
> believe security is good but it is not you take inappropriate risks and
> get badly burned.
>   
The "bad security is worse than no security" idea comes exactly from
what Alan says above: it happens when the security is not as good as you
think it is, and so you don't take adequate precautions.

Using the ongoing bicycle lock example, the discovery a few years ago
that a certain model of Kryptonite bike lock could be picked with a
simple pen made the security on this otherwise very sturdy lock become
abruptly very weak http://www.wired.com/culture/lifestyle/news/2004/09/64987

Conversely, the case can also be made that "weak security is better than
no security". It is better to secure your bike with a $10 lock than no
lock. If someone insists on only "high" security bike locks that cost
$1000 and weigh 30 lbs, then most people will choose to not lock their
bikes, or skip biking all together.

IMHO, much of the criticism leveled at proposed LSMs has been of the
latter kind, or worse. That the security of the proposed LSM does not
meet some particular use case does not make it "bad", it makes it not
for that use case.

To reject an LSM for providing "bad" security, IMHO you should have to
show how it is possible to subvert the self-stated goals of that LSM.
Complaints that the LSM fails to meet some goal outside of its stated
purpose is irrelevant. Conjecture that it probably can be violated
because of $contrivance is just so much FUD.

Exception: it is valid to say that the self-stated goal is too narrow to
be useful. But IMHO that bar of "too narrow" should be very, very low.
Defenses against specific modes of attack would be a fine thing to build
up in the library of LSMs, especially if we got a decent stacking module
so that they could be composed.

Crispin

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

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Alan Cox]

> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.

That seems to be an appropriate test.

> Exception: it is valid to say that the self-stated goal is too narrow to
> be useful. But IMHO that bar of "too narrow" should be very, very low.
> Defenses against specific modes of attack would be a fine thing to build
> up in the library of LSMs, especially if we got a decent stacking module
> so that they could be composed.

Once you have stacking then it actually at times will make sense to have
security modules that do one very precise thing and do it well.

Alan

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

On 10/29/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.

LSM is providing bad security on two fronts.

Number 1 LSM are speeding effort to create features.  Apparmor and
Selinux both provide file access filtering from applications.  Yet
they double up the code to do it.   So they cannot be used with each
other without doubling up hooks.  Then other LSM are creating there
own sections of code to do the same thing.   Simple rule more code
more risk of bugs since it will be less audited.  Duplication defense
features is really bad for security.  Some how code sharing has to be
got into LSM construction.

Number 2 The critical bit LSM stop at the edges of applications.   Now
without overlapping my hooks with existing LSMs I cannot create
application level protections.  Overlapping hooks will cause speed
loss.

LSM is set to protect the application. But inside the application
there will be sections that need the access rights and others that
don't.  Now a exploit in any section of the application under LSM gets
the LSM assigned rights.   With application level this can be done a
few ways extension to elf that is create by the complier and api calls
lowering access functions of current thread or for a starting thread.
If you exploit a section of the code without access to disk network
access and so on and without the right to call any function that does
that.   What have you exploited.   Minor data damage compared to
complete data that the application have access to being stolen as what
is the case with LSM at moment.  Basically LSM prevent taking control
of the complete system but don't help to stop peoples private data
from being stolen.  Both are bad to happen to a person.

LSM design is there to help security development not get in its way or
to cause bitrot.  Currently LSM design is causing major risk bitrot in
duplicated code.

Reading and processing configuration files should be independent to
the protection methods.   Hopefully designed to be able to run user
mode to test if the new profile for a application is safe to add
before adding it to the OS.   Typo prevention on both sides.  Current
method of just sticking everything into one huge blob is preventing
code sharing and risking more security holes.

The current LSM design is bad on so many levels.  I am surprised that
it takes a Non PHD System Admin to see it.  Some how I think its a
empire thing.   If everything was just simple blocks a person could
write a new LSM in hours with pretty good security.  Compared to
todays long time trying effort.  Leads of Apparmor selinux and so on
not being prepared to give up there little empire for the greater
good.

I personally hate stacking as a idea.  I personally prefer two layers
only.  Config reading and  enforcement.   Of course that does not stop
applications being assigned to different config reading systems.
Depth the two layers should stay fixed even if you have many different
models in use.

All LSM seam to want to force System Admins to pick there LSM over
another.   Instead of being able to pick LSM for task at hand.   Same
with poor security being better than no security its true.  Its
nothing strange to find selinux based systems with there security
disabled because the Admin cannot configure it.   But the reverse is
also true that when you have skilled Admins stuck with a system like
Apparmor cannot harden the system as far as they could with selinux.
Both ways its causing security holes poor security when you should
have good security is bad too.  Part of the problem LSM maintainers
are not at the front lines is all I can guess.  Because they don't
seam to know what is really needed.

Peter Dolding

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Arjan van de Ven]

On Sun, 28 Oct 2007 15:08:56 -0700
Crispin Cowan <crispin@crispincowan.com> wrote:

> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.

exactly; this is why I've been pushing recently for each new LSM to at
least document and make explicit what it tries to protect / protect
against (threat model and defense model in traditional security terms).
Without such an explicit description it's both impossible to
"neutrally" review a proposed LSM towards its goals, and it ends up as
a result with people making assumptions and attacking the model because
there's no separation between code and model.

 
> Exception: it is valid to say that the self-stated goal is too narrow
> to be useful. But IMHO that bar of "too narrow" should be very, very
> low. Defenses against specific modes of attack would be a fine thing
> to build up in the library of LSMs, especially if we got a decent
> stacking module so that they could be composed.

again I agree pretty much; I do want to reserve some minimum "common
sense" bar because people may (and probably will) do silly things withs
LSMs that are really not the right thing to do objectively.


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Rob Meijer]

On Thu, October 25, 2007 02:42, Casey Schaufler wrote:
>
> I agree that security code does need to provide security. What we
> need to get away from is the automatic attacks that are based on 20th
> century computer system assumptions. Things like "name based access
> control is rediculous", and "a module can't be any good if it doesn't
> deal with all objects", or "the granularity isn't fine enough". Look
> at TOMOYO. It's chuck full of good ideas. Why spend so much energy
> badgering them about not dealing with sockets? How about helping the
> AppArmor crew come up with acceptable implementations rather than
> whinging about the evils of hard links? And maybe, just maybe, we can
> get away from the inevitable claim that you could do that with a few
> minutes work in SELinux policy, but only if you're a security
> professional of course.

What may be even more relevant are those concepts that couldn't be done
in SELinux, and how proposals that come from the theory of alternative
access controll models (like object capability modeling) are dismissed
by the aparently largely MLS/MAC oriented people on the list.

In a wider contect than just this list, it apears to me that MLS and
Obj Caps advocates simply dismiss the alternative models as broken or as
irrelevant at best. In my view this attitude is very much pressent on
the MLS list.

It might in the light of this attitude even be a viable option to just
simply spin off 3 (or more) sets of LSM module sets, and maybe even put
some ifdefs in the base code depending on the chosen access controll model,
if for some reason the 'model' warants some major patch.

To me it would look like a good concept if LSM/Linux would try to support
all exisiting formal models of access controll, but without the need to
support all implementation alternatives for these models. That is, if a
module 'requires' a patch but the underlaying formal model does not, than
it would seem reasonable that the module be fixed. If however the 'model'
seems to require the patch, it may be perfectly reasonable for this patch
to be implemented, if need be with an ifdef for the used model.

Thus IMHO it may be a good idea to instead of a maintainer for LSM
modules as proposed, alternatively a maintainer for each formal model
may be more appropriate. This also would require module builders to first
think about what formal model they are actualy using, thus resulting in
cleaner module design.



Rob

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Crispin Cowan]

Rob Meijer wrote:
> What may be even more relevant are those concepts that couldn't be done
> in SELinux, and how proposals that come from the theory of alternative
> access controll models (like object capability modeling) are dismissed
> by the aparently largely MLS/MAC oriented people on the list.
Clearly what is needed here is for someone to actually implement an
object capability LSM module. None of SELinux, SMACK, LIDS, AppArmor,
MultiADM, or TOMOYO can implement object capabilities, so there is clear
justification for building such a module. I would argue strongly to
include it.

> Thus IMHO it may be a good idea to instead of a maintainer for LSM
> modules as proposed, alternatively a maintainer for each formal model
> may be more appropriate. This also would require module builders to first
> think about what formal model they are actualy using, thus resulting in
> cleaner module design.
>   
I *really* dislike this idea. It seems to set up the situation that the
only acceptable modules are those that follow some "formal" model. Problems:

    * What qualifies as a formal model? This becomes an arbitrary litmus
      test, depending on whether the model was originally published in a
      sufficiently snooty forum.
    * What if someone invents a new model that has not been "formalized"
      yet? Should Linux be forced to wait until the idea has been
      through the academic mill before we allow someone to try
      implementing a module for the idea?
    * The proposal only allows a single implementation of each formal
      model. In theory, theory is just like practice, but in practice it
      is not. SMACK and SELinux follow substantially similar formal
      models (not exactly the same) so should we exclude one and keep
      the other? No, of course not, because in practice they are very
      different.

Crispin

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

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

On 10/29/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> I *really* dislike this idea. It seems to set up the situation that the
> only acceptable modules are those that follow some "formal" model. Problems:
>
>     * What qualifies as a formal model? This becomes an arbitrary litmus
>       test, depending on whether the model was originally published in a
>       sufficiently snooty forum.

Agree slows development and experimentation with a idea BAD.  I would
more say function and reach of model and how its ment to operate
documented clearly.  So next coder along is not taken wild guess.  It
must be so clearly documented that almost any system admin could
understand how much or how little protection it is providing.

>     * What if someone invents a new model that has not been "formalized"
>       yet? Should Linux be forced to wait until the idea has been
>       through the academic mill before we allow someone to try
>       implementing a module for the idea?

Experimental until documented out of tree following mine.
.
>     * The proposal only allows a single implementation of each formal
>       model. In theory, theory is just like practice, but in practice it
>       is not. SMACK and SELinux follow substantially similar formal
>       models (not exactly the same) so should we exclude one and keep
>       the other? No, of course not, because in practice they are very
>       different.

Drop a stick on both of them.   Since they both operate substantially
similar they should be directly prepared to share code with each
other.   If one is not prepared to work with the other openly and
fairly out the tree it goes.

It could quite simple become the only thing different between Smack
and Selinux in they way they read configuration files.   Long term the
most user friendly and security solid modules win.  So long term one
wins short term any number of models.  We of course wait for that to
happen.  Note it could be agreement between coders.   Since they were
force to work as one if there is merit it will come out.  There is no
room for empire builders.   We need security builders.  Part of that
is getting your code examined by the most number of people able.

Same with apparmor vs selinux both can provide file access filtering.
So why two sets of code to do it.

LSM need a really strong maintainer prepared to beat a few ears in.
Or all we will endup with is usable modules.   Selinux pain in but to
configure no not really usable.   Maybe flaws in Smack so force to use
Selinux.  Apparmor too weak.

Basically a stack of trash is the current LSM model.  LSM's are fast
turning into x86 vs x86-64 bitrot all over again accept this time 100
times worse.  What is basically bitrot caused by not sharing.
Stackable modules maybe.  More important shared source code to do
stuff and common standards between LSM used where able.  This also
should make it simpler for new models to be added and experimented
with.  Since the new model may not need to redo all there hooking
system all over again.  Reduced security risk more tested code used in
new models.

Next more important extend security down into applications if
applications need it.   File access filtering would be a great feature
at the thread level.

We have enough LSM's to be hard. It a privilege to be in the main
kernel tree not a right.  Part of having a module in the Linux kernel
tree is a promise to do what is right for everyones security using the
kernel even if it means the end to your LSM's existence.  Part of
doing what is right is sharing of code.   All LSM developers should be
looking at there code and asking should this be like posix file caps
and for everyone.  Or should this be a LSM only feature because its
useless to everyone else.  From what I am seeing LSM maintainers don't
seam to think its part of the requirement to help other LSM's be
better even if theirs ends up losing.  Only if you are building a
Empire does it matter who wins or loses the long term of LSM's.   Only
thing that truly matter is that we get the best long term.


Peter Dolding

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Rob Meijer]

On Mon, October 29, 2007 11:24, Crispin Cowan wrote:

>> Thus IMHO it may be a good idea to instead of a maintainer for LSM
>> modules as proposed, alternatively a maintainer for each formal model
>> may be more appropriate. This also would require module builders to
>> first
>> think about what formal model they are actualy using, thus resulting in
>> cleaner module design.
>>
> I *really* dislike this idea. It seems to set up the situation that the
> only acceptable modules are those that follow some "formal" model.
> Problems:
>
>     * What qualifies as a formal model? This becomes an arbitrary litmus
>       test, depending on whether the model was originally published in a
>       sufficiently snooty forum.
>     * What if someone invents a new model that has not been "formalized"
>       yet? Should Linux be forced to wait until the idea has been
>       through the academic mill before we allow someone to try
>       implementing a module for the idea?

I may have been stating things a bit to strong when talking only about
"formal" models only. But possibly you could just define the non-formal
experimental models as a single group.

The thing I was trying to propose was aimed at the problem that if someone
proposes a patch to the LSM base code that he/she feels is needed to
complete an LSM module that implements a particular (formal) model,
he/she would end up explaining and/or defending both the 'model', the module
and its requirement for the patch.

What I tried to propose is to assign some sort of maintainer role for each
(formal) model, and let these roles take care of the module/patch part of
stuff, while the module writer would only need to defend/discuss the the
patch with the model maintainer.

>     * The proposal only allows a single implementation of each formal
>       model. In theory, theory is just like practice, but in practice it
>       is not. SMACK and SELinux follow substantially similar formal
>       models (not exactly the same) so should we exclude one and keep
>       the other? No, of course not, because in practice they are very
>       different.

I would think the two may benefit from a role as described above.
But I was thinking more in the line of new modules that may again
implement this same model, and would thus benefit from interaction with
this 'model maintainer' role.


Rob

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Crispin Cowan]

Rob Meijer wrote:
> On Mon, October 29, 2007 11:24, Crispin Cowan wrote:
>   
>>> Thus IMHO it may be a good idea to instead of a maintainer for LSM
>>> modules as proposed, alternatively a maintainer for each formal model
>>> may be more appropriate. This also would require module builders to
>>> first
>>> think about what formal model they are actualy using, thus resulting in
>>> cleaner module design.
>>>       
>> I *really* dislike this idea. It seems to set up the situation that the
>> only acceptable modules are those that follow some "formal" model.
>> Problems:
>> ...
>>     * The proposal only allows a single implementation of each formal
>>       model. In theory, theory is just like practice, but in practice it
>>       is not. SMACK and SELinux follow substantially similar formal
>>       models (not exactly the same) so should we exclude one and keep
>>       the other? No, of course not, because in practice they are very
>>       different.
>>     
> I would think the two may benefit from a role as described above.
> But I was thinking more in the line of new modules that may again
> implement this same model, and would thus benefit from interaction with
> this 'model maintainer' role.
>   
Ah! So the proposal really is to have an LSM maintainer for each
"family" of models, acting as a resource and arbiter for modules in a class.

I like that idea, and have no objection to it. However, it does have
resource problems, in that the pool of LSM maintainers is not that
large. There is also the likely objection that this degree of scale is
not needed until at least there are multiple families of models in the
upstream kernel, and possibly until there are multiple instances of a
single family in the upstream kernel.

It also begs the question of what constitutes a family.

    * AppArmor, SELinux, and TOMOYO are all ambient capability systems
          o AppArmor and TOMOYO are pathname based
          o SELinux is label based
    * SELinux and SMACK are label-based
          o I don't know if SMACK is an ambient capability system
    * Rob Meijer implicitly advocated for an object capability LSM
          o would it be pathname or label based? You could do either or
            both ...
    * The LSPP work from RH, Tresys, and TCS is MLS based
          o this is a subset of both label-based and ambient capability
            based
    * I have no clue what family to put MultiADM or Dazuko into
    * Getting very formal, I could imagine a Clarke-Wilson module
    * Getting very informal, I could imagine a module that is a
      collection of cute intrusion prevention hacks, such as the Open
      wall Linux symlink and hardlink restrictions, and my own RaceGuard
      work
          o Oh wait, I published
            <http://citeseer.ist.psu.edu/cowan01raceguard.html>
            RaceGuard. Does that make it formal? :-)

Crispin

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

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Rob Meijer <capibara@xs4all.nl> wrote:


> >     * The proposal only allows a single implementation of each formal
> >       model. In theory, theory is just like practice, but in practice it
> >       is not. SMACK and SELinux follow substantially similar formal
> >       models (not exactly the same) so should we exclude one and keep
> >       the other? No, of course not, because in practice they are very
> >       different.
> 
> I would think the two may benefit from a role as described above.
> But I was thinking more in the line of new modules that may again
> implement this same model, and would thus benefit from interaction with
> this 'model maintainer' role.

The Smack development has benefited greatly from comments, suggestions,
and bug reports from members of the SELinux community. Further, I have
had no trouble whatever sharing the netlabel component with SELinux.
Audit is another matter as it requires some work to get the SELinux
dependencies out, but everyone's been receptive to proposals there.
Why on earth would I want some 'model maintainer' passing judgements
on my work in progress? The only thing I can imagine a 'model
maintainer' doing is obstructing innovation. Unless it was me, of
course. Linus is right, you know.


Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Toshiharu Harada]

On 10/25/2007 10:42 AM, Casey Schaufler wrote:
> I agree that security code does need to provide security. What we
> need to get away from is the automatic attacks that are based on 20th
> century computer system assumptions. Things like "name based access
> control is rediculous", and "a module can't be any good if it doesn't
> deal with all objects", or "the granularity isn't fine enough". Look
> at TOMOYO. It's chuck full of good ideas. Why spend so much energy
> badgering them about not dealing with sockets? How about helping the
> AppArmor crew come up with acceptable implementations rather than
> whinging about the evils of hard links? And maybe, just maybe, we can
> get away from the inevitable claim that you could do that with a few
> minutes work in SELinux policy, but only if you're a security
> professional of course.

Casey,

Thank you introducing TOMOYO Linux. I really like your idea of
simplified MAC (and you work so hard!). I also find advantages
of AppArmor for distributing policies with less hustle. Finally
and most importantly, I respect SELinux as the first in-tree,
flexible and reliable security frame work and respect developers
involved.

As a project manager of TOMOYO Linux, I would like to
push it, of course. But I noticed, if each of LSM module
developer begin pushing their own code, that's not for the
sake of Linux and we may end up with chaos.

Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in

http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

I would like to receive feedbacks from Stephen, Crispin
(you already have a comparison, though :),
Casey and any people interested in. If possible,
I would like to include opinions from BSD people.

I would like LSM to be the result of common requirements.
"Common" means good in general, but not always for security
perspective. IMHO, I think it is possible for us to get to the
conclusion not to have a framework.

Cheers (and with love to Linux),
Toshiharu Harada

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Toshiharu Harada]

On 10/25/2007 9:41 AM, Chris Wright wrote:
> * Linus Torvalds (torvalds@linux-foundation.org) wrote:
>> Do other people want to stand up and be "LSM maintainers" in the sense 
>> that they also end up being informed members who can also stand up for new 
>> modules and help merge them, rather than just push the existing one(s)? 
>> Chris? Casey? Crispin?
> 
> Stephen and James, despite their clear bias towards SELinux, do try to
> give good feedback.  But you are right, there's not enough active help
> for people trying to make a contribution to get their code in shape.
> Many of the modules that come along have been misguided conceptually,
> but I think that e.g. apparmor, tomoyo, smack could use that kind
> of constructive help to get into final mergable shape.  Personally,
> I haven't spent nearly enough time reviewing those, my apologies to
> those developers.  So, yes, help is welcome.

Yes, TOMOYO Linux is committed to help.
I mean, please count me in.

PS
Chris, I've been waiting for your comments for our code. :)

Regards,
Toshiharu Harada

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

On 10/30/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> Ah! So the proposal really is to have an LSM maintainer for each
> "family" of models, acting as a resource and arbiter for modules in a class.

I see it a little bit different one LSM maintainer for the lot of
modules who kicks the ass's of thoses who are not prepaid to share.
>
> I like that idea, and have no objection to it. However, it does have
> resource problems, in that the pool of LSM maintainers is not that
> large. There is also the likely objection that this degree of scale is
> not needed until at least there are multiple families of models in the
> upstream kernel, and possibly until there are multiple instances of a
> single family in the upstream kernel.
>
> It also begs the question of what constitutes a family.
>
>     * AppArmor, SELinux, and TOMOYO are all ambient capability systems
>           o AppArmor and TOMOYO are pathname based
>           o SELinux is label based

Here as always all three should see where they can share code and get
the best performance this might mean AppArmor and Tomoyo use Selinux
labels because it causes less overhead.  Or Selinux provides a
optional path based using the other engine.  Both are providing the
same feature in different ways.   Question does have to be asked is
there bench testable justification for need two for file systems
filters.

>     * SELinux and SMACK are label-based
>           o I don't know if SMACK is an ambient capability system

Both of these are sharing backwards and forwards between each other so
being nice with each other.  LSM overall Maintainer only really need
to at worst way xyz sections are not merged/shared and to document why
with benchmarks if they are not going to be.  Ie tested reason.

>     * Rob Meijer implicitly advocated for an object capability LSM
>           o would it be pathname or label based? You could do either or
>             both ...
Both is a valid answer.   Sections done path based should be shared
with other path based and labal based shared with other label based.

>     * The LSPP work from RH, Tresys, and TCS is MLS based
>           o this is a subset of both label-based and ambient capability
>             based
Ok section by section where would it be best for that code base to share with.

>     * I have no clue what family to put MultiADM or Dazuko into
MultiADMIN falls under o my god head ache.  This is more a posix
standard feature altered ie 1 root user turned into many.  This really
risks breaking the other models as a LSM.  Its more of a all in or all
out.  Really it needs to be lowered out of LSM into a standard
optional Linux feature so it cannot breach the security of other LSM
modules.  Also LSM modules will need to be made able to tell a
MultiADMIN root users.  This is part of what I was talking about some
parts need to be as lower down module not at full blown LSM level.
This is the rare one where the complete model needs to be moved down.
There are bits in almost all LSM that need to be looked at being made
full time features of linux like quotas and posix file capability's .

Dazuko is the rare user mode controlled interface.  Still same rule
share code where able.  Anti-Virus integration and other protecting
systems are commonly overlooked by LSM's.    Same here if this should
be a LSM or a kernel optional feature independent to LSM that a LSM
can block from happening.

>     * Getting very formal, I could imagine a Clarke-Wilson module
>     * Getting very informal, I could imagine a module that is a
>       collection of cute intrusion prevention hacks, such as the Open
>       wall Linux symlink and hardlink restrictions, and my own RaceGuard
>       work
>           o Oh wait, I published
>             <http://citeseer.ist.psu.edu/cowan01raceguard.html>
>             RaceGuard. Does that make it formal? :-)
>
You will hate me but I don't call that formal enough.  Its lacks the
critical bit of doc written in terms that any system admin can
understand what they are being given.

Next question should RaceGuard be a LSM at all.  Or should it be a
standard feature what LSM can over rule? <Swap RaceGuard out standard
question for all new LSM's and LSM features>

Lot of things are being pushed as LSM's when they should be pushed as
expanded default features outside LSM.

Peter Dolding

Re: Defense in depth: LSM *modules*, not a static interface

[Al Viro]

On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
> Defense in depth has long been recognised as an important secure design 
> principle. Security is best achieved using a layered approach.
 
"Layered approach" is not a magic incantation to excuse any bit of snake
oil.  Homeopathic remedies might not harm (pure water is pure water),
but that's not an excuse for quackery.  And frankly, most of the
"security improvement" crowd sound exactly like woo-peddlers.

Defense in depth: LSM *modules*, not a static interface

[Cliffe]

Defense in depth has long been recognised as an important secure design 
principle. Security is best achieved using a layered approach.

On a single system it makes sense to have a layered approach such as:

Standard DAC (where users are in control of permissions)
Some form of user-based non-DAC (where admins can specify what users can 
specifically do) such as SELinux or SMACK
System-wide firewall (netfilter)
Some form of sandboxes/namespace isolation (chroot, jails...)
General application confinement such as DTE (SELinux), or Capability 
lists (AppArmor, systrace ...)
Application network confinement - firewall to confine individual apps 
(maybe included in the above)
IDS or IPS
Malware scanner
Posix Capabilities
Pax/RaceGuard
...[insert innovation here]...

And while I acknowledge that many of these layers are currently buried 
within the kernel (netfilter...) they are security layers which in many 
cases would probably make sense as stackable security modules.

Making the interface static forces mammoth solutions which then must 
attempt to solve all of the above in one ls*m*. What happened to 
dividing tasks into easy to manage chunks?

Regards,

Z. Cliffe Schreuders
BSc Comp Sci (Hons) & Int Comp
PhD Candidate, Casual Tutor
School of IT
Murdoch University

Re: Defense in depth: LSM *modules*, not a static interface

[Crispin Cowan]

Al Viro wrote:
> On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
>   
>> Defense in depth has long been recognised as an important secure design 
>> principle. Security is best achieved using a layered approach.
>>     
>  "Layered approach" is not a magic incantation to excuse any bit of snake
> oil.  Homeopathic remedies might not harm (pure water is pure water),
> but that's not an excuse for quackery.  And frankly, most of the
> "security improvement" crowd sound exactly like woo-peddlers.
>   
Frank's point was that the static interface makes layering somewhere
between impractical and impossible. The static interface change should
be dumped so that layering is at least possible. Whether any given
security module is worth while is a separate issue.

I.e. that there are bad medicines around is a poor excuse to ban
syringes and demand that everyone be born with a strong immune system.

Why is it that security flame wars always end up reasoning with absurd
analogies? :-)

Crispin

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

Re: Defense in depth: LSM *modules*, not a static interface

[Cliffe]

Al Viro wrote:
> On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
>   
>> Defense in depth has long been recognised as an important secure design 
>> principle. Security is best achieved using a layered approach.
>>     
>  
> "Layered approach" is not a magic incantation to excuse any bit of snake
> oil.  Homeopathic remedies might not harm (pure water is pure water),
> but that's not an excuse for quackery.  And frankly, most of the
> "security improvement" crowd sound exactly like woo-peddlers.
>   

I agree completely; but layers that provide actual security improvements 
are important.

--

Z. Cliffe Schreuders
BSc Comp Sci (Hons) & Int Comp
PhD Candidate, Casual Tutor
School of IT
Murdoch University

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Oct 30 2007 12:23, Toshiharu Harada wrote:
>
> Instead of pushing TOMOYO Linux, I started developing
> comparison chart of security-enhance Linux implementations.
> The current version can be found in
>
> http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

Smack Security Model: autolabel, as far as I can tell.
Smack Policy Generation: user - hand - and an editor
Apparmor tutorial (beats any FAQ at first):
	ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Crispin Cowan]

Jan Engelhardt wrote:
> Apparmor tutorial (beats any FAQ at first):
> 	ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
>   
Thanks for the high praise. Unfortunately that FTP site seems to not be
working. Some alternatives:

    * My personal copy of the above video
      http://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi
    * Similar talk at linux.conf.au 2007
      http://youtube.com/watch?v=EgrfmSm0NWs
    * Similar talk at Defcon 2007
      http://video.google.com/videoplay?docid=-1731833784646588861&hl=en

Crispin

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

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Toshiharu Harada]

On 10/30/2007 5:40 PM, Jan Engelhardt wrote:
> On Oct 30 2007 12:23, Toshiharu Harada wrote:
>> Instead of pushing TOMOYO Linux, I started developing
>> comparison chart of security-enhance Linux implementations.
>> The current version can be found in
>>
>> http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
> 
> Smack Security Model: autolabel, as far as I can tell.
I noticed the smell of danger in the naming of "Security Model".
Please allow me some time.

> Smack Policy Generation: user - hand - and an editor
> Apparmor tutorial (beats any FAQ at first):
> 	ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
Updated above two items. Thank you. :)

I'm not an optimist to believe we can reach the perfect
comparison. The purpose is to feed information, not to judge.
This might sound ironically, but I don't really think
we can *compare* them because they have different
theories/purposes/backgrounds. Some kind of forgiveness and
fuzziness are required.

As I don't want to steal everybody's bandwidth,
simple updates will be done silently. Your suggestions and
information will be greatly appreciated despite of
visible evidence.

Thank you.
Toshiharu Harada

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Oct 30 2007 01:50, Crispin Cowan wrote:
>Jan Engelhardt wrote:
>> Apparmor tutorial (beats any FAQ at first):
>> 	ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
>>   
>Thanks for the high praise. Unfortunately that FTP site seems to not be
>working. Some alternatives:
[...]

Actually, if the selinux team would do the same [introductionary video],
I'd guess the hardness level commonly associated with selinux could be
relieved a bit.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Bernd Petrovitsch]

On Thu, 2007-10-25 at 09:04 -0700, Ray Lee wrote:
> On 10/25/07, Bernd Petrovitsch <bernd@firmix.at> wrote:
> > On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
> > [....]
> > > Key-based masterlocks are easily broken with freon, and their combo
> > > locks are easily brute-forced in about ten minutes. Yet, I'll still
> > > use them to lock up my bike and garage.
> >
> > The question is what the security threat is and the value of the secured
> > items.
> >
> > > The idea that poor security is worse than no security is fallacious,
> > > and not backed up by common experience.
> >
> > The common experience is, that common people just *feel* safer (just
> > because they have poor security).
> 
> Do you lock your bike up when you leave it lying around? My point is
> that real security comes in layers, not one perfect solution that will
> always work everywhere for everyone. The latter is a pipe-dream.

Of course not. "Security" as such is more than less "only" risk
management (or part of it - depending of the viewpoint).

> > With no security, they know that there is no security. With poor
> > security, they do not know (or can deny) that they have next to no real
> > security.
> 
> The fallacy here is to believe that just because they have no
> security, that it will *in*any*way* change their behavior. I deal with
> real users daily, and *they*don't*care*. Further, there's no level of

If people don't care, they are pretty lost anyway.
That's actually the reason for all that security stuff that no one wants
but which stands in the way of all people just because of the "don't
care" faction (which by far the majority of all in any given area).
But there is that (also not too small) "I installed $PERSONAL_FIREWALL
and *nothing* can happen because $VENDOR and $TECH_JOURNALIST in
$LOW_QUALITY_PC_MAG said so" faction.

> education that we can instill into the community to make them aware of
> the issues and change their habits accordingly, because real users
> don't have the background to understand those lessons.
> 
> While you can teach them that running an executable from someone they
> haven't heard of is obviously bad, they don't know why downloading an
> image is potentially dangerous, "it's an image, right?" "Well, there's
> these things called buffer overflows..." <eyes glaze over>
> 
> Security is not an all or nothing game, it's layers. And we have to

And every layer/subsystem/area must be checked and seen independently of
others (or the dependency must be that strong that no one can work
around).
And every security layer will and should have it's purpose and targets.

> make sure that the layers are usable without taking a course from the
> NSA. I'd love to see a poll of the kernel development community to
> find out how many use SELinux on their machines, for example.

"selinux=0" on the kernel commandline is normal - no unknown people have
logins and so there was no reason to learn it. And against should it
protect in the first place if only trusted people are there?

> > The prime example here is the usual (so-called) "personal firewall" on
> > Windows where people work normally as "administrator".
> 
> So your argument is that if there weren't a personal firewall on
> Windows, that a significant number of people would then not run as
> Administrator? I beg to differ.

No, how do you come to that conclusion?

People login as "Administrator" because they did it since DOS3.0.
People buy and install $PERSONAL_FIREWALL because some cheap PC tech
magazine had advertisements for them.
Next generation (or this generation?) viruses/malware will either
reconfigure $PERSONAL_FIREWALL silently (and if course only
temporarily).
And the vendor of $PERSONAL_FIREWALL writes into the manual (which no
one reads) or the EULA (which no one reads because it isn't relevant in
the first place) or some README (which no one finds) that one must not
login as "Administrator". But that just to keep the vict^Wbuyers to not
sue them. And working on Win* without being "Administrator" is a real
PITA - so the average user won't do it for long.

So apart from the personal feelings of that user I can't find any sign
of security.

BTW from a commercial viewpoint, the (so-called) "personal firewalls"
were probably one of the best ideas (and another major example that
technical expertise has nothing to do with sales success).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: Defense in depth: LSM *modules*, not a static interface

[Simon Arlott]

On Tue, October 30, 2007 07:14, Cliffe wrote:
> And while I acknowledge that many of these layers are currently buried
> within the kernel (netfilter...) they are security layers which in many
> cases would probably make sense as stackable security modules.
>
> Making the interface static forces mammoth solutions which then must
> attempt to solve all of the above in one ls*m*. What happened to
> dividing tasks into easy to manage chunks?

Would it be possible to have Kconfig select which LSM should handle each
area of security? Selecting LSM A would automatically disable LSM B and
C since they both implement the same security functions, while LSM D
would still be selectable since it implements something else. The default
capabilities code would then turn off parts of itself that another LSM
is handling.

Alternatively the M in LSM can be restored and modules can be stacked.
It should be possible for the primary LSM to check the security_ops of the
secondary LSM(s) and complain if it considers there to be an incompatiblity.

-- 
Simon Arlott

Re: Defense in depth: LSM *modules*, not a static interface

[Casey Schaufler]

--- Crispin Cowan <crispin@crispincowan.com> wrote:

> Al Viro wrote:
> > On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
> >   
> >> Defense in depth has long been recognised as an important secure design 
> >> principle. Security is best achieved using a layered approach.
> >>     
> >  "Layered approach" is not a magic incantation to excuse any bit of snake
> > oil.  Homeopathic remedies might not harm (pure water is pure water),
> > but that's not an excuse for quackery.  And frankly, most of the
> > "security improvement" crowd sound exactly like woo-peddlers.
> >   
> Frank's point was that the static interface makes layering somewhere
> between impractical and impossible. The static interface change should
> be dumped so that layering is at least possible. Whether any given
> security module is worth while is a separate issue.
> 
> I.e. that there are bad medicines around is a poor excuse to ban
> syringes and demand that everyone be born with a strong immune system.
> 
> Why is it that security flame wars always end up reasoning with absurd
> analogies? :-)

That's my fault, sorry. I don't know why it's my fault,
but that's where it usually ends up and I thought I'd get
the blame bit out of the way. Gotta go squeeze some legless
reptiles now.


Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

(please do not drop Cc, or I would have lost this thread part if I had 
not been on lkml. And sometimes I am not because of the volume. Thanks.)

On Oct 30 2007 15:13, Peter Dolding wrote:
>On 10/30/07, Crispin Cowan <crispin@crispincowan.com> wrote:
>
>>     * I have no clue what family to put MultiADM or Dazuko into
>
>MultiADMIN falls under o my god head ache.  This is more a posix
>standard feature altered ie 1 root user turned into many.  This really
>risks breaking the other models as a LSM.

I disagree.

Traditionally, Linux has given a process all capabilities when the
UID changed to 0 (either by setuid(2) or executing a SUID binary).
This has been relieved over the years, and right now with LSMs in the
field, it is possible to 'deactivate' this special case for UID 0.

SELinux does not have this special case for UID 0. Neither does it
seem to use capabilities (quick grep through the source). So
basically, all users are the same, and no one has capabilities by
default. Does SELinux thus break with other LSMs?

Now assume a SELinux system where all users have all capabilities
(and the policy that is in place restricts the use of these
capabilities then) -- should not be that unlikely. Does that break
with other LSMs?

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Jan Engelhardt <jengelh@computergmbh.de> wrote:

> 
> (please do not drop Cc, or I would have lost this thread part if I had 
> not been on lkml. And sometimes I am not because of the volume. Thanks.)
> 
> On Oct 30 2007 15:13, Peter Dolding wrote:
> >On 10/30/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> >
> >>     * I have no clue what family to put MultiADM or Dazuko into
> >
> >MultiADMIN falls under o my god head ache.  This is more a posix
> >standard feature altered ie 1 root user turned into many.  This really
> >risks breaking the other models as a LSM.
> 
> I disagree.
> 
> Traditionally, Linux has given a process all capabilities when the
> UID changed to 0 (either by setuid(2) or executing a SUID binary).
> This has been relieved over the years, and right now with LSMs in the
> field, it is possible to 'deactivate' this special case for UID 0.
> 
> SELinux does not have this special case for UID 0. Neither does it
> seem to use capabilities (quick grep through the source). So
> basically, all users are the same, and no one has capabilities by
> default. Does SELinux thus break with other LSMs?
> 
> Now assume a SELinux system where all users have all capabilities
> (and the policy that is in place restricts the use of these
> capabilities then) -- should not be that unlikely. Does that break
> with other LSMs?

As some of the early Smack discussions brought out, some LSMs
including Smack will be perfectly happy with the traditional
Linux privilege mechanisms (choice of root and/or capablities)
while others including SELinux will go their own ways. So long
as LSMs are self contained and strictly restrictive the
mechanisms they use to modulate their behavior shouldn't be an
issue. If SELinux chooses to turn its MLS controls off between
midnight and 3am I can't see how that would be Smack's business,
even if they were somehow stacked. Multiple LSMs has issues,
like what should security_secid_to_secctx() return to the audit
system, but privilege model shouldn't be one of them.


Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Oct 30 2007 12:14, Casey Schaufler wrote:
>
>while others including SELinux will go their own ways. So long
>as LSMs are self contained and strictly restrictive the
>mechanisms they use to modulate their behavior shouldn't be an
>issue. If SELinux chooses to turn its MLS controls off between
>midnight and 3am I can't see how that would be Smack's business,
>even if they were somehow stacked. Multiple LSMs has issues,
>like what should security_secid_to_secctx() return to the audit
>system, but privilege model shouldn't be one of them.

I am with you on that. And for everybody who missed it: MultiAdmin
only grants rights at the same time commoncap does (e.g. on setuid
and bprm_set_security). And all modules DO work with commoncap, now
don't they?

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

Jan Engelhardt wrote:
> I disagree.
>
> Traditionally, Linux has given a process all capabilities when the
> UID changed to 0 (either by setuid(2) or executing a SUID binary).
> This has been relieved over the years, and right now with LSMs in the
> field, it is possible to 'deactivate' this special case for UID 0.
>   
> SELinux does not have this special case for UID 0. Neither does it
> seem to use capabilities (quick grep through the source). So
> basically, all users are the same, and no one has capabilities by
> default. Does SELinux thus break with other LSMs?
>
> Now assume a SELinux system where all users have all capabilities
> (and the policy that is in place restricts the use of these
> capabilities then) -- should not be that unlikely. Does that break
> with other LSMs?
>   
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules 
are applied over using Selinux rules.  This is just the way it is 
stacking LSM's is Just not healthy you always risk on LSM breaking 
another.  Part of the reason why I have suggested a complete redesign of 
LSM.  To get away from this problem of stacking.

I see MultiAdmin purely in the class of posix file capabilities( Fine 
grained replacement to SUID).
This is a standard feature fix not part of LSM.  Note it can not replace 
all SUID bits due to some internals of applications design need to be 
changed to support posix file capabilities in particular not checking if 
running as UID 0.  Traditional  UID 0 is already optional for 
applications without  LSM's.

Posix file capabilities only applies to applications only.  MultiAdmin 
being the user mirror of Posix file capabilities.

MultiAdmin patch to the user side may allow more SUID bits to be killed 
off from the start line.  So increasing overall system security.

Of course MultiAdmin might end up two halfs.   One a standard feature 
that hands out capabilities to users that LSMs can overrule.  And one a 
user by user directory access control LSM directory control LSM less 
likely to cause problems.

I really don't see the need for a LSM stacking order.  Some features 
just should not be LSM's in my eyes.  MultiAdmin is one of them.

Traditional way has all ready been expanded for applications without 
LSM's.  So my call still stand O heck head ache rating.   Because its in 
the wrong place.  Particularly when you think people will want to use it 
stacked with other LSM's.   Stacking should be avoided where able.   
This means at least some of Multiadmin features just have to be done 
core kernel as a normal kernel module to avoid stacking and breaking the 
LSM.

Note posix file capabilities was developed as a LSM module too at first 
the point came where it was going to cause more trouble for other LSMs 
granting stuff in conflict.    Both Multiadmin and posix file 
capabilities share a lot in common.  Both developed in the wrong place.  
Both required to be else where.  Even there function is similar breaking 
down root powers and handing them out more effectively.  So in my eyes 
it is a pure Posix extension not a LSM.

Peter Dolding

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[david]

On Wed, 31 Oct 2007, Peter Dolding wrote:

> MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are 
> applied over using Selinux rules.  This is just the way it is stacking LSM's 
> is Just not healthy you always risk on LSM breaking another.  Part of the 
> reason why I have suggested a complete redesign of LSM.  To get away from 
> this problem of stacking.

since the method of stacking hasn't been determined yet, you can't say 
this.

it would be possible for MultiAdmin to grant additional access, that 
SELinux then denies for it's own reasons.

if the SELinux policy is written so that it ignores capabilities, and 
instead just looks at uid0 then that policy is broken in a stacked 
environment, but it's the polciy that's broken, not the stacking.

yes, there will be interactions that don't make sense, but just becouse 
something can be used wrong doesn't mean that there aren't other cases 
where it can be used properly.

David Lang

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

On 10/31/07, david@lang.hm <david@lang.hm> wrote:
> On Wed, 31 Oct 2007, Peter Dolding wrote:
>
> > MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
> > applied over using Selinux rules.  This is just the way it is stacking LSM's
> > is Just not healthy you always risk on LSM breaking another.  Part of the
> > reason why I have suggested a complete redesign of LSM.  To get away from
> > this problem of stacking.
>
> since the method of stacking hasn't been determined yet, you can't say
> this.

I can because that is the current day problem. With many LSM's loaded
they stack completely as a complete mess and with problems.  They
fight with each other.  Lack of define on stacking equals big
problems.   Since you have not created a standard for stacking does
not stop the problem from existing.  Nice lack of planing when LSM
started or maybe its intentional.  When you need stacking its about
time you start moving things into the OS?

There is a way around the problem too without allowing LSM to stack.
Good advantage backward compatible  because your are not playing with
the LSM standard to do it so no LSM modules should need large
alterations.  At worse mirror extensions to handle the new OS feature.
 Posix File Capabilities provide the solution.   First done as a LSM
risked conflict.   Moved in as a operating system extension by by
conflict.  Fragments from LSM's should exactly move that way if they
expect to be overlapped by other models.

Lot of stacking problems can be avoided if segments are complete
standard extensions.
>
> it would be possible for MultiAdmin to grant additional access, that
> SELinux then denies for it's own reasons.
>
> if the SELinux policy is written so that it ignores capabilities, and
> instead just looks at uid0 then that policy is broken in a stacked
> environment, but it's the polciy that's broken, not the stacking.

That is not how current day always works.  MultiAdmin grants and that
can be the end of the treeing.   Selinux does not get asked if it
refuses it or not.  So no matter what was set in the Selinux policy it
may never get used.   Adding more layers is also bad for performance
to.  Treeing threw modules for rights is a really slow process.  As
like a posix feature extension.   Selinux/Other LSM's is at top of
allocation no flaw no bypass.

> yes, there will be interactions that don't make sense, but just becouse
> something can be used wrong doesn't mean that there aren't other cases
> where it can be used properly.
>
We are talking security here if its not order safe its not good.
MultiAdmin done as a posix feature extension is order safe.
MultiAdmin done as a LSM is not order safe.

System Admins are humans too.  Getting orders backwards does happen.
So should be avoided where able.

This completely avoids the need for adding another layer of stacking
and since built inside current day framework.  Does doing this risk
the end of LSM's as we know it yes it does.  Since it is not being
used as LSM were intended.  LSM is just a addon to standard OS
security what is either a testing ground for new features to secure
the OS that get build into the OS in time or as location for security
modules.

Somethings should be just done in the Standard OS security nothing to
do with LSM.

Little bit hard for some I guess to hear that LSM are not all
important and not all Security features should be done in them.  Some
should be done in the main OS security features.

Biggest current day problem with LSM is they have forgot that LSM is
only a testing ground or a zone for features that people will only
want some of the time.

MultiAdmin is a feature that can enhance means to Audit OS ie who did
what.  Enhance security hand outs and can be really handy with almost
any LSM on the system.  Its description of what it is sounds very much
like every other standard feature.

Lets end the bitrot.  Start having bits go into the main OS security
features where they should be.

Peter Dolding

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Peter Dolding <oiaohm@gmail.com> wrote:


> Lets end the bitrot.  Start having bits go into the main OS security
> features where they should be.

Gawd. Sorry, but we lost that argument in 1986 and the situation
hasn't changed a bit since. Most people just don't want what we're
selling. Do you know why Unix was a success and MULTICS* a failure?
It's because Unix had mode bits and MULTICS had ACLs. Fortunately
for those of us who wear titles like "Security Expert" or "Trust
Technologist" with pride there are enough clinical paranoids in
positions of authority to keep the Trusted System niche from closing
up completely and hence supporting our Rock Star Lifestyles. The
good news is that the situation is no worse than that faced by
the people who are bringing you Infiniband or Itanium, neither of
which will ever be the life of the party either. Sure security is
important, but I learned (in college, and yes they had colleges
way back then) not to drink too much at parties I'd crashed.

LSM isn't all I want it to be either, but it's better than I ever
got in the Proprietary OS world, and that includes when the MLS
systems were bringing in $20million a pop. Trying to force features
that virtually no one wants into any system is a bad idea. If
you haven't read Man of LaMancha I strongly suggest you do so.
Or at least see the play, it's got some catchy songs.

-----
* If you don't know what MULTICS was you can buy me a beer and
  I'll tell you the whole story


Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[david]

On Wed, 31 Oct 2007, Peter Dolding wrote:

> On 10/31/07, david@lang.hm <david@lang.hm> wrote:
>> On Wed, 31 Oct 2007, Peter Dolding wrote:
>>
>>> MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
>>> applied over using Selinux rules.  This is just the way it is stacking LSM's
>>> is Just not healthy you always risk on LSM breaking another.  Part of the
>>> reason why I have suggested a complete redesign of LSM.  To get away from
>>> this problem of stacking.
>>
>> since the method of stacking hasn't been determined yet, you can't say
>> this.
>
> I can because that is the current day problem. With many LSM's loaded
> they stack completely as a complete mess and with problems.  They
> fight with each other.  Lack of define on stacking equals big
> problems.   Since you have not created a standard for stacking does
> not stop the problem from existing.  Nice lack of planing when LSM
> started or maybe its intentional.  When you need stacking its about
> time you start moving things into the OS?

the lack of a stacking ability was deliberate (go back and read the 
archives). basicly no LSM was willing to admit that they weren't the 
be-all, end-all of security, so nobody was willing to consider that anyone 
would ever want anything else.

one method of doing the stacking would be for the LSM to not know about 
the stacking, but the kernel takes care of passing all requests through 
each LSM in order (if the LSMs can be staticly compiled the order should 
be able to be changed at compile time)

now, the existing policies for some LSM's may need to change, becouse 
they've been assuming that they only needed to check capabilities for 
UID=0, when they will now need to check them for everyone, but arguably, 
this was a bug masquerading as an optimization in the first place.

> There is a way around the problem too without allowing LSM to stack.
> Good advantage backward compatible  because your are not playing with
> the LSM standard to do it so no LSM modules should need large
> alterations.  At worse mirror extensions to handle the new OS feature.
> Posix File Capabilities provide the solution.   First done as a LSM
> risked conflict.   Moved in as a operating system extension by by
> conflict.  Fragments from LSM's should exactly move that way if they
> expect to be overlapped by other models.
>
> Lot of stacking problems can be avoided if segments are complete
> standard extensions.

which LSM gets to declare the standards?

>>
>> it would be possible for MultiAdmin to grant additional access, that
>> SELinux then denies for it's own reasons.
>>
>> if the SELinux policy is written so that it ignores capabilities, and
>> instead just looks at uid0 then that policy is broken in a stacked
>> environment, but it's the polciy that's broken, not the stacking.
>
> That is not how current day always works.  MultiAdmin grants and that
> can be the end of the treeing.   Selinux does not get asked if it
> refuses it or not.  So no matter what was set in the Selinux policy it
> may never get used.   Adding more layers is also bad for performance
> to.  Treeing threw modules for rights is a really slow process.  As
> like a posix feature extension.   Selinux/Other LSM's is at top of
> allocation no flaw no bypass.

only if the stacking mode permits this. if it always requires passing 
through all the layers then this wouldn't be a problem.

Besides which, the MultiAdmin authors would probably be willing to make 
the nessasary changes to their LSM to play nicely with others anyway (but 
good programming practice would dictate that you don't count on it, and 
arrange for the other modules to approve as well)

>> yes, there will be interactions that don't make sense, but just becouse
>> something can be used wrong doesn't mean that there aren't other cases
>> where it can be used properly.
>>
> We are talking security here if its not order safe its not good.
> MultiAdmin done as a posix feature extension is order safe.
> MultiAdmin done as a LSM is not order safe.

as things are currently written, it's not possible to stack, so there is 
no order. change how things are written and you can make them safe.

> System Admins are humans too.  Getting orders backwards does happen.
> So should be avoided where able.

the sysadmins need to be given enough rope, you don't know everything that 
they are trying to do, and you don't know what other LSMs going to do. so 
how can you possibly decide ahead of time what orders are safe?

> This completely avoids the need for adding another layer of stacking
> and since built inside current day framework.  Does doing this risk
> the end of LSM's as we know it yes it does.  Since it is not being
> used as LSM were intended.  LSM is just a addon to standard OS
> security what is either a testing ground for new features to secure
> the OS that get build into the OS in time or as location for security
> modules.
>
> Somethings should be just done in the Standard OS security nothing to
> do with LSM.
>
> Little bit hard for some I guess to hear that LSM are not all
> important and not all Security features should be done in them.  Some
> should be done in the main OS security features.
>
> Biggest current day problem with LSM is they have forgot that LSM is
> only a testing ground or a zone for features that people will only
> want some of the time.

no, LSM is not just for testing, LSM is an interface so that Linus doesn't 
need to pick the 'one true security model' and enforce it on everyone.

it's like freedom of religion, each religion belives that they are the one 
true path, but in exchange for the guarentee that they are not going to be 
percecuted, they reluctantly allow all other religions equal freedom. when 
religion passes from mearly strange to activly harmful (i.e. cults) you 
find the edge of the freedom.

similarly, LSMs need to accept the fact that some people don't want their 
flavor of security, so to avoid being thrown out entirely they need to 
allow other LSMs to exist, and use the same kernel hooks, even if they 
believe that the alturnatives are misguided. as long as an LSM is not 
activly harmful (as opposed to mearly being snake oil) it should be 
allowed.

> MultiAdmin is a feature that can enhance means to Audit OS ie who did
> what.  Enhance security hand outs and can be really handy with almost
> any LSM on the system.  Its description of what it is sounds very much
> like every other standard feature.
>
> Lets end the bitrot.  Start having bits go into the main OS security
> features where they should be.

which bits into which security features? Good, knowledgable people can't 
agree on what's right.

ending the bitrot just requires accepting the LSMs into the kernel as 
first-class options, it doesn't require declaring any one LSM (or even any 
part of any one LSM) as being the 'one right way' to do something and 
force everyone to use that way.

David Lang

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Crispin Cowan]

Peter Dolding wrote:
> Lets end the bitrot.  Start having bits go into the main OS security
> features where they should be.
>   
Linus categorically rejected this idea, several times, very clearly.

He did so because the security community cannot agree on a
one-true-standard for what that OS security feature set should be. From
looking at this thread and many others, he is correct; there is no
consensus on what the feature set should be.

So you can wish for the "main OS security features" all you want, but it
is not going to happen without a miraculous degree of consensus abruptly
arising.

On the contrary, security, done well, is a tight fitting suit. It must
be tight, or it allows too much slack and attackers can exploit that. To
make it tight, it must be tailored to the situation at hand. That means
that there may *never* be a consensus on the "one true way", because it
could be that there is no "one true way". It could be that SMACK is best
in some cases, AppArmor in others, SELinux in others yet again, MLS in
others, etc. etc.

I agree with Casey; LSM may not be perfect, but it is a great deal more
consensus than I have seen anywhere else in the security community. Your
desire that AppArmor and SELinux should share code has already happened:
LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and
TOMOYO, and MultiADM, etc.

It certainly can be improved, but it is not in need of wholesale
replacement, and especially not without a clear design that addresses
clearly stated problems that lots of people are having.

Crispin

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

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

On 10/31/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> Peter Dolding wrote:
> > Lets end the bitrot.  Start having bits go into the main OS security
> > features where they should be.
> >
> Linus categorically rejected this idea, several times, very clearly.
>
> He did so because the security community cannot agree on a
> one-true-standard for what that OS security feature set should be. From
> looking at this thread and many others, he is correct; there is no
> consensus on what the feature set should be.
>
> So you can wish for the "main OS security features" all you want, but it
> is not going to happen without a miraculous degree of consensus abruptly
> arising.
>
Not really.  Every time Linus has rejected is when people have tried
to thump complete models like Selinux into kernel as one huge mother
of a blocks without grounds.

MultiAdmin is different most other models.  Please look at Posix File
Capabilities.  Grounds and security advantages of that module was
proven while not fighting with other LSM means to do protection.
There are grounds for many admins in linux for tracking admin
alterations.  It falls into a cat of a feature request and security
feature.  Of course not all of MultiAdmin features will be suitable at
main OS security features.  Yes MultiAdmin will have to be happy to
break there code up to get the as there key feature to as many users
as able.  This is a difference UID 0 all powerful I guess everyone
here can agree that is not exactly good.  Not being able to trace who
did alterations as UID 0 is not good either.  Where does the other
frameworks deal with it.

The path is still open into kernel.  Complete models of course are
never going to make it.  100 percent consensus is not always required.
 Same reasons for Posix File Capabilities providing a segmented SUID
feature.  Applying the same Capabilities on a user by user base also
has equal advantages instead of having UID 0 or not UID 0.

Next important question why not look at segments to put forward
consensus.  This is something is not clearly being looked for.

100 percent consensus has never been true for every feature in Linux.

>On the contrary, security, done well, is a tight fitting suit. It must
>be tight, or it allows too much slack and attackers can exploit that.

I love that quote.  There is difference to tight fitting and covering
everything needed.  Ie tight fitting suit without pockets is going to
be a pain.

Main OS security features always made tight by the LSM.  Since they
are override able.

This can solve the stack problem to a point.   Of course not a perfect solution.

Chain passing threw LSM is not a solution.  Never will be.  A
applications on systems may require many different security models to
protect them.

Needing hooks everywhere with unlimited control provided at a single
interface does not look like a tight security model to me.  Makes LSM
look like the Ideal rootkit location.

LSM bundling hooks into security interfaces segments and reduces
threat.  Since each interface has rules and limitations.

Of course my ideas have not been fully documented out correct.   I am
not foolish my skills are not perfect.  The reason behind my ideas is
to get past the limitations of LSM.

The differences between LSMs get less different the closer you get to
the LSM interface.

Label vs path based is the biggest divide.   Including the config
system of modules makes merging hard.  Catch is Label and path based
both have there places.  Ie filesystem limitations(path based) and
speed(label based).  So both being side by side in the kernel I have
no issue with.  I really have to ask why selinux does not support path
based for the odd file systems that don't support labels and the
reverse with apparmor?  Is it that the developers have been building a
empire and not see the need for the others features so failing
completely to build the most powerful security framework.

Yes LSM is only a testing ground and for features that no everyone
wants.  ie Not everyone wants selinux apparmor... Models.  For things
like posix file capabilities its just a testing ground for features
before it moved into kernel full time.

LSM has two uses. Not one.

'one true security model' I am not talking about that with Multiadmin
main goal is a Security Feature it really does not make up a complete
model in its own right.  Different Admins with different capability's.
 Now the final form of Multiadmin who knows.  If we had file access
controls at the same level of control as posix file capabilities there
is a chance that Multiadmin core features could be done threw pam.
Lack of core features is forcing things into the LSM level that may
not need to be there.  Having users with permissions more limited to
filesystem would be useful.  There are small fragments of LSM that
have uses out side the LSM framework also what you are failing to
offer.

This is the problem with Multiadmin its existence is truly
questionable.   Why does it exist where it does.  Even why it exists
at all.  Same applies to apparmor.  Why does it exist should it exist
complete a LSM or should it be cut in two standard OS feature and a
LSM.   Apparmor style file control would be great at a application
level like posix file capabilities.

Note all the core features do make a security model in its own right.
 Wish to enhance that should be equal goal to making LSM's.  They key
thing to the core security model is flexibility.  So of course Linus
does not want to choose a new model he already had one.

Peter Dolding

PS This is most likely no what people want to hear.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Toshiharu Harada]

2007/10/31, Crispin Cowan <crispin@crispincowan.com>:
> Peter Dolding wrote:
> > Lets end the bitrot.  Start having bits go into the main OS security
> > features where they should be.
> >
> Linus categorically rejected this idea, several times, very clearly.
>
> He did so because the security community cannot agree on a
> one-true-standard for what that OS security feature set should be. From
> looking at this thread and many others, he is correct; there is no
> consensus on what the feature set should be.
>
> So you can wish for the "main OS security features" all you want, but it
> is not going to happen without a miraculous degree of consensus abruptly
> arising.
>
> On the contrary, security, done well, is a tight fitting suit. It must
> be tight, or it allows too much slack and attackers can exploit that. To
> make it tight, it must be tailored to the situation at hand. That means
> that there may *never* be a consensus on the "one true way", because it
> could be that there is no "one true way". It could be that SMACK is best
> in some cases, AppArmor in others, SELinux in others yet again, MLS in
> others, etc. etc.
>
> I agree with Casey; LSM may not be perfect, but it is a great deal more
> consensus than I have seen anywhere else in the security community. Your
> desire that AppArmor and SELinux should share code has already happened:
> LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and
> TOMOYO, and MultiADM, etc.

My main concern is whether we (different attempts) can share the code.
IOW whether we can reach and form the agreement for single security framework.
It is possible to write code if only we have a clear specifications, but
this is not the case.
I can easily think of LSM, or whatever we call,  as Greatest Common Factor,
but in that case LSM will explode soon and no single module can not be happy,
Linux security will not be achieved.

> It certainly can be improved, but it is not in need of wholesale
> replacement, and especially not without a clear design that addresses
> clearly stated problems that lots of people are having.

We should not invent wheels, that is agreed by everyone , but if we try to share
something that we can not share, we will fail. From the fact existing
LSM did not satisfy any module (including SELinux), I do not
want to investigate stack able version.

Cheers,
Toshiharu Harada

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

The Clear and Important thing is there is already a single security framework.

The single security framework is the security that exists when no LSM
is loaded.  It turns out the more I look most of my model already
exists just not being used effectively.  There is a capabilities frame
work at worse needs expanding to handling more detailed controls.
Like X thread can only read x y z files an write to a file.

Improvements to the single security framework are getting over looked.
  I would have personally though selinux would have done Posix file
capabilities as a general service to all.  But no IBM had to do it.
This shows a problem.  Critical upgrades to the single security
framework are not being made by LSM producers.  This means one thing
LSM producers are putting there framework before the good of everyone.
  This just cannot keep on going its a path to more and more forks and
more confusion.

Is it Linus getting in way I think not.   Because upgrades are making
it.  Slowly making it but they are making it.   Is it LSM makers
trying to alter the single security framework to there model.  I am
almost perfectly sure that is the main problem.  Next problem is LSM
vs LSM one up man ship ie mine is better than yours or Mine can do all
yours can with 12 times more complex config file.  Not taken a
complete look to see if both sides have advantages.

Part the problem is if you upgrade the single security framework
enough selinux apparmor... most of the LSM will become side shows of
very little importance to security more a s backup to the main
security.  Focus may move back to the old unix locations.  PAM for
creating users and assigning rights and application controlled
security.

Key thing to put  features into the existing single security framework
is flexibility and application control.  Application controlled
security can always beat selinux apparmor and every other LSM I have
ever seen.  The most advanced design of security just happens to the
one you cannot remove.   It also happens to be the most neglected.
The weaknesses that exist in the single security framework is lack of
advancement and repair.

What I class as features is like a fix to a small part.  Ie SUID too
powerful fine grained controls required.
Disk access control methods for file systems without using the
permission system. << Apparmor and relegated path base back end
engine. This also partly allows applications to protect there own
internal users from each other without needing to create system wide
users.  Basically in time internal application users should be equally
protected from each other as system wide users.  This enhancement goes
far past the common day scope of apparmor.  This is the advantage of
taking it out of LSM or at least looking to.  You may see where it can
be make 1000 times more useful as feature than a LSM and provide many
more times system protection even in ways a LSM never could.  Yes
altered apparmor could be really sell able as a core feature.

There are a lot of parts in LSMs that can be broken down into single
feature enhancements.  Major difference is how these features are
controlled.   Applications must be able to directly lower access on a
thread by thread base.  Never raise it.  These features are also
provided to all users on the system to control always even if they
cannot use them due to lack of rights.

Explain to me how its not bitrot leaving the key security framework
without features and then dividing up those features between different
incompatible parts.  This is the basic define of bitrot because you
are making a bigger and bigger mess.

Peter Dolding

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Peter Dolding <oiaohm@gmail.com> wrote:


> Improvements to the single security framework are getting over looked.

Please post proposed patches.

>   I would have personally though selinux would have done Posix file
> capabilities as a general service to all.

Posix capabilities predate SELinux. SELinux is not interested in
Posix capabilities. 

> But no IBM had to do it.

Err, no. It was done by Andrew Morgan back in the dark ages.
Why on earth do you think IBM did it?

> ...

OK, you have all the answers. Show us some code or STFU.


Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

On 11/1/07, Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> --- Peter Dolding <oiaohm@gmail.com> wrote:
>
>
> > Improvements to the single security framework are getting over looked.
>
> Please post proposed patches.
>
> >   I would have personally though selinux would have done Posix file
> > capabilities as a general service to all.
>
> Posix capabilities predate SELinux. SELinux is not interested in
> Posix capabilities.
>
> > But no IBM had to do it.
>
> Err, no. It was done by Andrew Morgan back in the dark ages.
> Why on earth do you think IBM did it?


Posix file capabilities the option to replace SUID bit with something
more security safe only handing out segments of root power instead of
the complete box and dice like SUID.  Even different on a user by user
base.

Posix capabilites is what Posix file capabilities is based on.  Yes I
know the words appear close.  The word file is important.  Please read
Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html

IBM coders worked and got it into the main line really recently to
provide at least some way to avoid fault of SUID of course it could
still be made better.  I would have though being a important problem
that other LSM guys would have done it first.  So door to add new
features to kernel is open past any question.  Of course the features
have to be for everyones good.

Andrew Morgan Posix capabilities is something far older its been there
for ages pre selinux the correct fix to SUID for everyone has always
been there by extending Andrew Morgan's work.  So I will ask again why
did IBM have to do Posix file capabilities instead of Selinux.
Selinux has had 7+ years to do it.

Thank you for proving my point past question Casey Schaufler.  You
don't have a single clue of the alterations happing to the main
security model so there is every chance you will overlap with it.

Please get you tech right.  How many other holes are sitting open
because you patch them at LSM level and don't look down into default
security system to see if it should be fixed there.

>
> OK, you have all the answers. Show us some code or STFU.

That is no explanation to why the default security frame work is being
neglected.  I don't have all the answers.  It does not take a person
that high so see that LSM is a screwup leading to people being out of
touch with the main security model and its neglect.  It should not be
requiring outside parties to fix things that in the main security
model.  Only way that can be happening is if LSM is dysfunctional.  7+
year fault at min is not what you can call someone fixing a new fault.
 Now how are we going to fix the mess of LSM's to work correctly for
the good of linux.

One way is appoint one hard minded maintainer that is above my rights.

This is above me doing code.   No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section.  Strict
policies on fixing the main security model will be required.

Peter Dolding

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Jan Engelhardt]

On Nov 1 2007 12:51, Peter Dolding wrote:
>
>This is above me doing code.   No matter how many fixes I do to the
>core that will not fix dysfunction in the LSM section.  Strict
>policies on fixing the main security model will be required.

If there is no one wanting to fix the existing code, then the
perceived problem is not a problem.

Or to put it another way:
"You talk the talk, but do you also walk the walk?"

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[David Newall]

Jan Engelhardt wrote:
> On Nov 1 2007 12:51, Peter Dolding wrote:
>   
>> This is above me doing code.   No matter how many fixes I do to the
>> core that will not fix dysfunction in the LSM section.  Strict
>> policies on fixing the main security model will be required.
>>     
>
> If there is no one wanting to fix the existing code, then the
> perceived problem is not a problem.

What an absurd claim.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Peter Dolding]

On 11/1/07, David Newall <david@davidnewall.com> wrote:
> Jan Engelhardt wrote:
> > On Nov 1 2007 12:51, Peter Dolding wrote:
> >
> >> This is above me doing code.   No matter how many fixes I do to the
> >> core that will not fix dysfunction in the LSM section.  Strict
> >> policies on fixing the main security model will be required.
> >>
> >
> > If there is no one wanting to fix the existing code, then the
> > perceived problem is not a problem.
>
> What an absurd claim.
>
I agree.  If they can provide a reason.  A correct reason why its not
being fixed then the perceived problem does not exist.  Until then it
common human flaw Tunnel vision.  People normally don't look at the
big picture.

Common fake reason is that Linus does not approve.   History of
patches completely disagrees with that.  Parts Linus has blocked have
been out of alignment with the build into kernel security model.  Yet
other parts that were in alignment with the model have got in during
the same time.  Perfect example of dysfunction making up a lie because
things will not go into kernel exactly how they want.

LSM is nothing more than a testing and model zone.   A place were
important features should not be.  It was put there because model
designs could not get along.   Did that mean that LSM was were the
features were intended to stay.  No the goal should be simple to get
as many good features into the main line as possible while staying in
alignment with the main kernels model.  I don't know where the wrong
idea that the main line did not have a security model came from
either.  Something does not have to be a LSM to be a security model.

XEN, KVM and lguest are not a suitable workaround to problem.  Its
more of LSM developers trying to say its not needed so don't have to
work with each other.  I am not always using x86 machines so at times
not one of those solutions fit.

Containers in Linux kernel get to be processor neutral in features.
So it will not matter what the processor chip it will work.  So the
correct solution to running many LSM somehow has to be done with
Containers.

Note calling me a know it all is not an answer either.   Either they
can put have a good explanation for there failing or the need asses
kicked.  Heck if I am wrong I need ass kick and perfectly prepared to
accept it.  The problem is I am not a person to accept invalid answers
what they have been giving me so far.

My main base is System Administration.  Not coding please note that
System Administrators are the final clients.  If you want someone with
System Administration back ground to take up the leadership of LSM and
bash it into a System Administrator friendly shape I am more than
prepared to do so.  I can bet a System Administrator in charge who is
looking from flexibility's and security point of view is going to get
noses really badly out of joint.  The flexibility bit is currently
missing.   Its not always possible to reboot a server just because the
security framework is not up to the job or client wants you to use a
tighter model.

Yes so people trying to lie to me is something I have very little
tolerance with.  Paperwork like PHD don't scare me off.  I have had to
repair networks destroyed by people with PHD with masters in computer
programming because they run a BIOS destroying virus from a outside
source.  So lets just say my trust has to be earned and using
incorrect facts don't get trust from me.

There is a bigger one than just Containers.  Its called linux on
desktop.   Some how security models will have to tolerate being
controlled from a central server.  Preferred 1 model so any number of
Linux Distros can be used in a network.  Just like different versions
of windows can now.  So somehow we have to get to one master model.
Even if the other models are just like feature tweaks.  Application
controlled allows pam and ldap into play.

Selinux jamed in does not really suit what is needed.  The world of
Linux is changing the LSM need to get there but into gear and catch
up.

Peter Dolding

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Andrew Morgan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Dolding wrote:
> On 11/1/07, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> --- Peter Dolding <oiaohm@gmail.com> wrote:
>> Posix capabilities predate SELinux. SELinux is not interested in
>> Posix capabilities.
>>
>>> But no IBM had to do it.
>> Err, no. It was done by Andrew Morgan back in the dark ages.
>> Why on earth do you think IBM did it?
> 
> Posix file capabilities the option to replace SUID bit with something
> more security safe only handing out segments of root power instead of
> the complete box and dice like SUID.  Even different on a user by user
> base.
> 
> Posix capabilites is what Posix file capabilities is based on.  Yes I
> know the words appear close.  The word file is important.  Please read
> Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html

For the record, I think you are both right. I took a stab at it back
when Casey and I first met:

ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.4-fcap/README

all that stuff worked fine it was just a bit ahead of its time...

- From memory, at that point in time "extended attributes" were an
external patch, and having some trouble getting merged. My sense was
that EA was a pre-requisite and I was happy to wait for that support to
become integrated before pushing my file capability support.

In the midst of all this LSM emerged as a reaction to Linus' clear
unhappiness about all extensions security. I didn't have the time to
participate in the LSM, and my work sat in the form of these patches.

SELinux at that time existed as a separate infrastructure, and evidently
did have the time to embrace LSM.

> IBM coders worked and got it into the main line really recently to
> provide at least some way to avoid fault of SUID of course it could

[...]

So, yes, IBM (Serge) deserve full credit for starting over, and getting
it merged...

Cheers

Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFHLr6EQheEq9QabfIRAsOrAJ9XzTL0Lqm5jaxwO6UoPB9Pwh3SzQCfVWFd
cPyjsGp/s6D6HuBE6M4NJH0=
=G/ah
-----END PGP SIGNATURE-----

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Serge E. Hallyn]

Quoting Andrew Morgan (morgan@kernel.org):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Peter Dolding wrote:
> > On 11/1/07, Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> --- Peter Dolding <oiaohm@gmail.com> wrote:
> >> Posix capabilities predate SELinux. SELinux is not interested in
> >> Posix capabilities.
> >>
> >>> But no IBM had to do it.
> >> Err, no. It was done by Andrew Morgan back in the dark ages.
> >> Why on earth do you think IBM did it?
> > 
> > Posix file capabilities the option to replace SUID bit with something
> > more security safe only handing out segments of root power instead of
> > the complete box and dice like SUID.  Even different on a user by user
> > base.
> > 
> > Posix capabilites is what Posix file capabilities is based on.  Yes I
> > know the words appear close.  The word file is important.  Please read
> > Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html
> 
> For the record, I think you are both right. I took a stab at it back
> when Casey and I first met:
> 
> ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.4-fcap/README
> 
> all that stuff worked fine it was just a bit ahead of its time...
> 
> - From memory, at that point in time "extended attributes" were an
> external patch, and having some trouble getting merged. My sense was
> that EA was a pre-requisite and I was happy to wait for that support to
> become integrated before pushing my file capability support.
> 
> In the midst of all this LSM emerged as a reaction to Linus' clear
> unhappiness about all extensions security. I didn't have the time to
> participate in the LSM, and my work sat in the form of these patches.
> 
> SELinux at that time existed as a separate infrastructure, and evidently
> did have the time to embrace LSM.
> 
> > IBM coders worked and got it into the main line really recently to
> > provide at least some way to avoid fault of SUID of course it could
> 
> [...]
> 
> So, yes, IBM (Serge) deserve full credit for starting over, and getting
> it merged...

There are still pieces to line up.  Note that Andrew Morgan is working
on a patch to make the securebits per-process to make capabilities
more useful as well as a 64-bit capability patch.  And the support in
tree to date would be riddled with gotchas without Andrew Morgan's,
Stephen Smalley's, and Casey Schaufler's input.

-serge

(But hey, thanks :)

Re: Defense in depth: LSM *modules*, not a static interface

[Crispin Cowan]

Simon Arlott wrote:
> On Tue, October 30, 2007 07:14, Cliffe wrote:
>   
>> And while I acknowledge that many of these layers are currently buried
>> within the kernel (netfilter...) they are security layers which in many
>> cases would probably make sense as stackable security modules.
>>
>> Making the interface static forces mammoth solutions which then must
>> attempt to solve all of the above in one ls*m*. What happened to
>> dividing tasks into easy to manage chunks?
>>     
> Would it be possible to have Kconfig select which LSM should handle each
> area of security? Selecting LSM A would automatically disable LSM B and
> C since they both implement the same security functions, while LSM D
> would still be selectable since it implements something else. The default
> capabilities code would then turn off parts of itself that another LSM
> is handling.
>   
I get what you mean, but the problem is that there is little consensus
on what "area" means. Rather the opposite, it could easily be the case
that different modules have such a different view of the world that you
cannot easily mechanically determine whether they can stack.

Some categories that occur to me:

    * Restrictive vs. Permissive:
          o LSM is mostly restrictive, but the POSIX.1e Capabilities
            hooks are permissive.
          o Some modules like MultiADM and File Capabilities are
            deliberately permissive, while others like AppArmor and
            SMACK are purely restrictive.
          o In any kind of stacking scheme, it would be important to
            load the permissive modules first, followed by the
            restrictive modules.
          o This becomes problematic as soon as you have a module that
            is both permissive and restrictive.
          o Note: AppArmor is both permissive and restrictive because it
            incorporates the Capabilities code rather than trying to
            stack with it. With a good clean stacker, AA might be able
            to become purely restrictive.
    * Access control vs. Intrusion prevention:
          o An Access control policy is one that specifies what a
            confined subject can access.
          o An Intrusion prevention engine specifies classes of things
            that may never happen, e.g. the Openwall hard and symbolic
            link restrictions.
          o An intrusion prevention mechanism might be a blanket effect
            that prevents the Bad Thing from happening for all
            processes, or it might be policy driven, and only prevent
            the Bad Thing for explicitly confined processes, or
            explicitly allow the Bad Thing for permitted processes.
          o Access control and Intrusion Prevention modules are
            naturally complementary, making stacking very attractive.
          o Note: SELinux already incorporates some intrusion prevention
            features, and AppArmor plans to incorporate such features.
            With a good clean stacker, AA might be able to instead use
            stacking.


> Alternatively the M in LSM can be restored and modules can be stacked.
> It should be possible for the primary LSM to check the security_ops of the
> secondary LSM(s) and complain if it considers there to be an incompatiblity.
>   
That is what I advocate. Restore the modular feature immediately, this
static interface is lots of cost (mostly opportunity cost) and very
little benefit (mostly defense against contrived FUD threats).

Crispin

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

Re: Defense in depth: LSM *modules*, not a static interface

[Cliffe]

Crispin Cowan wrote:
> Simon Arlott wrote:
>   
>> On Tue, October 30, 2007 07:14, Cliffe wrote:
>>   
>>     
>>> And while I acknowledge that many of these layers are currently buried
>>> within the kernel (netfilter...) they are security layers which in many
>>> cases would probably make sense as stackable security modules.
>>>
>>> Making the interface static forces mammoth solutions which then must
>>> attempt to solve all of the above in one ls*m*. What happened to
>>> dividing tasks into easy to manage chunks?
>>>       
...
>> Alternatively the M in LSM can be restored and modules can be stacked.
>> It should be possible for the primary LSM to check the security_ops of the
>> secondary LSM(s) and complain if it considers there to be an incompatiblity.
>>   
>>     
> That is what I advocate. Restore the modular feature immediately, this
> static interface is lots of cost (mostly opportunity cost) and very
> little benefit (mostly defense against contrived FUD threats).
>
> Crispin
>   

Security can (and should) be implemented in a layered approach. Not 
allowing stacking means that, rather than creating modules which 
complement each other, certain layers need to be migrated into the 
mainline kernel code. This would be ok if every situation had the same 
security requirements; however, they do not.

For example small LSMs that provide hooks for Malware scanners (like 
dazuko), certain security improvements (such as RaceGuard, PaX ...) and 
POSIX capabilities could be stacked with other larger lsms (traditional 
access control, IDS, firewalls) rather than copying these techniques 
into all the large lsms (such as SELinux and AppArmor) or putting them 
into the mainline kernel. Obviously it would be easier to maintain one 
capability lsm which stacks, than capabilities being implemented in 
every access control lsm.

It may be possible to compile stacked LSMs together (I don't know), but 
modules provide greater flexibility and either way stacking should be 
pursued.

I agree with Crispin, restore modules. Then discussions of suitable ways 
of providing stacking can occur / continue.

Cliffe wrote:
> Al Viro wrote:
>> On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
>>  
>>> Defense in depth has long been recognised as an important secure 
>>> design principle. Security is best achieved using a layered approach.
>>>     
>>  
>> "Layered approach" is not a magic incantation to excuse any bit of snake
>> oil.  Homeopathic remedies might not harm (pure water is pure water),
>> but that's not an excuse for quackery.  And frankly, most of the
>> "security improvement" crowd sound exactly like woo-peddlers.
>>   
>
> I agree completely; but layers that provide actual security 
> improvements are important. 

Just to clarify, I was agreeing with Al that layers for the sake of 
layers does not improve security if the layers are flawed. I was not 
implying that the specific LSMs that are being proposed currently 
(AppArmor etc) are flawed. I personally think that AppArmor provides 
security improvements which are particularly suitable in some situations.

However, if you do have defense in depth then a flaw in one layer may be 
compensated by another layer. For example if you have a system wide 
firewall that does not allow any incoming traffic to enter a system, and 
an AppArmor profile denies all network traffic to a specific 
application, then a flaw in the firewall which would ordinarily result 
in a compromise of the systems policy would not cause that specific 
application to be exposed. Granted this may be a poor example, but it 
does illustrate that layers provide security improvements. Of course 
this kind of setup does provide management and usability challenges but 
that is an area for improvement.

Anyway I hope that my opinion is helpful,

Cliffe.


-- 
Z. Cliffe Schreuders
BSc Comp Sci (Hons) & Int Comp
PhD Candidate, Casual Tutor
School of IT
Murdoch University

Re: Defense in depth: LSM *modules*, not a static interface

[Peter Dolding]

Lets on paper do what Crispin Cowan said to be a good stacker apparmor
become purely restrictive and modules like it.  This will explain were
stacking ends up dead meat.

Most people don't notice that the default system is there Posix
Capabilities.   So effectively just by changing apparmor you have now
double layered the code.   Effectively slower.

Stacking risks creating a longer and longer path to permit and refuse
a request.  Since modules cannot take advantage of system provided
parts.  Without dealing with that problem stacking is a speed problem
as well as a security one.

I know a strange question would the be a advantage in adding a set of
restrictive options to POSIX.1e Capabilities section.  Could this
reduce the overall amount of code making up LSM's.  Might cure the
depth problem of stacking most of the time.  Less traveling threw the
LSMs less problems on speed.. And reduce the numbers of hooks needed
by LSM's into kernel.

I agree with Crispin Cowan at moment some modules are not stackable.
But there is a large price to pay by making them stackable too.  With
modules that are permissive and restrictive I have never come up a
good solution in Crispin Cowan eyes.  Its the reason why I was
splitting the security into zones.  It was the only way I could come
up with to make sure they could not fight.  Give them each there own
limited domain of control with limited permissions on offer.

Depth of stacking is important from admin point of view.  Ok something
coders can simply forget.  Lets say I have a application not working
due to secuirty on a linux I have never used before.  Yes this happens
when you replace admins.   Stacked also risks giving me more configs
to look threw to find the file that is blocking.

Yes I agree with layering security.  But there comes a point were
complexly removes gain of layering.

"AppArmor profile denies all network traffic to a specific
application"  Ok why should AppArmor be required to do this.  Would it
not be better as as part of Capabilities that is always there and is
application controllable.  It would be a security advantage if data
processing threads that don't do network access inside a application
don't have it.  Basically this feature could be done in mirror.  Allow
Network access Capabilities flag.  Not set application cannot access
network at all.  All LSM's would be able to use that to cut of network
access to applications.  As a standard feature of kernel if a new
network stack or some other alteration is done LSM hooks would not
need altering.  Lot of LSM hooks would disappear.  Need for LSM to
monitor and run different code to kernel in a lot of places would also
disappear.

With Capabilities expand it to point that applications cannot do
anything without permissions.  Both models are do able.  Restrictive
can be done in a Permissive model effectively if the starting point of
the Permissive is that you cannot do anything without permissions
being granted.  Big different is that the Permissive Model is the
kernel default.  Some LSM are design in conflict with the main model
of the OS.  You really only want one model from speed point of view.

This is the main problem with LSM most are forcing self against grain
of the OS's design.  Needing lots of hooks into different places
should have been a big hint. You are ending up with 2 models where you
should have only one.  Ie permissive controlled can do a MAC just as
effectively as hooking everywhere in kernel.   To be correct is a lot
safer since applications would be able to drop there permissions as
needed.  LSM rootkit gets massive amounts of power at moment not by
breaking anything because everything is piped in its direction.  What
is the point of layers when there a layer that can do what ever it
sees fit.

Basically look at the main kernel design work with it don't fight with
it.   This will reduce code everyone needs.

Only effective way I can come up with of layering and not having one
layer grant something that another has taken away/change.  Is to
double up  posix capability and other security appling systems.  One
containing the final output and one to list was is still allowed to be
changed.   This is going to have a speed cost.  Thank god only the
final output needs to be entering kernel processing. Once something is
removed from being setable the next LSM along cannot change it and
should send a error message.   This still requires building a
completely common core security engine so that a LSM does not do a
feature outside so we don't have grant and forbid fights any more.

Only different to my container model is depth of travel.  This one
will be slower than Container model I was putting up before.

Note a engine to do security can be basically security module neutral.
 Yes at least we don't need to debate about if the engine should be
permissive or restrictive.  Since the engine already exists.
Permissive it is.  Fighting with existing design is wasting time.

Peter Dolding

Re: Defense in depth: LSM *modules*, not a static interface

[Casey Schaufler]

--- Cliffe <cliffe@ii.net> wrote:

> As good an idea POSIX capabilities might be,

Now that's a refreshing comment. Thank you.

> not all security problems 
> can be solved with a bitmap of on/off permissions.

There are people (I'm not one of them) who figure that you
can solve all the security problems by applying sufficiently
fine granularity of on/off permissions.

> Peter Dolding wrote:
> <lots o stuff>
> 
> Ok but what happens to the principle of least privilege?
> 
> What if we want AppArmor to confine that application to use a particular 
> set of ports?
> 
> Do you propose having a capability for each port? how about protocols?

While you're at it, how about a capability for each possible
directory entry name?

> So unless my understanding of capabilities is fundamentally flawed 
> (which it may be - I have not spent time reviewing recent changes) 
> obviously Linux capabilities does not provide a solution to every problem.

Of course they don't. The only problem they are intended
to solve, and I really mean this, is the association of uid 0
with privilege. That's it. You would be better off with a single
CAP_GODLIKE than with uid 0 having all privilege all the time.
Fine grained capabilities are a bonus, and there are lots of
people who think that it would be really nifty if there were a
separate capability for each "if" in the kernel. I personally
don't see need for more than about 20. That is a matter of taste.
DG/UX ended up with 330 and I say that's too many.



Casey Schaufler
casey@schaufler-ca.com

Re: Defense in depth: LSM *modules*, not a static interface

[Cliffe]

As good an idea POSIX capabilities might be, not all security problems 
can be solved with a bitmap of on/off permissions.

Peter Dolding wrote:
> "AppArmor profile denies all network traffic to a specific
> application"  Ok why should AppArmor be required to do this.  Would it
> not be better as as part of Capabilities that is always there and is
> application controllable.  It would be a security advantage if data
> processing threads that don't do network access inside a application
> don't have it.  Basically this feature could be done in mirror.  Allow
> Network access Capabilities flag.  Not set application cannot access
> network at all.  All LSM's would be able to use that to cut of network
> access to applications.  As a standard feature of kernel if a new
> network stack or some other alteration is done LSM hooks would not
> need altering.  Lot of LSM hooks would disappear.  Need for LSM to
> monitor and run different code to kernel in a lot of places would also
> disappear.
>
> With Capabilities expand it to point that applications cannot do
> anything without permissions.  Both models are do able.  Restrictive
> can be done in a Permissive model effectively if the starting point of
> the Permissive is that you cannot do anything without permissions
> being granted.  Big different is that the Permissive Model is the
> kernel default.  Some LSM are design in conflict with the main model
> of the OS.  You really only want one model from speed point of view

Ok but what happens to the principle of least privilege?

What if we want AppArmor to confine that application to use a particular 
set of ports?

Do you propose having a capability for each port? how about protocols?

So unless my understanding of capabilities is fundamentally flawed 
(which it may be - I have not spent time reviewing recent changes) 
obviously Linux capabilities does not provide a solution to every problem.

Regards,

Cliffe.

--

Z. Cliffe Schreuders
BSc Comp Sci (Hons) & Int Comp
PhD Candidate, Casual Tutor
School of IT
Murdoch University

Re: Defense in depth: LSM *modules*, not a static interface

[Tetsuo Handa]

Hello.

Casey Schaufler wrote:
> Fine grained capabilities are a bonus, and there are lots of
> people who think that it would be really nifty if there were a
> separate capability for each "if" in the kernel. I personally
> don't see need for more than about 20. That is a matter of taste.
> DG/UX ended up with 330 and I say that's too many.

TOMOYO Linux has own (non-POSIX) capability that can support 65536 capabilities
if there *were* a separate capability for each "if" in the kernel.
http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.1.x/tomoyo-lsm/patches/tomoyo-capability.diff?root=tomoyo&view=markup

The reason I don't use POSIX capability is that the maximum types are limited to
bitwidth of a variable (i.e. currently 32, or are we going to extend it to 64).
This leads to abuse of CAP_SYS_ADMIN capability.
In other words, it makes fine-grained privilege division impossible.

Since security_capable() cannot receive fine-grained values,
TOMOYO can't do fine-grained privilege division.

I wish if capability machanism has mapping layer like:

#define CAP_DIVIDED_FOO1 0
#define CAP_DIVIDED_FOO2 1
#define CAP_DIVIDED_FOO3 2
  ...
#define CAP_DIVIDED_BAR1 100
#define CAP_DIVIDED_BAR2 101
#define CAP_DIVIDED_BAR3 102

const int cap_divided_to_grouped(int cap_divided)
{
	static const int cap_mapping_array[] = {
		/* [divided index value] = POSIX compatible index value (i.e. 0-31) */
		[CAP_DIVIDED_FOO1] = 0,
		[CAP_DIVIDED_FOO2] = 0,
		[CAP_DIVIDED_FOO3] = 0,
		[CAP_DIVIDED_BAR1] = 1,
		[CAP_DIVIDED_BAR2] = 1,
		[CAP_DIVIDED_BAR3] = 1,
	};
	return cap_mapping_array[cap_divided];
}

int capable(int cap_divided)
{
	return security_capable(cap_divided);
}

int security_capable(int cap_divided)
{
	/* Allow LSM to decide based on fine-grained capability index. */
	return LSM_implementation_specific_capability_check(cap_divided_to_grouped(cap_divided));
}

int function_foo(void)
{
	if (!capable(CAP_DIVIDED_FOO1))
		return -EPERM;
	return 0;
}

int function_bar(void)
{
	if (!capable(CAP_DIVIDED_BAR2))
		return -EPERM;
	return 0;
}

Thanks.

Re: Defense in depth: LSM *modules*, not a static interface

[Peter Dolding]

On Nov 7, 2007 2:11 PM, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:
> Hello.
>
> Casey Schaufler wrote:
> > Fine grained capabilities are a bonus, and there are lots of
> > people who think that it would be really nifty if there were a
> > separate capability for each "if" in the kernel. I personally
> > don't see need for more than about 20. That is a matter of taste.
> > DG/UX ended up with 330 and I say that's too many.
>
> TOMOYO Linux has own (non-POSIX) capability that can support 65536 capabilities
> if there *were* a separate capability for each "if" in the kernel.
> http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.1.x/tomoyo-lsm/patches/tomoyo-capability.diff?root=tomoyo&view=markup
>
> The reason I don't use POSIX capability is that the maximum types are limited to
> bitwidth of a variable (i.e. currently 32, or are we going to extend it to 64).
> This leads to abuse of CAP_SYS_ADMIN capability.
> In other words, it makes fine-grained privilege division impossible.
>
> Since security_capable() cannot receive fine-grained values,
> TOMOYO can't do fine-grained privilege division.
>
Seen same problem.  Tetsuo Handa.

Capabilities alone does not.   Capabilities make up part of the engine.

As you can see currently it allows controls by block.  Now if
something has no network access at all does it have filtering rules no
it does not.  Same with file access.  There are some applications that
never need write or read from file systems.  So why are they granted
that.

These broad area covering controls can be provided to applications
without very much complexity.  Applications can use these features
internally to harden their security.  Make sections of program only
have read only file access other sections having read write other
sections have no file access.  Same with network access.  This is a
layer that is over looked and lacking power.

Capabilities do big blocks of security.  Bottom point of capabilities
should be a static application that loads into ram runs but cannot
report or allocate any memory.  Ie basically contained harmless and
useless.

The LSM takes control of permission allocation not enforcement in my
model.  The enforcement are done by sections like Capabilities and
Netlabels and some filesystem part that is missing.  Other parts might
be missing too.  Really need to be bashed out.   The Capabilities
could even tell you if those features are applied to your application.
 Now application can respond more correctly to user cannot access
directory because blocked by LSM/Application security settings not
just failed access.

Note Capabilities can provide a nice central point to give a basic
quick overview of what a application can and cannot do.  This
application does not have network access and is locked that way no
need to process Netlabels.  Same with filesystem.

330 is not too many if they exist for valid reasons.  20 appears to be
too few.  Most of the capabilities have be designed with the idea of
breaking up root powers.   This does not provide enough for
applications own internal security.

Its like currently you have a under 1024 port access switch and a Raw
network access switch.  Now there is no mirror switch for over 1024 so
all networking to application could be turned off.  Also applications
under 1024 then many not have the right to magically open up a back
door on higher user like ports.

On filesystem Read Write Execute and Change stat.   Memory allowed to
Allocate memory,  Memory map.    Device access limitations flags.
This is quickly list getting to 10 more at least needed.

Basically there are quite a few still missing in Capabilities that are
needed for application own security.  No permissions issued threw
Capabilities should equal application paper weight.   There are also
missing engine parts.   Netlabels is only one part.

Basically Capabilities flags as the hub.  With sections like Netlabels
and other security processing engines forking off it.  Sections like
Netlabels only need settings if Capabilities allows anything in the
first place.  This allows special engines for sections.  Yet not
having to allocate the memory when you don't need it.

Peter Dolding

Re: Defense in depth: LSM *modules*, not a static interface

[Casey Schaufler]

--- Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote:

> Hello.
> 
> Casey Schaufler wrote:
> > Fine grained capabilities are a bonus, and there are lots of
> > people who think that it would be really nifty if there were a
> > separate capability for each "if" in the kernel. I personally
> > don't see need for more than about 20. That is a matter of taste.
> > DG/UX ended up with 330 and I say that's too many.
> 
> TOMOYO Linux has own (non-POSIX) capability that can support 65536
> capabilities
> if there *were* a separate capability for each "if" in the kernel.
>
http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.1.x/tomoyo-lsm/patches/tomoyo-capability.diff?root=tomoyo&view=markup
> 
> The reason I don't use POSIX capability is that the maximum types are limited
> to
> bitwidth of a variable (i.e. currently 32, or are we going to extend it to
> 64).
> This leads to abuse of CAP_SYS_ADMIN capability.

That is a matter of taste. 

> In other words, it makes fine-grained privilege division impossible.

I personally believe that a finer granularity than about 20
is too fine. I understand that this is a minority opinion.


Casey Schaufler
casey@schaufler-ca.com

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[serge]

(finally starting to make headway through this thread over a month late)

Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> > To reject an LSM for providing "bad" security, IMHO you should have to
> > show how it is possible to subvert the self-stated goals of that LSM.
> > Complaints that the LSM fails to meet some goal outside of its stated
> > purpose is irrelevant. Conjecture that it probably can be violated
> > because of $contrivance is just so much FUD.
> 
> That seems to be an appropriate test.
> 
> > Exception: it is valid to say that the self-stated goal is too narrow to
> > be useful. But IMHO that bar of "too narrow" should be very, very low.
> > Defenses against specific modes of attack would be a fine thing to build
> > up in the library of LSMs, especially if we got a decent stacking module
> > so that they could be composed.
> 
> Once you have stacking then it actually at times will make sense to have
> security modules that do one very precise thing and do it well.

Hey - I thought it was the other way around?  :)

-serge