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

[Crispin Cowan]

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

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

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

Crispin

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

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

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

[Toshiharu Harada]

On 10/25/2007 10:42 AM, Casey Schaufler wrote:

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


Casey,

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

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

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

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

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

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

Cheers (and with love to Linux),
Toshiharu Harada

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

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

[Cliffe]

Al Viro wrote:

On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
  
Defense in depth has long been recognised as an important secure design 
principle. Security is best achieved using a layered approach.

 
"Layered approach" is not a magic incantation to excuse any bit of snake

oil.  Homeopathic remedies might not harm (pure water is pure water),
but that's not an excuse for quackery.  And frankly, most of the
"security improvement" crowd sound exactly like woo-peddlers.
  


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


--

Z. Cliffe Schreuders
BSc Comp Sci (Hons) & Int Comp
PhD Candidate, Casual Tutor
School of IT
Murdoch University
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Al Viro]

On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
> Defense in depth has long been recognised as an important secure design 
> principle. Security is best achieved using a layered approach.
 
"Layered approach" is not a magic incantation to excuse any bit of snake
oil.  Homeopathic remedies might not harm (pure water is pure water),
but that's not an excuse for quackery.  And frankly, most of the
"security improvement" crowd sound exactly like woo-peddlers.
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Cliffe]

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


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

Standard DAC (where users are in control of permissions)
Some form of user-based non-DAC (where admins can specify what users can 
specifically do) such as SELinux or SMACK

System-wide firewall (netfilter)
Some form of sandboxes/namespace isolation (chroot, jails...)
General application confinement such as DTE (SELinux), or Capability 
lists (AppArmor, systrace ...)
Application network confinement - firewall to confine individual apps 
(maybe included in the above)

IDS or IPS
Malware scanner
Posix Capabilities
Pax/RaceGuard
...[insert innovation here]...

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


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


Regards,

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

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

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

[Peter Dolding]

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

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

Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Kazuki Omo(Company)]

Dear, Folks,

Now we are planning to submit LIDS to mainline.
(As you know, it already written for supporing LSM for several years.)

When we will finish to re-write documentation and some FAQ, then
we will be able to submit the patch.

Sincerely,

OMO

Serge E. Hallyn wrote: (2007/10/09 03:00):

Quoting Eric W. Biederman ([EMAIL PROTECTED]):

"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
Also I'm thinking towards what do we have to do isolate the security
module stuff in the context of a namespace.  So that a person in
a container can setup their own rules that further restrict the
system.


In the selinux example I plan to do set up soon, that will be done
using the '.' namespace separator.

Every object/subject in vserver1 will have a type 'vserver1.whatever'.
'vserver1.root_t', 'vserver1.etc_t', etc.

I don't know how far the policy tools have gotten, but they are
*supposed* to implement constraints at policy compile time such that
every type which is a child of 'vserver1' would have no more access than
what is granted to type 'vserver1'.  So this provides a pretty nice
conceptual way to set up security for a vserver.

Then using the userspace policy server and metapolicy (this would be a
step or two beyond my first example) the policy could define rules about
what sort of policy could be added by a process of type
'vserver1.root_t'.  So we can allow the container admin to introduce
policy changes affecting only his own container, and subject to all
constraints placed by the host admin on vserver1.


So far I'm not ready to do anything yet but I'm keeping a weather eye
on the situation so I have a clue what I'm go.


If 1, an selinux policy should cover you.  So you can then skip to 3.
Or, alternatively, I do plan - as soon as my free time clears up a bit -
on demonstrating how to write some selinux policy to create a secure
container based on current -mm + your experimental network namespace
patches.

Thanks that sounds interesting.


If 3, then selinux policy modules may actually help you, else either
a new LSM (maybe like LIDS) or a userspace tool which is a front-end to
selinux policy, emulating the iptables rules formats, may be what you
want?

I don't want to have to choose my LSM at compile time.  I want to
add support into the kernel at compile time and be able to configure
it before I go multi-user.  I know this kind of architecture is
achievable because iptables allows it.

When I conceive as the security modules as just a firewall between
applications on my own box I think, oh yeah this is no big deal,
I might want to limit something that way some time.  These are just
some additional rules on when to return -EPERM.  So I ask myself why
is this situation much less flexible and much harder to use then our
network firewall code?


It actually used to be far more flexible than it is now.  The consensus
appears to be that it's just too hard - at times impossible - to
properly label every object or subject at some point after they've all
been created (processes created, inodes read from disk, etc).  Two
examples:

