RE: [BK PATCH] LSM changes for 2.5.59

RE: [BK PATCH] LSM changes for 2.5.59

[Makan Pourzandi (LMC)]

> > > I'm very serious about submitting a patch to Linus to 
> remove all hooks not
> > > used by any intree module once 2.6.0-test.
> > 
> > Any idea on how much time that gives us (to rework SELinux 
> and submit
> > it)?
> 

Hi, 

My comments are from user of LSM point of view and not one of its designers. Actually, we have been using LSM for now about a year to develop our own security module in DSI project (security for clustered server, http://sourceforge.net/projects/disec). 

I believe that one major advantage of LSM is that it avoids the one size fits all approach. LSM allows to different people to come up with different mechanisms to implement security according to their needs. 
And different Linux users have different needs. For example in DSI project, we used LSM to implement our own security approach for clustered servers. For example, having tight restrictions on response time, we rather concentrate on performance impact of security and distributed access control inside a cluster than file access control (running mainly diskless machines). 
I believe this is very acceptable, because it allows the user to choose the security module that fits best its needs. The security needs are not the same for military/banking/telecom/gaming/... businesses. And till the moment that we have a config tool (file or else) that can allow these people to configure fine grained access control according to their needs (for example like how we configure iptables), I believe that LSM is necessary to give these people a chance of developing their own solution. 


Further more, I believe that LSM encourages the developers in the community to take initiatives related to security in Linux. This way, it helps developing different security approaches. This at the end, even if we choose to go with only one approach and drop others,  will help the diversity of existing solutions and the possibility of choosing among a set of solutions (hopefully the best one will be chosen). IMHO, to let people be able to come up with different security approaches, we have
to let LSM be part of the kernel in order to encourage people to
develop their approach.

That was my 2 cents. 

Regards, 
Makan Pourzandi 
-------------------------------------------------------
Makan Pourzandi            
Ericsson Research Canada
http://sourceforge.net/projects/disec/      
-------------------------------------------------------         

This email does not represent or express the opinions of Ericsson
Corporation.

Re: [BK PATCH] LSM changes for 2.5.59

['Christoph Hellwig']

do you have any technical argument on the current implementation of
security hooks?  the whole discussion is on removing the current mess
until a proper design can be implemented.

Re: [BK PATCH] LSM changes for 2.5.59

[magniett]

"Makan Pourzandi (LMC)" a écrit :

> > > > I'm very serious about submitting a patch to Linus to
> > remove all hooks not
> > > > used by any intree module once 2.6.0-test.
> > >
> > > Any idea on how much time that gives us (to rework SELinux
> > and submit
> > > it)?
> >
>
> Further more, I believe that LSM encourages the developers in the community to take initiatives related to security in Linux. This way, it helps developing different security approaches. This at the end, even if we choose to go with only one approach and drop others,  will help the diversity of existing solutions and the possibility of choosing among a set of solutions (hopefully the best one will be chosen). IMHO, to let people be able to come up with different security approaches, we have
> to let LSM be part of the kernel in order to encourage people to
> develop their approach.
>
> That was my 2 cents.
>
> Regards,
> Makan Pourzandi

Hi,
I'm the leader of a project, developping a sandbox (processes confinement environment) for Linux based on LSM.
Our approach is dedicated for peer-to-peer global computing environments. I totally agree with Makan about the
diversity of developpement : we dont have the same goals than SELinux. The LSM project followed two phases :
in a first one, everybody was thinking about what could be good to integrate in LSM and now (the second phase),
a few people think about what they can remove because they dont use it. We need a flexible and reasonably complete
framework to implement solutions. I recall that it was the original request from Linus : a generic framework to decide
which kind of security solutions are the best. If LSM fits only one or two policy requirements, the choice does not
exist. For finishing : PLEASE, stop reducing LSM possibilities : it cost a lot to develop things for a hook and then
redevelopping it for a classical syscall interposition.
bests
Frédéric Magniette (University of Orsay/CNRS)

Re: [BK PATCH] LSM changes for 2.5.59

['Christoph Hellwig']

[argg, any chance you two could get RFC-complaint mailers?]

On Wed, Feb 12, 2003 at 07:11:09PM +0000, magniett wrote:
> exist. For finishing : PLEASE, stop reducing LSM possibilities : it cost a lot to develop things for a hook and then
> redevelopping it for a classical syscall interposition.

There's no one taking away the LSM patches.  Anyway life would be a lot
simpler if you actually announced the stuff you do on lkml instead of hiding
behind the moon.  The only chance hook you need will stay is that you
discuss them publically here.

Where's the pointer to your code?

Re: [BK PATCH] LSM changes for 2.5.59

[Crispin Cowan]

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

'Christoph Hellwig' wrote:

>[argg, any chance you two could get RFC-complaint mailers?]
>
>On Wed, Feb 12, 2003 at 07:11:09PM +0000, magniett wrote:
>  
>
>>exist. For finishing : PLEASE, stop reducing LSM possibilities : it cost a lot to develop things for a hook and then
>>redevelopping it for a classical syscall interposition.
>>    
>>
>There's no one taking away the LSM patches.  Anyway life would be a lot
>simpler if you actually announced the stuff you do on lkml instead of hiding
>behind the moon.  The only chance hook you need will stay is that you
>discuss them publically here.
>
For the second time in a week, I agree with HCH: If you are developing 
an LSM module, then by all means please make it publicly known. Whether 
we host your source or not, we want to at least link to your site from 
http://lsm.immunix.org/lsm_modules.html

WRT "taking away LSM patches": HCH wants to remove hooks that "no one 
uses" and also complains about LSM being a big ugly undesigned hack 
lacking abstraction. LSM does have an abstract design: it mediates 
access to major internal kernel objects (processes, inodes, etc.) by 
user-space processes, throwing access requests out to the LSM module. If 
you remove some of these hooks because they don't have a *present* 
module using them, then you break the abstraction.

People tell me that preserving functionality for the sake of abstraction 
is "not the Linux way". Ok, sure, but you degrade the quality of 
abstraction if you aggressively prune the interface.

But it would be much better to short-circuit that debate, and have 
extant modules that use the hooks than to try to defend them on the 
basis of abstraction. So if your sekrit module uses a hook, post here, 
or your hook may go away.

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX                      http://wirex.com/~crispin/
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
			    Just say ".Nyet"


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59

['Christoph Hellwig']

On Wed, Feb 12, 2003 at 02:22:34PM -0800, Crispin Cowan wrote:
> WRT "taking away LSM patches": HCH wants to remove hooks that "no one 
> uses" and also complains about LSM being a big ugly undesigned hack 
> lacking abstraction.

> LSM does have an abstract design: it mediates 
> access to major internal kernel objects (processes, inodes, etc.) by 
> user-space processes, throwing access requests out to the LSM module.

We seem to use the term design differently.  And maybe my english
wording wasn't perfect (I'm no native speaker..).  My objection is that
LSM by itself does not enforce the tightest bit of security policy
design.  Your "design" is putting in hooks before object accesses
without making them tied to enforcing some security policy.

