Re: [BK PATCH] LSM changes for 2.5.59

Re: [BK PATCH] LSM changes for 2.5.59

[Stephen D. Smalley]

Christoph Hellwig wrote:
> The wrong thing here is that you pass in the object itself, not
> it's ACC-relevant attributes.

That's no different than permission(), and it is the style of interface
suggested by Linus originally for LSM.  SELinux did provide an
interface more akin to what you describe (passing the security
identifiers of the process and relevant objects and a value indicating
the operation).  But SELinux was also more tightly integrated into the
kernel.  The original guidance for LSM was to simply pass the objects
and to use separate hooks for different operations, moving the
processing entirely into the module.

Bringing this all up now is definitely pointless.  LSM wasn't developed
in secret, and you could have made your case for a different
approach/interface at the very beginning.  If you had made a case early
on, and had gotten Linus to sign off on it, then we certainly wouldn't
have objected to such an approach.

> No it seems not pointless.  You add tons of undesigned cruft to 2.5 that
> will have to be maintained through all of 2.6. unless Linus hopefully
> pulls the plug soon enough.  You still haven't even submitted a single
> example that actually uses LSM into mainline.

Not undesigned, but designed to meet guidance with which you disagree.
There is a difference.

The capabilities module is one example, albeit a limited one.  As for
modules like SELinux, it seems better to wait until all of the
necessary hooks have either been accepted or definitively rejected
before submitting an adapted form of the module for mainline.  After
this set of changes, the only thing remaining is the networking hooks,
which have already gone through a feedback cycle with the networking
maintainers and are being pruned and revised accordingly.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

On Thu, Feb 06, 2003 at 10:02:37AM -0500, Stephen D. Smalley wrote:
> The capabilities module is one example, albeit a limited one.  As for
> modules like SELinux, it seems better to wait until all of the
> necessary hooks have either been accepted or definitively rejected
> before submitting an adapted form of the module for mainline.  After
> this set of changes, the only thing remaining is the networking hooks,
> which have already gone through a feedback cycle with the networking
> maintainers and are being pruned and revised accordingly.

Well, selinux is still far from a mergeable shape and even needed additional
patches to the LSM tree last time I checked.  This think of submitting hooks
for code that obviously isn't even intende to be merged in mainline is what
I really dislike, and it's the root for many problems with LSM.

There has been a history in Linux to only implement what actually needed
now instead of "clever" overdesigns that intend to look into the future,
LSM is a gross voilation of that principle.  Just look at the modules in
the LSM source tree:  the only full featured security policy in addition
to the traditional Linux model is LSM, all the other stuff is just some
additionl checks here and there.

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.

Life would be a lot simpler if you got the core flask engine in a mergeable
shapre earlier and we could have merged the hooks for actually using it
incrementally during 2.5, discussing the pros and contras for each hook
given an actual example - but the current way of adding extremly generic
hooks (despite the naming they are in no ways tied to enforcing security
models at all) without showing and discussing the code behind them simply
makes that impossible.

So yes, my suggestion is to backout the whole LSM mess for 2.6, merge
a sample policy core (i.e. a cleaned up flask/selinux) in 2.7.<early> and
then add one hook after another and discussing the architecture openly
where it belongs (here on lkml!).

Re: [BK PATCH] LSM changes for 2.5.59

[David Wagner]

Christoph Hellwig  wrote:
>Well, selinux is still far from a mergeable shape and even needed additional
>patches to the LSM tree last time I checked.  This think of submitting hooks
>for code that obviously isn't even intende to be merged in mainline is what
>I really dislike, and it's the root for many problems with LSM.

You keep bringing up SELinux.  Maybe you dislike SELinux; I don't know.
In any case, LSM is not there just to support SELinux.  It's intended
to support a broad range of security modules and security policies.
LSM is bigger than just SELinux.

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

[it would be really nice if you at least Cc'ed me when replying to my mails..
  *sigh*]

On Thu, Feb 06, 2003 at 05:16:39PM +0000, David Wagner wrote:
> Christoph Hellwig  wrote:
> >Well, selinux is still far from a mergeable shape and even needed additional
> >patches to the LSM tree last time I checked.  This think of submitting hooks
> >for code that obviously isn't even intende to be merged in mainline is what
> >I really dislike, and it's the root for many problems with LSM.
> 
> You keep bringing up SELinux.  Maybe you dislike SELinux; I don't know.
> In any case, LSM is not there just to support SELinux.  It's intended
> to support a broad range of security modules and security policies.
> LSM is bigger than just SELinux.

I bring up selinux because it's the only module in the lsm patches that I
consider more than just a bunch of hacks.  So, no it's not a dislike but
they only thing I actually consider worth mentioning.

Re: [BK PATCH] LSM changes for 2.5.59

[Alan Cox]

On Thu, 2003-02-06 at 15:18, Christoph Hellwig wrote:
> Life would be a lot simpler if you got the core flask engine in a mergeable
> shapre earlier and we could have merged the hooks for actually using it
> incrementally during 2.5, discussing the pros and contras for each hook

I'm not sure we can until the flask engine patent problems with secure
computing are completely resolved and understood. 

Getting it all resolved and in the base 2.7 early, with any cleanup, fixing
needed would be a good step forward

Re: [BK PATCH] LSM changes for 2.5.59

[jmjones]

On Thu, 6 Feb 2003, Christoph Hellwig wrote:

> Well, selinux is still far from a mergeable shape and even needed additional
> patches to the LSM tree last time I checked.  This think of submitting hooks
> for code that obviously isn't even intende to be merged in mainline is what
> I really dislike, and it's the root for many problems with LSM.

I disagree.  The code submitted BOTH addresses the current needs and
"vaguely anticipated future needs" (which I shall define as VAFN).  I've
applied this code to my "personal security solution" and found it
*largely* to address my needs.  Wanna see my code?  *NO*  I have other
plans for my code, but I still think LSM supports me more than the 2.4
kernel does and, therefore, *I* believe it is a move in the right
direction for the kernel.

> 
> There has been a history in Linux to only implement what actually needed
> now instead of "clever" overdesigns that intend to look into the future,
> LSM is a gross voilation of that principle.  Just look at the modules in
> the LSM source tree:  the only full featured security policy in addition
> to the traditional Linux model is LSM, all the other stuff is just some
> additionl checks here and there.
> 

This is correct, except in its overall evaluation of Linux.  Linux has
accepted only "actually needed" code, but it has FURTHER accepted
"actually needed but GENERALLY useful code."  If one can accept code that
already has a purpose AND support other "'clever' overdesigns that intend
to look into the future" which are "not-opposed-to-current-thinking", one
has moved one's project closer to an ideal. 
 