1. you've got pid 777.  How was it created?  Can you trust it's
history?  In my DTE module I solved this by keeping track of the
*full* invocation history until a policy was loaded.  I think
tomoyo may do something similar.  But it's really not
sufficient, especially since you don't even want a LSM loaded
at all.  So you can't reduce it to 'boot_t executd init_t
executed login_t executed shell_t', you have to keep track of
every inode executed

2. how do you reliably re-evaluate, for some file, what label
to assign to it?  Do you guess at a pathname?  Do you trust that
the inodes have been pre-labeled for every LSM, so when you load
the LSM you can grab the xattrs?

So it's a valid question - do we address these sorts of concerns in
order to add flexibility, or do we keep things as simple as possible
and say that it's up to the distro, for instance, or a site local
security administrator, to define policy, so that flexibility really
is of very limited use?


My impression is that selinux is one monolithic blob that doesn't
allow me to incrementally add matching or action features that I
find interesting.

Actually with policy modules it gets much much better.  I have in fact
been able to pretty easily write a short policy module to, say, create
an selinux user which ran as root and had full access to the system to
do system setup for automated testing.  There is a learning curve in
having to look at existing modules for maybe a few days to get started,
but once you get started the policy modules do make it very easy to
add to current policy.

Ok. Interesting.  Are these kernel modules?


Policy modules, loaded through selinuxfs at any time using 'semodule'.


Still while I get the general impression that selinux seems to be
very close to a generic solution, and that selinux more or less has

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

[Toshiharu Harada]

On 10/25/2007 9:41 AM, Chris Wright wrote:

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


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


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

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

Regards,
Toshiharu Harada

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

Re: Out-of-tree modules [was: Linux Security *Module* Framework]

[Jan Engelhardt]

On Oct 29 2007 20:46, Lee Revell wrote:
>On 10/29/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
>>
>> Provides a /dev/dsp style node for legacy applications that support
>> neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
>>
>
>(I think that should read "AND more than 2 channel sound")

It is for programs that only give out 2 channels of audio data.
Qdsp_dpl2 is a node that applies the DPL2 matrix on these two channels,
yielding the rear 2 channels, giving some sort of surround effect.

>Couldn't ALSA's OSS emulation be extended to support more than 2
>channels per device node?

I figured that exceeded my skills at that time.

>> thkd - 
>> ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff
>>
>> Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after
>> 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )
>
>It looks like this could be trivially fixed in a mergeable way.  That
>LKML thread petered out before the problem was seriously analyzed.
>
>Did you try the -Z flag of hdparm?

IIRC, yes, been through all sorts of hdparm options. -Z did not help
at all, and -B only prolonged the delay from 5 to around 15 seconds.
I contacted Tosh Corp (before posting on lkml) and while they know of
the 'issue', I did not get a satisfactory answer (namely how to FIX
it), so I thought why spend time slapping if there's a workaround...

Causing a minimal head seek every now and then (4096 bytes per 3
seconds is a somewhat small block size with a not-too-low interval)
is a working workaround for now. The module code is not top notch,
but I doubt I'll ever have more than one 1.8" MK2003GAH disk in the
same laptop.
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Out-of-tree modules [was: Linux Security *Module* Framework]

[Lee Revell]

On 10/29/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
>
> Provides a /dev/dsp style node for legacy applications that support
> neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
>

(I think that should read "AND more than 2 channel sound")

Couldn't ALSA's OSS emulation be extended to support more than 2
channels per device node?

>
> thkd - 
> ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff
>
> Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after
> 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )

It looks like this could be trivially fixed in a mergeable way.  That
LKML thread petered out before the problem was seriously analyzed.

Did you try the -Z flag of hdparm?

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

Re: eradicating out of tree modules

[Tilman Schmidt]

Am 28.10.2007 20:25 schrieb Adrian Bunk:
> On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote:
>> Am 28.10.2007 02:55 schrieb Adrian Bunk:
>>> Justifying anything with code with not GPL compatible licences has zero 
>>> relevance here.
>>>
>>> And there's value in making life harder for such modules with 
>>> questionable legality. As an example, consider people who experienced 
>>> crashes of "the Linux kernel" caused by some binary-only driver.
>>> Not that uncommon e.g. with some graphics drivers.
>>> This harms the reputation of Linux as being stable.
>> You are mixing up several distinct categories here: "out of tree"
>> != "non-GPL" != "proprietary" != "of questionable legality" !=
>> "binary-only" != "causing kernel crashes".
> 
> "binary-only non-GPL out-of-tree module causes kernel crashes" is a 
> quite common pattern for some popular binary-only modules.

