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

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

-

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
-

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

-

I see it a little bit different one LSM maintainer for the lot of

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

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
Both is a valid answer.   Sections done path based should be shared
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
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
...
[ message continues ]

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


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 Multiad...
[ message continues ]

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
-

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

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
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 testi...
[ message continues ]

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

-

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,

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
-

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 a...
[ message continues ]

Posix capabilities predate SELinux. SELinux is not interested in

Err, no. It was done by Andrew Morgan back in the dark ages.

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


Casey Schaufler
casey@schaufler-ca.com
-

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

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
...
[ message continues ]

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


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

[...]

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

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 :)
-

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?"
-

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 Adm...
[ message continues ]

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.


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 L...
[ message continues ]

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, 


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 

as things are currently written, it's not possible to stack, so there is 

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 

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 
believ...
[ message continues ]

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
-

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

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

-

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
-

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 i...
[ message continues ]

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.


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 im...
[ message continues ]

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...
[ message continues ]

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


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
-

There are people (I'm not one of them) who figure that you
can solve all the security problems by applying sufficiently

While you're at it, how about a capability for each possible

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
-

Hello.


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

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

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
-

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...
[ message continues ]

"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

-

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
-

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
-