You can narrow AND widen, and Linux is the *best* example of that policy,
to date.  There's no dishonor in accepting solutions that do what they
advertise AND allow what they have not advertised... provided they not
allow things widely defined as "evil."
 
> 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.
 
This would be unfortunate.  Narrow is good when one approaches a narrow
target, but LSM targets a wide target: Linux Security.

> 
> Life would be a lot simpler if you got the core flask engine in a mergeable
> shapre earlier and we could have merged the hooks for actually using it
> incrementally during 2.5, discussing the pros and contras for each hook
> given an actual example - but the current way of adding extremly generic
> hooks (despite the naming they are in no ways tied to enforcing security
> models at all) without showing and discussing the code behind them simply
> makes that impossible.
> 

Open your mind.  LSM supports both all current solutions for object-level
security AND provides a valid basis for moving Linux toward providing, AS
AN OPTION, true security.  Personally, I don't think LSM is the "be all
and end all" of a security interface, at this point, but I *do* think it's
the best first-draft of a system that can lead to that end.

Give me THREE design attributes that would make it better.  Bet you can't
come up with ONE.

LSM is NOT the *perfect* solution.  But I defy you to find a better
"first step" toward the solution of making Linux a "secure operating
system".  Nobody says it's cheap and the idea of making it a config-out
solution addresses that. 

What's your REAL problem?  Somebody stepping on your territory?
J. Melvin Jones

*-------------------------------------------------------
* J. Melvin Jones                http://www.jmjones.com/
* Webmaster, System Administrator, Network Administrator
* ------------------------------------------------------

Re: [BK PATCH] LSM changes for 2.5.59

[Miles Bader]

jmjones@jmjones.com writes:
> What's your REAL problem?  Somebody stepping on your territory?

Come on, don't be an ass.

Perhaps there are people on this mailing list who play silly territorial
games, but I don't think Christoph is one of them.  If he suggests that
there's a problem with something, the likely reason is that there's a
problem.

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

On Fri, Feb 07, 2003 at 09:20:08PM -0500, jmjones@jmjones.com wrote:
> I disagree.  The code submitted BOTH addresses the current needs and
> "vaguely anticipated future needs" (which I shall define as VAFN).

What is the "current needs" given that selinux is the only module actually
using it and it's neither in a mergeable shape nor is it legally clear
whether it can be merged?

> Open your mind.  LSM supports both all current solutions for object-level
> security AND provides a valid basis for moving Linux toward providing, AS
> AN OPTION, true security.  Personally, I don't think LSM is the "be all
> and end all" of a security interface, at this point, but I *do* think it's
> the best first-draft of a system that can lead to that end.

you don't get tru security by adding hooks.  security needs a careful
design and more strict access control policy can but don't have to be part
of that design.

> What's your REAL problem?  Somebody stepping on your territory?

The real problem is adding mess to the kernel.

Re: [BK PATCH] LSM changes for 2.5.59

[Crispin Cowan]

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

Christoph Hellwig wrote:

>you don't get tru security by adding hooks.  security needs a careful
>design and more strict access control policy can but don't have to be part
>of that design.
>
LSM does have a careful design. The design goal was to permit loadable 
kernel modules to mediate access to critical kernel objects by user 
level processes. By providing such a facility, LSM enables arbitrary 
security policies and policy management engines to be implemented as 
loadable modules. This solves the "make one size fit all" problem of 
diverse interests lobbying Linus to adopt one security model or another 
as the Linux standard. The LSM design saves Linus from having to make 
such a  choice by allowing end-users to make their own choice, meeting a 
goal stated by Linus nearly two years ago.

>The real problem is adding mess to the kernel.
>
Christoph's problem is likely that he doesn't like the design. Fair 
enough, can't please everyone, but a lot of effort went into that 
design. I also suspect that Christoph does not approve of Linus' design 
goal either, but he's never said that when I was looking.

Crispin

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


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

RE: [BK PATCH] LSM changes for 2.5.59

[LA Walsh]

> From: Crispin Cowan
>
> Christoph Hellwig wrote:
> 
> LSM does have a careful design. The design goal was to permit loadable 
> kernel modules to mediate access to critical kernel objects by user 
> level processes. By providing such a facility, LSM enables arbitrary 
> security policies and policy management engines to be implemented as 
> loadable modules. This solves the "make one size fit all" problem of 
> diverse interests lobbying Linus to adopt one security model or another 
> as the Linux standard. The LSM design saves Linus from having to make 
> such a  choice by allowing end-users to make their own choice, meeting a 
> goal stated by Linus nearly two years ago.
====
	A security model that mediates access to security objects by
logging all access and blocking access if logging cannot continue is
unsupportable in any straight forward, efficient and/or non-kludgy, ugly
way.  
	LSM is a collection of hack & hooks thrown together in an ad-hoc
manner to support those people who were able to lobby their specific
security policies.  Some security people were banned from the kernel
devel. summit because their thoughts were deemed 'dangerous': fear was they
were too persuasive about ideas that were deemed 'ignorant' and would
fool those poor kernel lambs at the summit.

	Also unsupported: The "no-security" model -- where all security 
is thrown out (to save memory space and cycles) that was desired for embedded work.

	LSM also doesn't support standard LSPP-B1 style graded security
where mandatory access checks are logged as security violations before
DAC checks are even looked at for an object.

	At one point a plan was proposed (by Casey Schaufler, SGI) and 
_\implemented\_ (team members & prjct lead Linda Walsh) to move all
security checks out of the kernel into a 'default policy' module.
The code to implement this was submitted to the LSM list in June 1991.
  
	This plan was shot down as "too radical".  It wasn't what the "kernel
programmers" wanted.  "They" would never accept it and therefore, LSM wouldn't accept it without prior approval from the "kernel
programmers".
When such approval was sought, the seeking party was drawn and quartered
for having the temerity to actually ask the question (since asking the question pointed out the failings of LSM to meet its original
design
goals).

> 
> >The real problem is adding mess to the kernel.
> >
> Christoph's problem is likely that he doesn't like the design. Fair 
> enough, can't please everyone, but a lot of effort went into that 
> design.
---
	True...alot of effort went into building the Titanic as well.

	The modular security model was implemented via macros and cleaned
up the logic of the kernel code by moving toward single exit points
that could allow consistent release of acquired data structures and locks
depending on where failure occurred.  That alone made the code more
readily understandable and maintainable.  Removing security policy
from the code into separate modules also made validation of security
considerably easier.

	So...of course, it wasn't wanted.

	LSM may implement some number of policies, but it is neither robust
