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

-