Now I hear people scream "but we want $BIGNUM totally different security
policies", but that;'s not what I want to take away.  Look at the Linux
VFS, it enforces quite a lot of stuff, and still we have tons of entirely
different filesystems.  Of course that could also have worked by putting
a function vector directly below the syscall level, similar to say the SVR3
filesystem switch.  But that means a) we duplicate tons of code because
filesystems are filesystem and there's stuff they will have to duplicate
anyway.  and b) there's stuff we just can't handle that way properly.
(see the cross-directory rename issue still present in most non-linux
unices).

Now getting a LSM-replacement in place that is as well-designed,
feature-rich and still rather slick as the Linux VFS won't happen
over night.  But if you see how we got that code is that we had
example filesystems that showed would should go into common code.

That's one of the reason why I think merging LSM-like hooks without
examples (three or four general purpose policies best) doesn't make
much sense.  We need to see what we can abstract out and how.

And here we see _the_ problem with the LSM process.  LSM wasn't
developed as part of the broad kernel community (lkml) but on
a rather small, almost private list.  People added hooks not because
they generally make sense but because their module needed it.
When reading this thread some people (e.g. David [*]) still seem that
changes should be done for LSM's sake - but that's entirely wrong.
The point of getting LSM or something similar in is for the sake
of the _linux_ _kernel_ getting usefull features, not for enabling
some small community writing out of tree modules.