nor easy to use.  Only recently was it decided not to require that every
security module to know about every hook.  That was also suggested almost
2 years ago because the current setup makes the implementation of 
security policies *MUCH* more complicated...and, theoretically, inherently
less provably secure.

l. walsh

Re: [BK PATCH] LSM changes for 2.5.59

[Crispin Cowan]

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

LA Walsh wrote:

>>From: Crispin Cowan
>>
>>LSM does have a careful design.... meeting a 
>>goal stated by Linus nearly two years ago.
>>    
>>
>	A security model that mediates access to security objects by
>logging all access and blocking access if logging cannot continue is
>unsupportable in any straight forward, efficient and/or non-kludgy, ugly
>way. 
>
Because Linus asked for access control support, not audit logging 
support, it is not surprising that logging models don't fit so well.

>  Some security people were banned from the kernel
>devel. summit because their thoughts were deemed 'dangerous': fear was they
>were too persuasive about ideas that were deemed 'ignorant' and would
>fool those poor kernel lambs at the summit.
>
Internal SGI politics.

>	Also unsupported: The "no-security" model -- where all security 
>is thrown out (to save memory space and cycles) that was desired for embedded work.
>
False: capabilities is now a removable module, which is what Linus asked 
for.

>	LSM also doesn't support standard LSPP-B1 style graded security
>where mandatory access checks are logged as security violations before
>DAC checks are even looked at for an object.
>
Because doing so would have required approx. 6-10X as many LSM hooks as 
the current LSM. Speak up if you think LSM should be 10X bigger to be 
able to support Common Criteria standards compliant audit logging ...

>	At one point a plan was proposed (by Casey Schaufler, SGI) and 
>_\implemented\_ (team members & prjct lead Linda Walsh) to move all
>security checks out of the kernel into a 'default policy' module.
>The code to implement this was submitted to the LSM list in June 1991.
>
And I actually like that plan. But I still believe it to be too radical 
for 2.6. It has many nice properties, but is much more invasive to the 
kernel. I think it is a very interesting idea for 2.7, and should be 
floated past the maintainers who will be impacted to see if it has a 
hope in hell.

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

Re: [BK PATCH] LSM changes for 2.5.59

[J Sloan]

LA Walsh wrote:

>	At one point a plan was proposed (by Casey Schaufler, SGI) and 
>_\implemented\_ (team members & prjct lead Linda Walsh) to move all
>security checks out of the kernel into a 'default policy' module.
>The code to implement this was submitted to the LSM list in June 1991.
>
er - are you quite certain about that date?

;-)

Joe

Re: [BK PATCH] LSM changes for 2.5.59

[David Wagner]

Christoph Hellwig  wrote:
>[...] given that selinux is the only module actually using it [...]

No, it's not.  I keep you telling you LSM is not just about SELinux,
but I'm happy to say it again, if necessary.

>you don't get tru security by adding hooks.

Of course not.  Noone is saying that the LSM hooks alone give security;
rather, they enable you to install a module that gives security.

>security needs a careful design

You keep saying this.  People keep telling you that LSM does have a
careful design.  I suspect you mean that you don't like the design we
chose, for whatever reason -- but that's a different sort of beast,
isn't it?

If you have constructive suggestions, I'm listening.

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

On Mon, Feb 10, 2003 at 05:59:19AM +0000, David Wagner wrote:
> Christoph Hellwig  wrote:
> >[...] given that selinux is the only module actually using it [...]
> 
> No, it's not.  I keep you telling you LSM is not just about SELinux,
> but I'm happy to say it again, if necessary.

So show me a different module using most of the hooks, it's that simple!

RE: [BK PATCH] LSM changes for 2.5.59

[LA Walsh]

> On Wed Apr 11 2001 - 18:28:50 PDT
> Crispin Cowan, Ph.D (Chief Scientist, WireX) claims:
> 
> Because Linus asked for access control support, not audit logging 
> support, it is not surprising that logging models don't fit so well.

Oh really?  On Wed Apr 11 2001 - 18:28:50 PDT
From: Crispin Cowan (crispin@wirex.com) told us:

	"Linus ...observes that there are many different security 
	approaches, each with their own advocates.  He doesn't want 
	to arbitrate which of them should be "the" Linux security 
	approach, and would rather that Linux can support any of 
	them.

	That is the purpose of this project:  to allow Linux to 
	support a variety of security models"

---
	You recognize that as your writing?  Perhaps with the context of
the full post, below, it will help.  Even more so,  Linus's emails that
defined the "charter" are also included below.  

	Maybe I'm delusional, but you are contradicting yourself.  In
common terms, this is called lying.  Either Linus didn't say he wanted
something "truly generic" (his words), and you made up the email from
Linus or you are trying to change what he said to suite your current
purposes.  You suckered in more than a few people with promises from below and then changed things cause you and other lsm members
were too 
afraid that the right thing wouldn't fly with "the kernel programmers".

	Security isn't just an afterthought you can patch on and cross
your fingers and hope it won't break.  It has to be designed in.  
Lsm came closest to that when we put the code on the table (2001, not 1991)
to fundamentally redesign linux security for today's needs.  Instead, we
end up with dribbled in patches of mediocrity that put us one step
closer to the byzantine, "Microsoftesque" OS model.  

	By some basic, unwritten, design short-comings (not present in the original plan), you have something that is neither
"simple" nor
"generic".  

	Complete text is written below if anyone cares to see how much
lsm has strayed and compromised away from the original charter.

Special.
-l

-------------------------------------------------------------------

From: Crispin Cowan (crispin@wirex.com)
Date: Wed Apr 11 2001 - 18:28:50 PDT 

--------------------------------------------------------------------------------


Greetings.  Thanks for your patience at the lack of traffic on the first day of
this list.  Subscriptions grew rapidly from nil to 202 in the last 24 hours, and
has now tapered off.  I held back posting introductory materials so that I
wouldn't have to post them three or four times :-)

Naturally, everyone is curious what this project is about in general:  why use a
generic security module interface?  And in particular, what has changed in Linus'
view of security extensions.  Rather than attempt to speak for Linus, I will
quote what he said in a private forum, and we can proceed from there.

It is Linus' comments that spurred me to want to start this undertaking.  He
observes that there are many different security approaches, each with their own
advocates.  He doesn't want to arbitrate which of them should be "the" Linux
security approach, and would rather that Linux can support any of them.

