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
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
--- Rob Meijer <[email protected]> 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
[email protected]
On 10/30/07, Crispin Cowan <[email protected]> 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
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
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.
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
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
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
--- Crispin Cowan <[email protected]> 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
[email protected]
(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 <[email protected]> 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?
--- Jan Engelhardt <[email protected]> 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 <[email protected]> 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
[email protected]
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?
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
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
On 10/31/07, [email protected] <[email protected]> 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
--- Peter Dolding <[email protected]> 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
[email protected]
On Wed, 31 Oct 2007, Peter Dolding wrote:
> On 10/31/07, [email protected] <[email protected]> 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
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
On 10/31/07, Crispin Cowan <[email protected]> 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.
2007/10/31, Crispin Cowan <[email protected]>:
> 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
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
--- Peter Dolding <[email protected]> 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
[email protected]
On 11/1/07, Casey Schaufler <[email protected]> wrote:
>
> --- Peter Dolding <[email protected]> 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
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?"
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.
On 11/1/07, David Newall <[email protected]> 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter Dolding wrote:
> On 11/1/07, Casey Schaufler <[email protected]> wrote:
>> --- Peter Dolding <[email protected]> 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-----
Quoting Andrew Morgan ([email protected]):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Peter Dolding wrote:
> > On 11/1/07, Casey Schaufler <[email protected]> wrote:
> >> --- Peter Dolding <[email protected]> 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 :)
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
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
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
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
--- Cliffe <[email protected]> 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
[email protected]
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.
On Nov 7, 2007 2:11 PM, Tetsuo Handa <[email protected]> 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
--- Tetsuo Handa <[email protected]> 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
[email protected]