> If 
> you remove some of these hooks because they don't have a *present* 
> module using them, then you break the abstraction.

An abstraction that isn't used is worthless.

	Christoph

[*] and btw, question in mails sent to a list I'm not subscribed to in
    reply to mails from me won't get answered, sorry.

Re: What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59

[Jesse Pollard]

On Wednesday 12 February 2003 05:05 pm, 'Christoph Hellwig' wrote:
> On Wed, Feb 12, 2003 at 02:22:34PM -0800, Crispin Cowan wrote:
> > WRT "taking away LSM patches": HCH wants to remove hooks that "no one
> > uses" and also complains about LSM being a big ugly undesigned hack
> > lacking abstraction.
> >
> > LSM does have an abstract design: it mediates
> > access to major internal kernel objects (processes, inodes, etc.) by
> > user-space processes, throwing access requests out to the LSM module.
>
> We seem to use the term design differently.  And maybe my english
> wording wasn't perfect (I'm no native speaker..).  My objection is that
> LSM by itself does not enforce the tightest bit of security policy
> design.  Your "design" is putting in hooks before object accesses
> without making them tied to enforcing some security policy.
>
> Now I hear people scream "but we want $BIGNUM totally different security
> policies", but that;'s not what I want to take away.  Look at the Linux
> VFS, it enforces quite a lot of stuff, and still we have tons of entirely
> different filesystems.  Of course that could also have worked by putting
> a function vector directly below the syscall level, similar to say the SVR3
> filesystem switch.  But that means a) we duplicate tons of code because
> filesystems are filesystem and there's stuff they will have to duplicate
> anyway.  and b) there's stuff we just can't handle that way properly.
> (see the cross-directory rename issue still present in most non-linux
> unices).
>
> Now getting a LSM-replacement in place that is as well-designed,
> feature-rich and still rather slick as the Linux VFS won't happen
> over night.  But if you see how we got that code is that we had
> example filesystems that showed would should go into common code.

Actually - one of the requirements was to be able to REMOVE all hooks to
create a system with NO added overhead. The VFS does add overhead, but the 
flexibility dictated that it be accepted.

> That's one of the reason why I think merging LSM-like hooks without
> examples (three or four general purpose policies best) doesn't make
> much sense.  We need to see what we can abstract out and how.
>
> And here we see _the_ problem with the LSM process.  LSM wasn't
> developed as part of the broad kernel community (lkml) but on
> a rather small, almost private list.  People added hooks not because
> they generally make sense but because their module needed it.
> When reading this thread some people (e.g. David [*]) still seem that
> changes should be done for LSM's sake - but that's entirely wrong.
> The point of getting LSM or something similar in is for the sake
> of the _linux_ _kernel_ getting usefull features, not for enabling
> some small community writing out of tree modules.

That wasn't true either - as I recall, the group that started working on LSM
was strongly suggested to take it off the list until "show me the code" could
be done.

> > If
> > you remove some of these hooks because they don't have a *present*
> > module using them, then you break the abstraction.
>
> An abstraction that isn't used is worthless.

Ummmm. Not all of the SCSI options are used either. Does that make the SCSI 
layer worthless?

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59

[James Morris]

On Wed, 12 Feb 2003, 'Christoph Hellwig' wrote:

> And here we see _the_ problem with the LSM process.  LSM wasn't
> developed as part of the broad kernel community (lkml) but on
> a rather small, almost private list.

Many of the things that you are saying in this discussion are untrue.

The bulk of the development process was carried out for more than two
years on the LSM development mailing list, which is fully public and open
to anyone.  It is not "almost private", whatever that is supposed to mean.

Should those thousands of emails have ended up on lkml instead?  Before
you answer, try reading the first thousand (which I actually did when 
joining the project).

As for "rather small", hundreds of people were involved in discussion
during the initial development phase (Chris Wright generated some stats on
this last year).  These people included numerous long time kernel
developers, commercial developers, well known security researchers and 
anyone else who was interested enough to join.

There were specific LSM discussions at two kernel summits, while multiple
OLS presentations have been given on LSM.  These events were further
covered by numerous online media sites.  LSM information was posted
several times to lkml, before and after the initial codebase was
developed.  If you didn't notice any of these things before you started
complaining recently, please don't blame the LSM developers.