Common, yes. Popular, maybe. The only one, not. Taking that as reason
for breaking out-of-tree open source modules is throwing out the baby
with the bathwater.

>>> The solution is not to support proprietary drivers, the solution is to 
>>> get open source replacements.
>> So how do you propose to "get" those replacements? And what shall
>> users do during the time this "getting" may take?
> 
> They should swamp the hardware vendors with requests for releasing 
> hardware specifications.

They are doing that already. But somehow it fails to magically cause
open source drivers to spring into existence immediately. The crucial
word here is *time*.

> Or even better buy their hardware from a competitor.

Hmmm. "Your existing hardware isn't supported anymore, buy new one?"
I thought that was a Microsoft line. (SCNR)

>>> If it's low quality code doing something useful - well, how many hundred 
>>> people are on Greg's list only waiting for some driver they could write?
>> No idea. Obviously not enough to actually solve the problem.
> 
> Greg has just begins with getting this started.

Exactly. Again, the problem is time. Deliberately breaking external
modules now and promising an in-tree alternative for later leaves
users out in the cold. That won't do much to improve the reputation
of Linux.

>> What solution do you propose?
> 
> You list the drivers you currently have in mind at the Linux Driver 
> Project [1].

They are all there already.

> Noone proposed to make the existance of out-of-tree modules completely 
> impossible - but it is a fact that derives directly from the Linux 
> kernel development model that thre's no stable API for out-of-tree 
> modules, and therefore each new kernel breaks many of them.

Granted.

> Once you accept this fundamental fact there's not much point in arguing 
> that changes that break out-of-tree modules should be fewer.

Granted. But that's not the point I was arguing anyway.

There is still a point in arguing that breaking out-of-tree modules
is not a goal. It's acceptable collateral damage if there is a good
reason for a change, but it doesn't by and in itself constitute such
a reason. That's why I'm taking exception with your statement in
<[EMAIL PROTECTED]>:
> [...] even though it might sound harsh breaking 
> external modules and thereby making people aware that their code should 
> get into the kernel is IMHO a positive point.

Breaking external modules is *not* positive. It's acceptable, but
everything else being equal it's still better to avoid it.

>>> Let me repeat that Greg has said he has hundreds of volunteers for such 
>>> tasks.
>> Even with hundreds of volunteers, your proposed solution of just
>> rewriting *all* external code in a way fit for inclusion into the
>> kernel is an unachievable goal. Just look at the list on
>> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>> and try to answer why each of them is still out of tree.
>> Hint: In most cases it's neither out of malice nor stupidity on
>> the authors' part.
> 
> There are different problems why different drivers are not (yet) 
> included in the kernel, but which ones don't have any possible solution?

I'm convinced all of them have possible solutions. The challenge
is to turn a possible solution into an actual one. And again, the
problem is time.

> And if you compare the numbers you'll see that Greg has on average a 
> handful of volunteers for one driver.

Not every problem can be solved faster by throwing more people at
it. Take mISDN as an example. Its developers have stated the goal
of inclusion in the main kernel tree years ago and it's still not
there. Deliberately breaking this external module "to make people
aware that their code should get into the kernel" would only delay
this goal even more. But sending them a handful of new volunteers
now would probably constitute the proverbial "adding manpower to a
late project".

> The most important question is still:
> 
> Why should there always be out-of-tree code that fills a real need not 
> satisfied by any in-tree code?

Because every in-tree code

Out-of-tree modules [was: Linux Security *Module* Framework]

[Jan Engelhardt]

On Oct 25 2007 19:56, Greg KH wrote:

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


quad_dsp - http://jengelh.hopto.org/p/quad_dsp/

Provides a /dev/dsp style node for legacy applications that support 
neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.


thkd - 
ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff

Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after 
5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Casey Schaufler]

--- 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]
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Crispin Cowan]

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

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

It also begs the question of what constitutes a family.

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

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

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

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

[Rob Meijer]

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

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

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

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

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

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

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


Rob

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

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

[Peter Dolding]

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

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

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

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

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

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

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

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

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

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

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


Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Crispin Cowan]

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

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

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

Crispin

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

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

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

[Rob Meijer]

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

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

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

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

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

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



Rob

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