That is the purpose of this project:  to allow Linux to support a variety of
security models, so that security developers don't have to have the "my dog's
bigger than your dog" argument, and users can choose the security model that
suits their needs.

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org

  ------------------------------------------------------------------------

Linus Torvalds wrote:

> On Fri, 6 Apr 2001, Peter G. Neumann wrote:
> >
> > No mention of security or reliability.  Is that an omission of
> > Edupage or of the gurus?
>
> I think it's another commentary on security not being "interesting".
>
> We had a NSA person give a talk about selinux, and I personally wouldn't
> mind having a better infrastructure in place in the kernel for things like
> that. HOWEVER, my problem as a system maintainer is that I don't see
> people agreeing about the right solution.
>
> The embedded people don't really want security management (or rather, to
> them, the simple "root is all"  approach is fine, and takes up less space
> than more complex schemes with the selinux kind of security managers etc).
>
> And even the security people aren't really sure which _sort_ of security
> support they want (or rather - they all KNOW which kind of security
> management they want, but there are as many different opinions as there
> are people).
>
> So I'm not interested in any one particular approach, TE/DTE/MLS or
> whatever. I can't even discuss the difference intelligently anyway (or
> even play at it), but what I can tell is that there is no "one right way".
> And that's without even getting into the issue of what the policy should
> be for them.
>
> Which means that what _I_ would require from something that gets
> integrated into Linux is either:
>
>  - true simplicity. "euid == 0" is this. capabilities are an approximation
>    of this, and it turns out that almost nobody even uses capabilities
>    just because they are complex enough to administer that they are of
>    dubious value in many cases. The notion of an extended "suid" bit (with
>    an ELF header of capabilities) has been bandied around for a long time,
>    and the fact is that it would be a total maintenance nightmare. And
>    that's the _simple_ case.
>
>    This is where Linux is now, and this is where we'll remain, unless we
>    get the alternative:
>
>  - truly generic. No "MLS" vs "TE" vs "uid==0" vs "capability" at ALL.
>    Something where the "uid == 0" version of security is just one case
>    (which the embedded people might use), or where SELinux would be just a
>    matter of loading the SELinux module and installing _that_ security
>    model.
>
> Quite frankly, nobody seems to be interested in actually trying to do the
> latter. Everybody has their _own_ particular flavour that they want to
> push, and don't realize that I cannot accept that as a maintainer.
>
> I would, for example, be willing to entertain the notion of having a
> (global or per-process or whatever) pointer to a "security checks"
> structure:
>
>         struct security_checks_struct {
>                 int (*execve)(struct task_struct *tsk,struct binprm *new);
>                 int (*file_open)(struct file *);
>                 int (*raise_capability)(...
>                 ...
>                 ... selinux had about 140 points they wanted to hook into  ..
>                 ... others probably have a few more.
>                 ...
>         };
>
> and then just have a opaque per-security-model security ID thing scattered
> around in critical places (the obvious being the thread structure, files,
> directory cache, inodes, etc). And instead of having _any_ policy at all,
> the kernel would just call the security procedure. Which might choose to
> fail (-EFASCIST) or might choose to return success but silently downgrade
> the security of the process that does the action, or whatever.
>
> Please understand that from _my_ perspective as a technical OS guy, I
> don't actually care about what the policy is, or who makes it up. I only
> care about not painting Linux into a corner. And I care about it being
> efficient and _conceptually_ simple (it doesn't matter to me if any
> particular security decision is really hard to make or not).
>
> I can live with the overhead of a function pointer access. As Don Knuth
> said: every problem in computer science can be solved with an added level
> of indirection. I'm not interested in the fight between different security
> people. I want the indirection that gets _me_ out of that picture, and
> then the market can fight out which policy and implementation actually
> ends up getting _used_.
>
>                 Linus

  ------------------------------------------------------------------------

Linus Torvalds wrote:

> On Sat, 7 Apr 2001, David Wagner wrote:
>
> > > I would, for example, be willing to entertain the notion of having a
> > > (global or per-process or whatever) pointer to a "security checks"
> > > structure:
> > >
> > >     struct security_checks_struct {
>         ...
> > > and then just have a opaque per-security-model security ID thing scattered
> > > around in critical places (the obvious being the thread structure, files,
> > > directory cache, inodes, etc).
> >
> > Let me suggest a few design issues for consideration:
> >
> >   - State.
>
> Absolutely. This is the "opaque per-security-model security ID thing". You
> absolutely _have_ to have state for a lot of interesting security models.
> In fact, even simple capabilities are "state" - the only common stateless
> security model is the "euid == 0" one, where the "state" is actually just
> super-imposed on the user ID (ie it's really stateful too, it's just that
> the state is shared with "non-security" issues).
>
> >   - Passive vs. active filtering.
>
> Again, passive filtering doesn't actually work. UNIX already has one
> mandated way of active filtering, namely the execve() case for suid
> executables. I would absolutely prefer to see that as just another case of
> filtering, not as some special case.
>
> Which implies that all the other functions might as well also do active
> changes to the security model. Things like "uhhuh, he opened a file that
> was marked secure, we must thus mark the whole process secure and make
> sure that all current and future file descriptors are trusted".
>
> Just returning an error code is not enough. Active side effects are a
> natural and important part of many security models.
>
> >   - Composition of policies.
> >     How are policy extensions combined?  Can we have wuftpd restricted
> >     according to SELinux policy, sendmail according to Janus policy, ...
>
> This is problematic.
>
> The problem is the "security ID". If you allow concurrent security
> policies, they need to have ways of agreeing on the meaning of the
> security ID, or the system needs to support the notion of multiple
> concurrent security ID's (and associate them with the right policy). And
> THAT is hard. It's probably hard enough to not be worth it, and most
> people who want the flexibility would be probably be willing to code up
> the "supercase" in the security manager, instead of trying to mix security
> models dynamically.
>
> This is especially true as the interactions could be "interesting", and
> probably very hard indeed to validate.
>
> In short, my personal opinion would be a big NO, simply from a system
> design standpoint. With one small modifier:
>
> I did suggest a "per-process" security pointer. The reason is that even if
> the system doesn't actually enforce any policy, there obviously _has_ to
> be a default policy. The policy could be anything, from "allow everything"
> to "allow nothing", although the latter would make it really hard to
> bootstrap a system ;)
>
> For obvious reasons, the natural "default policy" is the one that Linux
> already has: capabilities. As that is "nearly stateless" (and can be
> considered essentially stateless if you just leave the current capability
> bits in the process space and do not try to move them into the new "opaque
> security ID" part of the process), that default policy can co-exist with
> any other policy by virtue of not ever actually touching the "opaque
> security ID".
>
> And allowing that co-existence (by having the security action stucture
> pointer be per-process) makes it _much_ easier to have a graceful
> transition to the new scheme. As an example:
>
>  - the system comes up in "legacy" mode with the capabilities (but you
>    might as well think of it as "root user can do anything", because that
>    is hot 99.999% of people end up using the capabilities).
>
>  - the "security environment" is started. Unlike all existing models, this
>    "security environment" doesn't actually have to have _any_ practical
>    compatibility at all with the legacy mode, as those things can be
>    handled ourside the security environment using the proper legacy tools.
>
>  - the system manager might choose, for example, to leave the
>    old-fashioned getty system for the local console, using the default
>    capability system. This way the manager might log in at the system
>    console (but nowhere else), and be completely _outside_ the secure
>    area.
>
> Imagine the implications: your "security manager" doesn't need to actually
> worry about system management at all, because you might have the policy
> that all system management _must_ be done at the physical system console.
> As such, your security policies may not even have the _notion_ of allowing
> for "raised capabilities", and as such there is absolutely no way anybody
> could get higher capabilities than those they started with.
>
> Most traditional security systems need to have _some_ way of getting
> higher privileges for true system management. By using the above
> "per-process security management" setup, you kind of get it for free. You
> might run all your services inside a security model that simply does not
> _have_ a way out. Not for management, not for anything. Because management
> is done completely ourside the security model.
>
> Useful? Sounds useful to me. It also sounds simple to implement, and gives
> you perfect backwards compatibility without the security manager having to
> even worry about it - because the security manager wouldn't even be
> involved in the legacy stuff.
>
> >   - What to interpose on?
> >     Here are a few suggestions for possibilities: interposition on all
> >     system calls; interposition on all VFS calls; on sockets.  What else?
>
> Not at a system call level. It gets too intrusive, and too many people
> (including me) start to worry a _lot_ if you lose even one cycle in the
> system call path. Linux system calls are lightweight, and I like them that
> way.
>
> Also note that the traditional notion of "accounting system calls" is just
> _stupid_. It's the wrong abstraction level. Some system calls do many
> things (think "getxuid()"). Other system calls give direct user-space
> access to objects, so you can only see that you had access to the object,
> you can't actually see _what_ the user did anyway (think "mmap").
>
> You interpose on well-defined abstraction levels. Anything else is a waste
> of time, and useless. Why should you care if the user does a system call:
> sometimes the user can do the same thing by hand, and the system call is
> nothing but a convenience. The extreme case of this would be the whole
> TCP/IP stack: the user _could_ just open a raw packet socket and do its
> own TCP/IP stack totally in user mode. Or think about "gettimeofday()":
> it could be a system call on some architectures, and avaiable in user mode
> on others.
>
> And even when you have meaningful system calls like "write", why interpose
> on that. Nobody cares if you write to /dev/null, while if you write to
> /etc/passwd people might take a second look. You need to get in at the
> _meaningful_ level.
>
> And the system call interface is meaningless in itself. I suspect the only
> reason people focus on hooking into system calls is that it tends to be
> "easy", and a simpel specification - you can ask a summer intern to add
> the hook to monitor every system call. That doesn't make it meaningful.
>
> So add the hooks at the proper level - and make sure they really _are_
> necessary, because people start worrying about performance if you have too
> many function calls, even if they would default to being an immediate
> return in the common case. A cycle here and a cycle there adds up. I'm
> willing to add better security infrastructure, but that doesn't mean that
> I'd be willing to be stupid.
>
> (I know about accounting. And I disagree. What the HELL is the point in
> accounting how many system calls some process made? What does that tell
> you? It tells you _nothing_. Yet every single OS for some reason has hooks
> to accound system calls. That's STUPID.)
>
> Interesting objects to add security ID's to: processes, files, pathnames
> ("dentry" in Linux-speak), inodes (which includes a lot of different cases
> like sockets etc), routes, devices, etc. But _not_ system calls. You add
> the hooks to the actual places that look up (and especially modify) the
> data structures you've tagged.
>
> I'd be surprised if there are many more than 5-10 different object types
> you'd need to tag, and more than maybe 200 places where you'd need to
> intercept then. Total infrastrucure patch size should be on the order of a
> few thousand lines.
>
> (Remember: I'm not interested in the actual security _manager_, which may
> of course be arbitrarily complex in itself. The code _there_ to keep track
> of whatever security tags etc could be hairy and much bigger. But once it
> is encapsulated well enough, that part is no longer an issue from a system
> design perspective).
>
>                 Linus


--------------------------------------------------------------------------------

Re: [BK PATCH] LSM changes for 2.5.59

[Chris Wright]

* LA Walsh (law@tlinx.org) wrote:
> 	Maybe I'm delusional, but you are contradicting yourself.  In

Re-read Linus' original spec with the following things in mind:
- we don't interpose at the system call level, rather the kernel object level
- we tag about 8 objects
- we have about 150 callbacks
- we don't move the capabilities bits from the task struct to the opaque id
- we allow active filtering
- we discourage generic policy composition
- we support models such as MLS, TE, DTE, RBAC, Capabilities, PBAC/TBAC
  (whatver you want to call it), etc.

The fact that we don't support CAPP or LSPP standard compliant systems
which require MAC checks before DAC checks for _auditing_ is outside the
scope of this access control system.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [BK PATCH] LSM changes for 2.5.59

['Christoph Hellwig']

On Sun, Feb 09, 2003 at 07:40:17PM -0800, Crispin Cowan wrote:
> >	Also unsupported: The "no-security" model -- where all security 
> >is thrown out (to save memory space and cycles) that was desired for embedded work.
> >
> False: capabilities is now a removable module, which is what Linus asked 
> for.

It's not.  You put a bit of capability logic into a LSM module, but all
the specific calls to capable are still around and turned into an LSM hook -
often near another hook.

> >_\implemented\_ (team members & prjct lead Linda Walsh) to move all
> >security checks out of the kernel into a 'default policy' module.
> >The code to implement this was submitted to the LSM list in June 1991.
> >
> And I actually like that plan. But I still believe it to be too radical 
> for 2.6.

It's too later for 2.6 _now_.  If you started doing this in early 2.5
we'd have a much less messy ACC architecture by now.  

> It has many nice properties, but is much more invasive to the 
> kernel. I think it is a very interesting idea for 2.7, and should be 
> floated past the maintainers who will be impacted to see if it has a 
> hope in hell.

*nod* and until we get that gets implemented we should remove the current
mess..

Re: [BK PATCH] LSM changes for 2.5.59

[Crispin Cowan]

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

'Christoph Hellwig' wrote:

>On Sun, Feb 09, 2003 at 07:40:17PM -0800, Crispin Cowan wrote:
>  
>
>>[move security logic out to a module] It has many nice properties, but is much more invasive to the 
>>kernel. I think it is a very interesting idea for 2.7, and should be 
>>floated past the maintainers who will be impacted to see if it has a 
>>hope in hell.
>>    
>>
>*nod* and until we get that gets implemented we should remove the current
>mess..
>
Am I parsing this correctly, that we actually agree on something? :-) 
I.e. that the idea of moving all the security logic to a module has merit.

Naturally, I disagree that we should remove the current LSM. The current 
version was designed to be what Linus asked for. Many LSM people like 
the idea of moving all the security logic out to a module, as it makes 
the interface much cleaner. But it is also waaay beyond the scope of 
what Linus asked for. It involves re-factoring so much code that we did 
not think it could be done correctly on the first try, never mind trying 
to get many code maintainers to accept much larger patches.

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

Re: [BK PATCH] LSM changes for 2.5.59

['Christoph Hellwig']

On Mon, Feb 10, 2003 at 12:33:12AM -0800, Crispin Cowan wrote:
> Am I parsing this correctly, that we actually agree on something? :-) 
> I.e. that the idea of moving all the security logic to a module has merit.

Yes.  If we want so support security models more complicated than plain
UNIX DAC (an especially more than one of those) there's no way around
moving all access control out of the core kernel.

> Naturally, I disagree that we should remove the current LSM. The current 
> version was designed to be what Linus asked for. Many LSM people like 
> the idea of moving all the security logic out to a module, as it makes 
> the interface much cleaner. But it is also waaay beyond the scope of 
> what Linus asked for. It involves re-factoring so much code that we did 
> not think it could be done correctly on the first try, never mind trying 
> to get many code maintainers to accept much larger patches.

Well, usually adding changes to the core kernel in a proper way needs
major refactoring of code - the approach of adding a small, "non-invasive"
hack here and there leads to the typical mess seen in commercial operating
systems, and in Linux we've avoided that mostly so far.

As far keeping the current LSM hooks:  I'm very unhappy with the design
of the, that's one point.  The other point I'm extremly unhappy with
adding them without adding it's users.  I'll shut up and be quite until
2.7 opens if you get a meaningfull LSM module merged that actually uses
those hooks.  If you don't get one in by 2.6-test I will send patches
to remove those unused hooks.

Re: [BK PATCH] LSM changes for 2.5.59

[Alan Cox]

On Mon, 2003-02-10 at 03:40, Crispin Cowan wrote:
> Because Linus asked for access control support, not audit logging 
> support, it is not surprising that logging models don't fit so well.

The snare folks are moving bit by bit from their original hacks to
a clean audit hook model. That may give you the hooks you want for
auditing in 2.7. Thats seperate to the security stuff and you may
want one and not the other.

Re: [BK PATCH] LSM changes for 2.5.59

[Casey Schaufler]

Crispin Cowan wrote:
> 
> LA Walsh wrote:
> 
> >>From: Crispin Cowan
> >>
> >>LSM does have a careful design.... meeting a
> >>goal stated by Linus nearly two years ago.
> >>
> >>
> >       A security model that mediates access to security objects by
> >logging all access and blocking access if logging cannot continue is
> >unsupportable in any straight forward, efficient and/or non-kludgy, ugly
> >way.
> >
> Because Linus asked for access control support, not audit logging
> support, it is not surprising that logging models don't fit so well.
> 
> >  Some security people were banned from the kernel
> >devel. summit because their thoughts were deemed 'dangerous': fear was they
> >were too persuasive about ideas that were deemed 'ignorant' and would
> >fool those poor kernel lambs at the summit.
> >
> Internal SGI politics.

Just a gentle reminder that Ms. Walsh is not an SGI employee
and that any opinions she may express regarding the Linux
development process are her own, and may not reflect the
views or understandings of SGI or any other individuals
involved.

In particular, dragging SGI into this discussion is
inappropriate and unnecessary. SGI is currently not
active in this effort, and makes no claims regarding
it's appropriateness to any particular purpose.

Please leave SGI, in spirit and name, out of
this discussion.

-- 

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

RE: [BK PATCH] LSM changes for 2.5.59

[LA Walsh]

 
> >  Some security people were banned from the kernel
> >devel. summit because their thoughts were deemed 
> 'dangerous': fear was they
> >were too persuasive about ideas that were deemed 'ignorant' and would
> >fool those poor kernel lambs at the summit.
> >
> Internal SGI politics.
---
	Nope... external -- the conference organizer was the one selecting and specifically disallowing certain attendees.  It
appeared important to weed out anyone who didn't think like him.

> 
> >	Also unsupported: The "no-security" model -- where all security 
> >is thrown out (to save memory space and cycles) that was 
> desired for embedded work.
> >
> False: capabilities is now a removable module, which is what 
> Linus asked 
> for.
---
	FALSE?  Are you telling us that you believe the only security in the kernel concerns capabilities?  Most security people
would acknowledge that Discretionary Access Control (DAC) by user-id and privilege control via
the binary "(UID==0)" would qualify as a "security" model.  Even the "Mandatory Access Control" bits, "immutable" and "append-only",
are a security model.  Capabilities are an almost insignificant part of security compared to the code for DAC and UID==0 checks.
Your statement
is misdirecting like a response to a question about a car: "How does 
it run?  Reliability?  Look at those tires! You won't see tires like 
that anywhere!" 



  
> 
> >	LSM also doesn't support standard LSPP-B1 style graded security
> >where mandatory access checks are logged as security 
> violations before
> >DAC checks are even looked at for an object.
> >
> Because doing so would have required approx. 6-10X as many 
> LSM hooks as 
> the current LSM. Speak up if you think LSM should be 10X bigger to be 
> able to support Common Criteria standards compliant audit logging ...
---
	I don't have current figures, but in the 2.4.2 kernel from Apr, 01,
I noted that the LSM patch yielded 179 patches to 35 source files
in 68 different procedures of which 33 are system calls."

The 2.4.2 audit patch had about 130 different procedure's "hooked" with
maybe twice that many data collection calls depending on the route taken through the code.  Additionally exit calls were required
for each
procedure (with exact number depending on how many different exit points
existed/procedure).  This was before any work combining exit targets that often simplified code to 'unroll' state.

	On IRIX, compiler pragmas like "execute_frequency_hint NEVER"
made sure that mainline cache wasn't harmed in the normal case and
required that even code computing audit masks was done 'out of line'.  
On a P4, this could be similar to hinting to the processor what to
optimize it's pipeline for -- meaning virtually no execution impact when audit was compiled in but turned off because the pipeline
would already be started on the post branch code.  But these intricacies are a matter of 
compiler technology.

	A pre-LSM version of audit existed and completely compiled out when not explicitly selected as a kernel build option.  When
enabled, _FULL_ auditing of a kernel build on a 2PIIx400 machine measured about 10% overhead, typically, for the 2.4.[12] series
(single HD, ~3-5Mb/s record
rate).  Compiled in but turned off, impact was *questionably* measurable (<.3%) and turned on but "no events" was still in noise
range (<1%) with typical monitoring sets being <3% overhead.  This was with no specific performance tuning -- just SMP stress
testing.

> >	At one point a plan was proposed (by Casey Schaufler, SGI) and 
> >_\implemented\_ (team members & prjct lead Linda Walsh) to move all
> >security checks out of the kernel into a 'default policy' module.
> >The code to implement this was submitted to the LSM list in 
> June [2001].
> >
> And I actually like that plan. But I still believe it to be 
> too radical for 2.6.
---
	The kernel was at version 2.4.[2-4].  At that time,  2.5 didn't even exist.  Whether or not it would be too much for 2.6
wasn't even on the table. The code had been tested and was ready but rejected -- because,
you said, the "kernel developers" would never accept it.  You proposed
a 2-stage process to Casey that lsm would first get it's head inside
the tent with hooks for the existing policies already in lsm, then
in the 2nd stage, you'd push for audit hooks.  I felt that the 2nd stage
would be pushed off until some vague, nebulous date, too far in the future to be of any use to SGI.  Casey disagreed and went
forward supporting you.
Over a year later, after going through contortions to get audit to work with
(in spite of?) lsm hooks by hooking all system calls (fulfilling Linus's stereotype of "stupid" designs) to get around lsm's
shortcomings, the 
project was shelved.  It had taken too long.  As for performance?  Even 
questions, about performance, were declared "off-limits".

> It has many nice properties, but is much more 
> invasive to the 
> kernel. 
---
	"More invasive".  Sorta like water is more invasive to our 
bodies than Helium.  Almost any security text will claim that security
has to be built in at the lowest levels -- even as far as designing it
in from the beginning to be successful.  You would expect good security
to _not_ be integral to a secure kernel?  


> I think it is a very interesting idea for 2.7, and should be 
> floated past the maintainers who will be impacted to see if it has a 
> hope in hell.
---
	I tried to float it past several maintainers in July 01 after
multiple people on the lsm list said they wouldn't consider it without
"pre-buyin" of the "kernel developers".  When I attempted to question
"them", a response to the question was reposted to the lkml.  You
complained to Casey who removed me from the project to mollify you in
hopes you would make good on your promises to include audit in the vague,
nebulous, "too-late", stage 2.

	You blew away a working implementation of a completely modular
security prototype because your first priority was to your specific
security policy -- not to what Linus had desired in having a "truly generic"
policy.  This type of bias, along with the considerable weight given
to the needs of SELinux (then the "darling" of linux security -- before
it was pointed out that it used privately held patents that would likely prohibit any commercial use of the security model) only
highlights problems when corporate and commercial interests are placed ahead of good design.

-l


	This

Re: [BK PATCH] LSM changes for 2.5.59

[David Wagner]

LA Walsh wrote:
>> >  Some security people were banned from the kernel
>> >devel. summit because their thoughts were deemed 
>> 'dangerous': fear was they
>> >were too persuasive about ideas that were deemed 'ignorant' and would
>> >fool those poor kernel lambs at the summit.
>
>> Internal SGI politics.
>
>	Nope... external -- the conference organizer was the one selecting and
>specifically disallowing certain attendees.  It
>appeared important to weed out anyone who didn't think like him.

I'm not sure that's relevant.  We discussed these issues at length on
the LSM mailing list months ago.  You had the opportunity (and took
it) to make the case for your proposal on the LSM mailing list, but in
the end, it was deemed not persuasive by most list members.  The LSM
mailing list came to rough consensus on the right technical decision.
I know you didn't like the outcome of that decision, but there were good
technical reasons for the decisions we made.  To say that you didn't
have a chance to present your ideas is a misrepresentation of the truth.

Part of distributed decision-making is conceding gracefully when the
consensus doesn't go your way.  We've all had to do this from time
to time.  In short, we've had this discussion already, and nothing has
changed since then.

Re: [BK PATCH] LSM changes for 2.5.59

[Bill Davidsen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 946 bytes --]

On Sun, 9 Feb 2003, Crispin Cowan wrote:

> And I actually like that plan. But I still believe it to be too radical 
> for 2.6. It has many nice properties, but is much more invasive to the 
> kernel. I think it is a very interesting idea for 2.7, and should be 
> floated past the maintainers who will be impacted to see if it has a 
> hope in hell.

Too radical? After the modules rewrite how could anything short of a
rewrite in another language be too radical. At least a unified set of
security hooks would be a feature which would be immediately useful and
easy to understand. The benefits of the module changes are not as obvious.

With MS pushing their own security initiative, which seems to be building
computers which only run their os, this would have been a really good
feature from a mindshare perspective. 

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

[-- Attachment #2: Type: APPLICATION/PGP-SIGNATURE, Size: 252 bytes --]

Re: [BK PATCH] LSM changes for 2.5.59

[Dave Jones]

On Mon, Feb 10, 2003 at 05:14:50PM -0500, Bill Davidsen wrote:

 > Too radical? After the modules rewrite how could anything short of a
 > rewrite in another language be too radical.

The modules rewrite highlighted a *lot* of bugs, which had nothing
to do with modules whatsoever. It was unfortunate for Rusty that his
work got merged the same time as a lot of other changes went in
which broke a lot of stuff (The cli/sti stuff springs to mind).
It also highlighted another bunch of bugs which were *real problems*
like using code marked __init after it was freed.

The "This doesn't compile, Rusty sucks" brigade then appeared,
not taking a second to realise that said driver was fscked regardless
of Rusty's code being merged.

Sure the modules rewrite wasn't painless, and like everything that
gets merged, there were bugs, but give the guy a break already.[1]
If there are still problems with modules, let Rusty know about it.
If not, please STFU already, its getting tiring hearing the same
old FUD.

		Dave

[1] Or would you prefer he renamed the firewall tools again? (SRustyCNR)

-- 
| Dave Jones.        http://www.codemonkey.org.uk

the modules problems

[Roman Zippel]

Hi,

On Tue, 11 Feb 2003, Dave Jones wrote:

>  > Too radical? After the modules rewrite how could anything short of a
>  > rewrite in another language be too radical.
> 
> The modules rewrite highlighted a *lot* of bugs, which had nothing
> to do with modules whatsoever. It was unfortunate for Rusty that his
> work got merged the same time as a lot of other changes went in
> which broke a lot of stuff (The cli/sti stuff springs to mind).
> It also highlighted another bunch of bugs which were *real problems*
> like using code marked __init after it was freed.

All this could have been done without a complete rewrite.

> The "This doesn't compile, Rusty sucks" brigade then appeared,
> not taking a second to realise that said driver was fscked regardless
> of Rusty's code being merged.
> 
> Sure the modules rewrite wasn't painless, and like everything that
> gets merged, there were bugs, but give the guy a break already.[1]
> If there are still problems with modules, let Rusty know about it.
> If not, please STFU already, its getting tiring hearing the same
> old FUD.

Dave, it's really not that simple. Sure, there were bugs misattributed to 
the modules rewrite, but these are usually easy to identify and can be 
forwarded to the right culprit.
This leaves us with the real module problems and the biggest is an 
unresponsive modules maintainer, when it comes to serious criticism. I'm 
not the only one, whose questions are ignored. Rusty somehow assumes 
nobody would understand his brilliant ideas (1), so we have to live 
"executive summaries" (2). Sorry, but this is fucking arrogant and this 
slowly really pisses me off.
The modules rewrite has some serious problems and so far I haven't found 
an explaination, how they will be addressed. Feel free to flame me if the 
solutions is so obvious that my little mind couldn't grasp it.
The biggest problem which doesn't let me look forward to 2.6 regarding 
modules are the user visible changes - the new module tools. Why wasn't it 
possible to update modutils? The new modprobe.conf is far less powerful 
and I don't really want to know what tricks distributions will come up 
with to keep modules.conf and modprobe.conf in sync.
request_module() is still broken, because modprobe/insmod does not 
synchronise multiple calls. The module tools are still experimental at 
best. I posted a patch to keep both tools working (no reaction of course).
I could go on with various other (serious) design problems, but I 
mentioned most of them already in other mails, again without any reaction 
from Rusty. I'd really like to know, why I'm not worth an answer anymore. 
I'd really like to help, but ignoring me doesn't solve anything, I 
wouldn't be that insistent, if I wouldn't see some real problems, I don't 
do this just to annoy Rusty. Either these problems are real, then they 
should be addressed somehow or I'm wrong, but then I'd like to know why 
and I had no problem to admit mistakes. If there are multiple possible 
solutions, we should at least consider all possible advantages/ 
disadvantages.
I'm really annoyed with this situation and if Rusty doesn't want to 
cooperate, I slowly think it's the best solution to just revert the whole 
mess and just port the few good things. The old module support isn't 
perfect, but at least we know its problems and can address them one by 
one.

bye, Roman

(1) http://marc.theaimsgroup.com/?l=linux-kernel&m=104440182324752&w=2
(2) http://marc.theaimsgroup.com/?l=linux-kernel&m=104261939523782&w=2

Re: [BK PATCH] LSM changes for 2.5.59

[Bill Davidsen]

On Tue, 11 Feb 2003, Dave Jones wrote:

> On Mon, Feb 10, 2003 at 05:14:50PM -0500, Bill Davidsen wrote:
> 
>  > Too radical? After the modules rewrite how could anything short of a
>  > rewrite in another language be too radical.
> 
> The modules rewrite highlighted a *lot* of bugs, which had nothing
> to do with modules whatsoever. It was unfortunate for Rusty that his
> work got merged the same time as a lot of other changes went in
> which broke a lot of stuff (The cli/sti stuff springs to mind).
> It also highlighted another bunch of bugs which were *real problems*
> like using code marked __init after it was freed.

I think I see a knee-jerk reaction here. I commented on the magnitude and
pervasiveness of the change, not the way it was done. I could write an
essay about the way it was done, but that wasn't what I was talking about,
just the low impact of lsm vs. modules.

I also mentioned that lsm would be an understandable major new feature,
encouraging a variety of applications (as iptables did for firewall
generators and load balancers). The new module code only gives rise to
busywork porting drivers and utilities to the new way of doing that same
old same old. If there's some neat new useful capability with modules I
must have missed that post. 

Yes, the idea that lsm is too radical to go into Linux does frost my ass,
and I'm not pretending it doesn't. But don't change the topic to "let's
not pick on Rusty," because I wasn't, at least in that post ;-)

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

side issues of baloney with that ham...(was LSM changes for 2.5.59)

[LA Walsh]

> > >  Some security people were banned from the kernel
> > >devel. summit because their thoughts were deemed 
> 'dangerous': fear was they
> > >were too persuasive about ideas that were deemed 
> 'ignorant' and would
> > >fool those poor kernel lambs at the summit.
> > >
> > Internal SGI politics.
---
	Actually...the above incident had nothing (to my knowledge)
to do with SGI politics but with Linux 'community' politics. However,
politics and Machiavelli have never been my forte (I tend to be too
straightforward/open), so in agreement with Mr. Schaufler, below, 
what would I know regarding such?

> Just a gentle reminder that Ms. Walsh is not an SGI employee
> and that any opinions she may express regarding the Linux
> development process are her own, and may not reflect the
> views or understandings of SGI or any other individuals
> involved.

In the same spirit, just a gentle reminder, Mr. Schaufler is a manager
at a commercial company that receives most of its revenue from IRIX
based machines.  His group recently released CAPP and LSPP approved 
versions (yeay!) of SGI's proprietary IRIX Operating System.  Given
the proven success of Trusted IRIX in the security market, his views 
and actions may not reflect the best interests of the Linux Security 
Community or any of the individuals involved.

My interest is that of a software designer who has been too interested
in product quality, design and performance and has been chastened
because such issues don't bring in revenue and are not commercial company 
goals. Anything effort above the  "_minimum_ needed to get by" was often
considered insubordinate and recalcitrant.  In a commercial company, 
capitalistically motivated, this is true.  Commercial giants in the 
software world have demonstrated that quality issues rate well below 
features and schedule.

> SGI is currently not
> active in this effort, and makes no claims regarding
> it's appropriateness to any particular purpose.
---
	Exactly.  :-)

-l