I do agree that we should have worked more closely with maintainers from
the beginning, but this was not out of trying to be secretive (of which we
have been accused quite a few times).  This happened out of believing that
we should reach a design consensus and write some code via the before
bothering any maintainers.  This approach was clearly flawed, and efforts
have since been made to rectify this for ongoing development.

(Note that this process occured publicly on the LSM development mailing
list, and that code was checked in as it was developed to publicly 
accessible bk repositories).

And I also agree that it would have been better if more people in general
discussed LSM on lkml.  For whatever reason, they did not.  I can point
you to many instances of LSM posts being made to lkml with zero response.  

The first LSM patch sent to lkml was actually applied by Linus with no
discussion from anyone else, _very_ much to our surprise.  We definitely
expected significant discussion from lkml subscribers and a highly
probable subsequent phase of rework before it would be accepted into
mainline.


> People added hooks not because they generally make sense but because
> their module needed it.

SELinux was used as a model for LSM because SELinux is _itself_ a
generalized access control framework (arising from over a decade of
research).  SELinux already supported MAC, TE, RBAC, IBAC and MLS, and was
one of the few existing Linux security projects with significant coverage
across the kernel.  Thus, it was an ideal basis for use as a model for the
initial design of the LSM hook placement and abstraction strategy.  Many
other projects were used as models as well.  In fact, I reviewed in detail
_every_ single Linux security project I could find when implementing the
networking hooks.

Claims of a "secret" and non-generalized design process are baseless.


- James
-- 
James Morris
<jmorris@intercode.com.au>

Re: What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59

[Crispin Cowan]

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

James Morris wrote:

>On Wed, 12 Feb 2003, 'Christoph Hellwig' wrote:
>
>>And here we see _the_ problem with the LSM process.  LSM wasn't
>>developed as part of the broad kernel community (lkml) but on
>>a rather small, almost private list.
>>    
>>
>Many of the things that you are saying in this discussion are untrue.
>
>The bulk of the development process was carried out for more than two
>years on the LSM development mailing list, which is fully public and open
>to anyone.  It is not "almost private", whatever that is supposed to mean.
>
For the record:

    * The LSM code patches have always been publicly available for
      anonymous checkout via BK from http://lsm.immunix.org/
    * The LSM mailing list is managed by Mailman and is open for anyone
      to subscribe
      <http://mail.wirex.com/mailman/listinfo/linux-security-module>,
      unsubscribe, or view the archives
      <http://mail.wirex.com/pipermail/linux-security-module/>.
    * The LSM mailing list is also independently archived elsewhere
      <http://marc.theaimsgroup.com/?l=linux-security-module&r=1&w=2>.
    * For the first year or so, the LSM mailing list was "closed" in
      that posts from non-subscribers were trapped for moderation. I
      always approved such posts if they were topical, and used the
      moderation only to filter spam.
    * Subsequent to that, I was told that this is "not the linux way"
      and the mailing list was made "open" so that anyone can post, and
      Spamassassin was installed to filter spam (which doesn't quite
      work perfectly
      <http://mail.wirex.com/pipermail/linux-security-module/2002-October:/3658.html>).

It has never, ever been "private" any more than any of the other 
subsystem -devel lists are "private."

>As for "rather small", hundreds of people were involved in discussion
>during the initial development phase (Chris Wright generated some stats on
>this last year).
>
A few days after I opened the list, it had 300 subscribers. Today it has 
607 subscribers. There have been 4183 posts.

>There were specific LSM discussions at two kernel summits, while multiple
>OLS presentations have been given on LSM.
>
To me, the most gratifying result to come out of OLS 2002 
<http://www.linuxsymposium.org/2002/> (apart from Linus accepting the 
first patch :-) was the Ericsson project 
<http://www.linuxsymposium.org/2002/view_txt.php?text=abstract&talk=44>. 
What makes this project so impressive is that AFAIK Ericsson never asked 
the LSM mailing list a single question. They just took the documents and 
the code, and implemented their module. To me, *that* is evidence that 
the abstraction is usable: that an independent 3rd party can code to it 
without help.

>I do agree that we should have worked more closely with maintainers from
>the beginning, but this was not out of trying to be secretive (of which we
>have been accused quite a few times).  This happened out of believing that
>we should reach a design consensus and write some code via the before
>bothering any maintainers.  This approach was clearly flawed, and efforts
>have since been made to rectify this for ongoing development.
>
And in fact we did seek input from Theodore Ts'o in the summer of 2001. 
Most of that guidance was verbal, and it happened 18 months ago, so my 
memory is imperfect, but I think he advised us to keep the invasiveness 
minimal, and to avoid adding features that were just there to support 
audit. Others at that lunch were Chris Wright (WireX) and Pete Loscocco 
(SELinux).

What I've learned from the LSM merge process is that we need to get 
piecewise buy-in from each major subsystem maintainer that will be 
impacted. For instance, the network hooks did not go in as smoothly as 
we would have liked. Thanks to hard work from James Morris and helpful 
feedback from David Miller, they did go in after substantial revisions. 
Next time, we will float a paper design past subsystem maintainers ahead 
of time.

>Claims of a "secret" and non-generalized design process are baseless.
>
Here here.

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX                            http://wirex.com/~crispin/
Recruiting for Linux kernel and glibc developers: http://immunix.org/jobs.html


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59

[Pete Zaitcev]

>>>And here we see _the_ problem with the LSM process.  LSM wasn't
>>>developed as part of the broad kernel community (lkml) but on
>>>a rather small, almost private list.
>>>
>>Many of the things that you are saying in this discussion are untrue.
>>[...]
>>The bulk of the development process was carried out for more than two
>>years on the LSM development mailing list, which is fully public and open
>>to anyone.  It is not "almost private", whatever that is supposed to mean.

This is a situation, descibed by Douglas Adams in the opening
chapters of "Hitchiker's Guide to Galaxy". You put the vital info
somewhere, and when someone (who has to suffer if he does not see it)
fails to retrieve the info, it gets his own fault. It all was in
the open, so what else is to be desired?

I used to be super irritated by separate lists. Now I'm a member
of linux-usb-devel, uml-devel, sparclinux, and god knows what else.
Yes, they are unavoidable. Still, it is important to keep linux-kernel
at least somewhat informed. IMHO.

-- Pete

Re: What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59

[Crispin Cowan]

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

Pete Zaitcev wrote:

>I used to be super irritated by separate lists. Now I'm a member
>of linux-usb-devel, uml-devel, sparclinux, and god knows what else.
>Yes, they are unavoidable. Still, it is important to keep linux-kernel
>at least somewhat informed. IMHO.
>
LKML was kept at least somewhat informed, IMHO:

    * LSM announced April 11, 2001
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=98695004126478&w=4>
    * Should there be separate lists for module development?
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=98695659813419&w=4>
          o Probably
            <http://marc.theaimsgroup.com/?l=linux-kernel&m=98701977623500&w=4>
    * Discussion of the "DAC-out" design option appears in LKML July 12,
      2001
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=99497020101496&w=4>
    * LSM entangled in discussion of whether binary-only modules should
      be permitted, September 24, 2001
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=100134989121896&w=4>
    * Syscall 223 provisionally reserved for LSM
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=100255709403906&w=4>
    * LSM mentioned as related to extended attributes project
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=100509197600341&w=4>
    * Does LSM conflict with accessfs? January 16, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=101120760212957&w=4>
          o No, it does not
            <http://marc.theaimsgroup.com/?l=linux-kernel&m=101138310816232&w=4>
    * LSM in Guillaume's big list of 2.5 stuff, January 23, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=101176727007672&w=4>
    * LSM in Marc-Christian Petersen's forked kernel, May 21, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=102201919806027&w=4>
    * LSM interfacing to extended attributes, June 28, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=102527059400830&w=4>
    * First LSM patch into Linus' tree, July 16, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=102677797911383&w=4>
          o There are lots of these subsequently, so I won't cite them all
    * Racing with module load/unload affects LSM too, September 12, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=103181033207587&w=4>
    * HCH takes issue with LSM, September 26, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=103307580006067&w=4>
    * LSM hook style changes from low-cost hooks to no-cost configurable
      hooks, October 16, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=103472694817532&w=4>
    * LSM and GPL requirement for modules, October 17, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=103486544115996&w=4>
    * Remove the LSM sys_security call, October 17, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=103488104604175&w=4>
    * LSM changed so that module does not have to provision every hook
      by providing a default action, December 1, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=103872797618899&w=4>
    * The start of this flame-war, February 5, 2002
      <http://marc.theaimsgroup.com/?l=linux-kernel&m=104441899708408&w=4>

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX                             http://wirex.com/~crispin/
Recruiting for Linux kernel and glibc developers:  http://immunix.org/jobs.html


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59

[Casey Schaufler]

'Christoph Hellwig' wrote:

> And here we see _the_ problem with the LSM process.

I personally don't agree with the subject line,
as I don't believe that anything "went wrong" with
LSM. True, it's not what I want, but then my contribution
wasn't what it needed to be to make it such, either.
I often disagreed with the directions, and was sometimes
surprised, but that kind of thing happens in a large
group environment. My sage wisdom was considered
more often than not, even if it was discarded unused
from time to time.

I've been retrofitting security policy into U2X systems
since the 1980's, first Orange Book and now Common
Criteria, and it's HARD. LSM is a fine first whack.
No one should dispair that it fails to meet a particular
need exactly, or that those meany maintainers won't
accept your hook without seeing the code that uses it.
Alan Cox described the Linux development process as
climbing over a fence with everyones hands in each others
pockets, and I think that describes LSM pretty well.

Advanced security features are unpopular, and
all evidience points to them remaining so. We, as
a development community, have yet to convince the
great insecure masses that they want to see audit
trails, user clearances, and time of day controls
in "their" kernels. Heck, we have yet to convince
each other! But buck up, I fully expect we'll do
better next round, and better the time after that,
as well.

LSM isn't finished because Linux isn't finished
and as a group we security developers are a
tenacious (stubborn? pig headed maybe?) lot.

-- 

Casey Schaufler				Manager, Trust Technology, SGI
casey@sgi.com				voice: 650.933.1634
casey_p@pager.sgi.com			Pager: 877.557.3184

Re: What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59

[Crispin Cowan]

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

'Christoph Hellwig' wrote:

>On Wed, Feb 12, 2003 at 02:22:34PM -0800, Crispin Cowan wrote:
>
>>LSM does have an abstract design: it mediates 
>>access to major internal kernel objects (processes, inodes, etc.) by 
>>user-space processes, throwing access requests out to the LSM module.
>>    
>>
>We seem to use the term design differently.  And maybe my english
>wording wasn't perfect (I'm no native speaker..).  My objection is that
>LSM by itself does not enforce the tightest bit of security policy
>design.  Your "design" is putting in hooks before object accesses
>without making them tied to enforcing some security policy.
>
You're right, we're using English differently :-) I don't know what the 
above paragraph means. I can guess, but that's where the trouble is 
coming from. Based on the guessing:

    * Yes, LSM by itself does not enforce security policy.
    * Yes, the desing is to put hooks in front of important objects, and
      ask the modules if that access is ok.

The effect of this is to push security policy out to the modules. This 
is what Linus asked for, so that he would not have to maintain security 
policy or security policy engines.

>When reading this thread some people (e.g. David [*]) still seem that
>changes should be done for LSM's sake - but that's entirely wrong.
>The point of getting LSM or something similar in is for the sake
>of the _linux_ _kernel_ getting usefull features, not for enabling
>some small community writing out of tree modules.
>
You have often made this point about "for the Linux kernel's sake" vs. 
some other motivation, and it bothers me. It suggests that you somehow 
care about the Linux kernel more than I do. No, I care about the Linux 
kernel a lot. More over, I don't see how "who cares about the kernel 
more" is pertinent.

That aside, the Linux kernel per se is not some entity to be pleased 
like a stone god. Linux exists for its users. LSM is designed to benefit 
Linux kernel users. Some benefit by being able to add security features 
that they could not get before, because they are not capable of patching 
their own kernels. Some benefit by being able to produce experimental 
security modules without having to patch & track the Linux kernel. Some 
benefit by being able to unload security stuff and go for a leaner 
configuration.

LSM is not about pleasing a small number of module vendors. It is about 
benefiting a large number of potential users.

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX                      http://wirex.com/~crispin/
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
			    Just say ".Nyet"


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]