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

[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

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

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.

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

[Mika Kukkonen]

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

Ericsson's project is called DSI (http://www.risq.ericsson.ca/dsi/), and
the code is at SourceForge: http://sourceforge.net/projects/disec/.

CGL v2 specs will incorporate some parts of DSI, but not the whole.

--MiKu

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

Re: [BK PATCH] LSM changes for 2.5.59

[Pete Loscocco]

Alan Cox wrote:
> 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. 

Despite recent speculation concerning patents, we remain confident that
we had the necessary rights to release SELinux in the manner and under
the conditions in which we did and that SELinux may be used, copied,
distributed, and modified in accordance with the terms and conditions of
the GPL.

--
Peter Loscocco
SELinux Project Leader
National Security Agency

RE: [BK PATCH] LSM changes for 2.5.59

[LA Walsh]

> From: David Wagner
> LA Walsh wrote:
> >	Maybe I'm delusional, but you are contradicting yourself.  In
> >common terms, this is called lying.
> 
> No, he's not; even if he were, no, it's not.  Can't we do
> without the personal attacks and just stick to technical topics?
---
	I'm sorry if you feel it was a personal attack.  It seemed
the appropriate noun for someone to whom this discrepancy in charter
has been pointed out to before and who worked to silence those
pointing out the discrepancy in public.

	That cast it into the light of deliberate conflicting statements
which I used the common word "lie", but perhaps more politically
correct would have been to say that I was confused by the apparent
contradiction of the two statements.  

	One says 'simple'/'generic', the other says 'access checks only
as implemented as patches on top of the questionable and vague
policies that already exist.  One deliberate design decision was to
make the hooks "non-authoritative" which makes the resulting
security policies as clean and easy to read as mud.  It also made
writing a clean/simple security policy impossible, with "kludges"
suggested like "well just always override DAC checks with priviledges"
and then do the real checks in the 'restrictive-only' LSM calls.

	Please explain to me how this is simple or generic.

	It's completely inappropriate for a security structure where
increased complexity yields increased failure and lower ability
to prove (confidence).


> >	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.  
> 
> People keep telling you that LSM does have a careful design for
> security.  I suspect what you really mean is that you don't like
> the design we chose -- but that's different.
---
	Please read what I said carefully.  I didn't say that the 
"patched on security" wasn't carefully designed.  I made no claims
about how carefully it was designed.  Carefulness of design avails
you not, if the design isn't appropriate for the problem space.

-l

RE: [BK PATCH] LSM changes for 2.5.59

[Stephen D. Smalley]

Linda Walsh wrote:
> 	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.  

Could this possibly be a result of the above being a fundamentally
flawed security model?  Not to mention it being primarily an auditing
model rather than a real access control model.  It also seems a bit
problematic regardless of your kernel security framework; what does
"logging cannot continue" truly mean?  Do you have to verify that the
log record made it to disk before you can proceed with the operation?

<insane ranting about evil conspiracies ignored>

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

The capabilities logic was moved into a module, and you have the option
of building a kernel with traditional superuser logic (dummy security
module) rather than capabilities.  It is true that the capability bits
haven't yet been moved into the opaque security field, as explained in
the documentation, but this can be changed if desired (but there are
consequences to such a change; see the discussion in lsm.tmpl) .  It is
also true that the capable() calls haven't been moved, but there is
little to be gained by it except possibly where there is a
corresponding LSM hook, and that is a straightforward refinement of the
existing LSM patch.

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

An auditing issue, not an access control issue.  As previously
discussed, there is no channel as long as both checks return the
same error (and doing otherwise is a compatibility problem).

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

1991? I don't think so.  But feel free to point people to your patch if
you like.  Moving all of the DAC logic into a module is _not_ necessary
to add support for strong access controls.  And modularizing that logic
has interesting implications; what happens to your applications when
you turn off the kernel DAC logic and replace it with something
arbitrary?  

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

RE: [BK PATCH] LSM changes for 2.5.59

[LA Walsh]

> From: Stephen D. Smalley [mailto:sds@epoch.ncsc.mil] 
> Linda Walsh wrote:
> > 	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.  
> 
> Could this possibly be a result of the above being a fundamentally
> flawed security model? 
---
	Perhaps you should discuss this with your employer, since it
was the DoD and NSA that came up with the policy.  


> Not to mention it being primarily an auditing
> model rather than a real access control model.  It also seems a bit
> problematic regardless of your kernel security framework; what does
> "logging cannot continue" truly mean? 
---
	For someone working in security, I'm surprised you aren't familiar
with the Controlled Access Protection Profile (CAPP).  It's a superset of
the old DoD "Orange Book" "C2" standard. 
 
	The above policy, which you say isn't a "real access control model"
falls under the "Controlled Access" PP's definition of Access Control.
Are you saying the CAPP isn't "really" an Access Control specification for
an OS?  It is onthe "Common Criteria's" OS list 
(http://www.commoncriteria.org/ccc/protection_profiles/ppinfo.jsp?id=4&status=Certified).  
	Of course if 15-country recognition isn't enough, there's your  employer's own Trusted Product page
(http://www.radium.ncsc.mil/tpep/).  
The CAPP specifies detail used in evaluating whether or not one "truly" 
meets the requirement. Maybe you can find someone around where 
you work who is more familiar with CC security evaluations who can
give you more information.


> Do you have to verify that the
> log record made it to disk before you can proceed with the operation?
---
	I'll refer you to section 5.1 of the above document. It describes 
the required audit policies, one of which, includes the _option_ of 
stopping the machine.

	Is it fundamentally flawed security for a bank to have an ATM shut down if it can no longer log or record transactions?


> <insane ranting about evil conspiracies ignored>
---
	<we don't like what she is saying...quick, call her a witch, a 
heretic, lets portray her as, bwahaha, i-n-s-a-n-e!>  "Evil?"  I don't
recall that word.  I'm fuzzy on the whole good-evil thing.  Whattya mean 'evil?'



> > 	Also unsupported: The "no-security" model -- where all security 
> > is thrown out (to save memory space and cycles) that was 
> desired for embedded 
> work.
> 
> The capabilities logic was moved into a module, and you have 
> the option
> of building a kernel with traditional superuser logic (dummy security
> module) rather than capabilities.
---
	Geez...am I the only one who sees SuperUser and DAC as security
models?  Maybe <eyes grow maniacally wild>, I really am i-n-s-a-n-e...



> An auditing issue, not an access control issue.  
---
	So you are asking us to believe, for example, that bank transaction
logs have nothing to do with bank or account security.  That in no way do
such logs/records provide any sort of control on access?  I disagree.


> As previously
> discussed, there is no channel as long as both checks return the
> same error (and doing otherwise is a compatibility problem).
---
	No channel?  Who's talking about channels?  Did I mention channels?
Nep.  I have my Intrusion Detection system set to go off only on 
mandatory policy violations.  I don't care about penny-ante DAC violations,
they are a dime a dozen, but attempts to override mandatory constraints?
That's suspicious on my machine.  I'd like to know exactly what you 
were trying to do when you attempted to open /usr/sbin for write. 

 

>  Moving all of the DAC logic into a module is _not_ necessary
> to add support for strong access controls.  
---
	Neither is electricity.  Lock the computer in a vault, encase it
in 50 feet of concrete!  *Way* secure.  Oh...you want it to be
'usable'?  Maybe we want to make the system a bit more accessible and
configurable?



> And modularizing that logic
> has interesting implications; what happens to your applications when
> you turn off the kernel DAC logic and replace it with something
> arbitrary?  
---
	You tell me.  The idea is configurability: "truly generic".  It 
depends on what policy you define.  I'm not about to guess
what would happen to "applications" (which?  Random?) that _you_ put on 
your own system that has a security policy that _you_ define.

Re: [BK PATCH] LSM changes for 2.5.59

[Stephen D. Smalley]

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.

It is true that SELinux is not yet in mergeable shape, but we do intend
to address those issues.  With regard to additional patches, SELinux
has at times diverged slightly from the main LSM patch, but we do feed
back changes.  At present, the only significant change in the
additional patch has to do with early initialization of SELinux so that
we can properly set up the security state of kernel objects when they
are created rather than needing to retroactively set up the state of
objects created before module initialization.  That issue has come up
in general for security modules on the LSM list, and we would need to
submit a general solution for it along with the submission of SELinux
for mainline.  Hence, you are correct that there is work to be done
before SELinux can be merged, but you are wrong to assume that we do
not intend to do that work or to submit SELinux.

> 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 assume that you mean "SELinux" above.  It is true that SELinux is the
dominant user of the LSM hooks at present.  We would have been happy to
submit SELinux as a direct kernel patch rather than adding a further
level of indirection via LSM, but that wasn't the guidance we were
given.

> 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)?  Some of the necessary changes are simply engineering issues, but
others require further dialogue, e.g. getting the API into an
acceptable form, revisiting the approaches used to label and control
access to pseudo filesystems.

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

We would have preferred this route as well, but again it wasn't the
guidance that we were given.  We were told to work on something
LSM-like, then told to wait to initially submit it until after certain
other changes went into 2.5.

> 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!).

Leaving 2.6 with no infrastructure for access control extensions at all?
Is this really preferable to keeping LSM in 2.5/2.6, and then migrating
to a more directly integrated architecture in 2.7?
 
--
Stephen Smalley, NSA
sds@epoch.ncsc.mil

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

On Mon, Feb 10, 2003 at 11:55:41AM -0500, Stephen D. Smalley 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.
> 
> back changes.  At present, the only significant change in the
> additional patch has to do with early initialization of SELinux so that
> we can properly set up the security state of kernel objects when they
> are created rather than needing to retroactively set up the state of
> objects created before module initialization.

And that for examples is a very important and needed change.  Security
modules as loadable modules are a bad idea as you don't have a consistand
labelling state - just look at the older selinux versions with all the
precondition mess.  But it should be generalized to a new initcall level
instead of the current explicit call to the selinux routine..

> > 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 assume that you mean "SELinux" above.

Yes, sorry.

> It is true that SELinux is the
> dominant user of the LSM hooks at present.  We would have been happy to
> submit SELinux as a direct kernel patch rather than adding a further
> level of indirection via LSM, but that wasn't the guidance we were
> given.

The problem is not really the indirection but the submission of the
indirection without it's users.

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

Unfortunately I don't decide about the linux 2.6 freeze - ask Linus.

> Some of the necessary changes are simply engineering issues, but
> others require further dialogue, e.g. getting the API into an
> acceptable form, revisiting the approaches used to label and control
> access to pseudo filesystems.

+ moving to extended attributes instead of magic files for storing the
  labels on filesystems
+ getting the patent issue sorted out

> Leaving 2.6 with no infrastructure for access control extensions at all?
> Is this really preferable to keeping LSM in 2.5/2.6, and then migrating
> to a more directly integrated architecture in 2.7?

Personally I prefer to not have infrastructure in over having broken
infrastructure.  Looks at what the devfs mess caused in 2.4 and how much
was removed or is beeing removed/rewritten again in 2.5.  Life would have
been a lot simpler if it never got in during 2.4.  Similarly I don't see the
problem why the current lsm users can't keep using patches during 2.6.

Re: [BK PATCH] LSM changes for 2.5.59

[Chris Wright]

* Christoph Hellwig (hch@infradead.org) wrote:
> 
> And that for examples is a very important and needed change.  Security
> modules as loadable modules are a bad idea as you don't have a consistand
> labelling state - just look at the older selinux versions with all the
> precondition mess.  But it should be generalized to a new initcall level
> instead of the current explicit call to the selinux routine..

I wrote such a patch last summer.  I'll rebase it to current and post it
(most likely when i return from .se).  It needs to be separte from
normal initcalls since they all happen too late.
-chris

Re: [BK PATCH] LSM changes for 2.5.59

[Stephen D. Smalley]

Mark Hahn wrote:
> can all this LSM nonsese be CONFIG'ed out of the kernel as promised?

Yes.  CONFIG_SECURITY=n makes it all go away.  But if your mind isn't
completely closed on the topic, you might want to read some of the
following published papers before concluding that it is nonsense:

1) The Inevitability of Failure:  The Flawed Assumption of Security in
Modern Computing Environments, available online from
http://www.nsa.gov/selinux/inevit-abs.html.

2) The published papers about SELinux from the 2001 FREENIX and 2001
OLS, available online from http://www.nsa.gov/selinux/docs.html.

3) The published papers about LSM from the 2002 Usenix Security and
2002 OLS, available online from http://lsm.immunix.org/lsm_doc.html.

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

Re: [BK PATCH] LSM changes for 2.5.59

[Stephen D. Smalley]

Christoph Hellwig wrote:
> Yes, and exactly that's the whole point of it!  The problem with LSM
> is that it tries to be overly flexible and thus adds random hooks that
> expose internal details all over the place.  Just stop that silly no policy
> approach and life will get a lot simpler.  There's no reason to implement
> everything and a kitchen sink in LSM.

The sysctl hook simply provides a way for a security module to
implement a security check for access to sysctl variables.  It provides
a classic kernel object (ctl_table) x operation interface, with the
subject implicitly passed via current, just like permission() for
inodes.  A security module can leave the hook unimplemented (no
restrictions beyond DAC), or implement a purely process-based
restriction or implement fine-grained controls to individual sysctls.
Sysctls are already exposed to userspace via sysctl(2) and/or
/proc/sys, so I'm not sure what the concern is there.  Nothing
complicated here.

As to your argument about LSM's flexibility, LSM simply followed the
guidance on what would be accepted into 2.5.  The original
SELinux/Flask architecture was more tightly integrated and had
well-defined boundaries while still providing substantial flexibility,
but the response to the SELinux presentation was to move towards
something more like LSM.  Seems pointless to argue about it now, except
as suggestions for future directions for LSM in 2.7.

> If you need attributes attached to the sysctl nodes just diable sysctl by
> number and use the existing filesystem based hooks.

Sorry, I don't see why this is preferable to implementing a single
security hook in ctl_perm that is invoked for both sysctl(2) and
/proc/sys access, providing a consistent access control regardless of
the interface.  Your approach is more prone to vulnerability (failing to
disable the sysctl(2) interface), and breaking application compatibility.

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

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

On Wed, Feb 05, 2003 at 11:47:05AM -0500, Stephen D. Smalley wrote:
> a classic kernel object (ctl_table) x operation interface, with the
> subject implicitly passed via current, just like permission() for
> inodes.  A security module can leave the hook unimplemented (no
> restrictions beyond DAC), or implement a purely process-based
> restriction or implement fine-grained controls to individual sysctls.
> Sysctls are already exposed to userspace via sysctl(2) and/or
> /proc/sys, so I'm not sure what the concern is there.  Nothing
> complicated here.

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

> 
> As to your argument about LSM's flexibility, LSM simply followed the
> guidance on what would be accepted into 2.5.  The original
> SELinux/Flask architecture was more tightly integrated and had
> well-defined boundaries while still providing substantial flexibility,
> but the response to the SELinux presentation was to move towards
> something more like LSM.  Seems pointless to argue about it now, except
> as suggestions for future directions for LSM in 2.7.

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.

Yes, I'm pissed that we get this crap all over the place, making code
harder to follow and that without any actual benefit to the mainline tree.

Please come up with something better for 2.7 and leave 2.5 alone, this will
help anyone.

Re: [BK PATCH] LSM changes for 2.5.59

[Greg KH]

On Wed, Feb 05, 2003 at 04:49:48PM +0000, Christoph Hellwig wrote:
> 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.

I'm tired of reading this crap every time I submit a LSM patch.

I'll say it for the last time...  LSM was designed and didn't just plop
into existence.  The group has published numerous design documents both
explaining the decisions and rational behind the design and
implementation of the project.  They are available at lsm.immunix.org,
as you probably already know.  I know you don't like the implementation
we currently have, but as no one has stepped up with a different
implementation, that has been designed and tested to work for an
extremely wide range of different security models, I suggest you stop
this kind of attack.

However, concrete criticism of specific implementation details, like you
have done in the past is welcome, and encouraged.  I'll look into your
comment about coding style issues that you mentioned earlier in this
thread.

> You still haven't even submitted a single example that actually uses
> LSM into mainline.

Um, what's security/root_plug.c then?  :)

greg k-h

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

On Wed, Feb 05, 2003 at 02:07:55PM -0800, Greg KH wrote:
> On Wed, Feb 05, 2003 at 04:49:48PM +0000, Christoph Hellwig wrote:
> > 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.
> 
> I'm tired of reading this crap every time I submit a LSM patch.

And I'm tired of this hooks creaping all over the kernel like a cancer...

> I'll say it for the last time...  LSM was designed and didn't just plop
> into existence.  The group has published numerous design documents both
> explaining the decisions and rational behind the design and
> implementation of the project.  They are available at lsm.immunix.org,
> as you probably already know.  I know you don't like the implementation
> we currently have, but as no one has stepped up with a different
> implementation, that has been designed and tested to work for an
> extremely wide range of different security models, I suggest you stop
> this kind of attack.

Sorry, but I care for the Linux kernel and think adding this stuff all
over the place will not help us in the long term.  In fact I'm pretty sure
that > C2 grade security in a general purpose Operating System is a really
bad idea.  My first choice as a replacement would be throwing it out
of the kernel entirely.  As for less invasive and more though out design
if for whatever reason we still need to keep this we had tons of discussion
here on the lists and on irc.

The main point is that LSM in the current shape, with every single policy
detail left to the modules (compare that say to the linux filesystem code
where we have lots of very different filesystems and still have as much as
possible policy decision in the core code, this is one of the really strong
points of Linux!) is a very bad idea and I _really_ don't want to see
it in the next major stable release.

And no, I don't complain on every single patch, just those that are overly
ugly.

> > You still haven't even submitted a single example that actually uses
> > LSM into mainline.
> 
> Um, what's security/root_plug.c then?  :)

It's a small hack.  But if you think it's representative for LSM I'm
fine with that and I'll submit a patch removing every hook except of
the single one actually used by it.

Re: [BK PATCH] LSM changes for 2.5.59

[Russell Coker]

On Wed, 5 Feb 2003 23:30, Christoph Hellwig wrote:
> The main point is that LSM in the current shape, with every single policy
> detail left to the modules (compare that say to the linux filesystem code
> where we have lots of very different filesystems and still have as much as
> possible policy decision in the core code, this is one of the really strong
> points of Linux!) is a very bad idea and I _really_ don't want to see
> it in the next major stable release.

My understanding is that LSM was created at the request of Linus because there 
were several groups of people who had different patches for security policy 
in "core code".  Linus apparently didn't like that idea and requested a 
framework so that Linux would not be tied to one particular security model.  
Someone please correct me if my understanding of LSM history is incorrect.

Now as for the issue of code to use the hooks, SE Linux uses almost all the 
hooks and I'm sure that Steve can send in the appropriate patch at any 
time...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

On Wed, Feb 05, 2003 at 11:39:46PM +0100, Russell Coker wrote:
> Now as for the issue of code to use the hooks, SE Linux uses almost all the 
> hooks and I'm sure that Steve can send in the appropriate patch at any 
> time...

Of course he could send it.  Whether it has a chance of beeing accepted
is an entirely different question, though..

Re: [BK PATCH] LSM changes for 2.5.59

[Stephen D. Smalley]

Christoph Hellwig wrote:
> Of course that needs further changes!
> 
> (a) actually implement that field, and
> (b) change the prototype of the hook to int (*sysctl)(int op, enum sensitivity);

No.  If one were to add such a field, then it would be accessible
through the ctl_table structure that is already passed to the hook.
You would not replace the ctl_table parameter with the kernel's
sensitivity hint, since the security module must be able to make its
own determination as to the protection requirements based on its
particular security model and attributes.  If you only pass the
kernel's view of the sensitivity, then you are hardcoding a specific
policy into the kernel and severely limiting the flexibility of the
security module.  Since the kernel's hint is necessarily independent of
any particular security model/attributes, it will only provide a
coarse-grained partitioning, e.g. you are unlikely to be able to
uniquely distinguish the modprobe variable if you want to specifically
limit a particular process to modifying it.  The existing hook
interface does not need to change.

Implementing a sensitivity hint field in the ctl_table structure would
be trivial, but determining a set of policy-neutral hint values that
capture important confidentiality, integrity, and functional
characteristics and mapping the existing set of sysctl variables to
those hint values is a longer term task.  The hook provides useful
functionality now, apart from such hints, and should not need to wait
on them.  In the short term, there may be a certain amount of
duplication of information among security modules regarding sensitive
sysctl variables, but that information can actually help to feed back
into the process of determining the right general set of hint values
necessary to support multiple security models and the mappings for
the existing sysctl variables.

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

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

On Wed, Feb 05, 2003 at 10:00:23AM -0500, Stephen D. Smalley wrote:
> No.  If one were to add such a field, then it would be accessible
> through the ctl_table structure that is already passed to the hook.

It would.  But it shouldn't be passed in for the first time.

> You would not replace the ctl_table parameter with the kernel's
> sensitivity hint, since the security module must be able to make its
> own determination as to the protection requirements based on its
> particular security model and attributes.  If you only pass the
> kernel's view of the sensitivity, then you are hardcoding a specific
> policy into the kernel and severely limiting the flexibility of the
> security module.

Yes, and exactly that's the whole point of it!  The problem with LSM
is that it tries to be overly flexible and thus adds random hooks that
expose internal details all over the place.  Just stop that silly no policy
approach and life will get a lot simpler.  There's no reason to implement
everything and a kitchen sink in LSM.

Since the kernel's hint is necessarily independent of
> any particular security model/attributes, it will only provide a
> coarse-grained partitioning, e.g. you are unlikely to be able to
> uniquely distinguish the modprobe variable if you want to specifically
> limit a particular process to modifying it.  The existing hook
> interface does not need to change.

If you need attributes attached to the sysctl nodes just diable sysctl by
number and use the existing filesystem based hooks.

Re: [BK PATCH] LSM changes for 2.5.59

[Mark Hahn]

> No.  If one were to add such a field, then it would be accessible
> through the ctl_table structure that is already passed to the hook.
> You would not replace the ctl_table parameter with the kernel's
> sensitivity hint, since the security module must be able to make its

can all this LSM nonsese be CONFIG'ed out of the kernel as promised?

Re: [BK PATCH] LSM changes for 2.5.59

[Stephen D. Smalley]

Christoph Hellwig wrote:
> I still don't see the issue of each LSM module having to duplicate the list
> of sysctls beeing addressed.  Coul you please work something out for that
> before sending it for inclusion?

I already responded to this concern in
http://marc.theaimsgroup.com/?l=linux-kernel&m=104316038729345&w=2 and
http://marc.theaimsgroup.com/?l=linux-security-module&m=104316278400987&w=2.
At most, a field might be added to the ctl_table structure so that the kernel
can provide a hint to security modules as to its view of the sensitivity of
a given sysctl variable, but this does not require any change to the sysctl
hook interface.

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

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

On Wed, Feb 05, 2003 at 08:45:16AM -0500, Stephen D. Smalley wrote:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=104316038729345&w=2 and
> http://marc.theaimsgroup.com/?l=linux-security-module&m=104316278400987&w=2.
> At most, a field might be added to the ctl_table structure so that the kernel
> can provide a hint to security modules as to its view of the sensitivity of
> a given sysctl variable, but this does not require any change to the sysctl
> hook interface.

Of course that needs further changes!

(a) actually implement that field, and
(b) change the prototype of the hook to int (*sysctl)(int op, enum sensitivity);

[BK PATCH] LSM changes for 2.5.59

[Greg KH]

Hi,

These changesets include some new LSM hooks, all of which have been sent
to lkml with no dissenting comments.  Some of these hooks are the same
ones I sent for 2.5.58, but were not picked up.  These include hooks for
syslog and sysctl, restores some previously lost hooks, and reworked the
hooks for the security structures for private files.

Please pull from:  bk://lsm.bkbits.net/linus-2.5

thanks,

greg k-h


 fs/dcache.c              |    6 +++
 fs/exportfs/expfs.c      |    5 +--
 fs/file_table.c          |   35 +++++++++++++++++------
 fs/namei.c               |   18 +++--------
 fs/nfsd/vfs.c            |    9 +----
 fs/super.c               |   16 ++++++++++
 include/linux/fs.h       |   10 +++++-
 include/linux/security.h |   71 +++++++++++++++++++++++++++++++++++++----------
 kernel/ksyms.c           |    6 ++-
 kernel/printk.c          |    7 +++-
 kernel/sys.c             |   21 ++++++++++---
 kernel/sysctl.c          |    5 +++
 security/capability.c    |   10 ++++++
 security/dummy.c         |   33 +++++++++++++++++----
 14 files changed, 191 insertions(+), 61 deletions(-)
-----

ChangeSet@1.984, 2003-02-05 14:37:12+11:00, sds@epoch.ncsc.mil
  [PATCH] LSM: Add LSM syslog hook to 2.5.59
  
  This patch adds the LSM security_syslog hook for controlling the
  syslog(2) interface relative to 2.5.59 plus the previously posted
  security_sysctl patch.  In response to earlier comments by Christoph,
  the existing capability check for syslog(2) is moved into the
  capability security module hook function, and a corresponding dummy
  security module hook function is defined that provides traditional
  superuser behavior.  The LSM hook is placed in do_syslog rather than
  sys_syslog so that it is called when either the system call interface
  or the /proc/kmsg interface is used.  SELinux uses this hook to
  control access to the kernel message ring and to the console log
  level.

 include/linux/security.h |   18 ++++++++++++++++++
 kernel/printk.c          |    7 +++++--
 security/capability.c    |   10 ++++++++++
 security/dummy.c         |    8 ++++++++
 4 files changed, 41 insertions(+), 2 deletions(-)
------

ChangeSet@1.983, 2003-02-05 14:32:08+11:00, sds@epoch.ncsc.mil
  [PATCH] LSM: Add LSM sysctl hook to 2.5.59
  
  This patch adds a LSM sysctl hook for controlling access to
  sysctl variables to 2.5.59, split out from the lsm-2.5 BitKeeper tree.
  SELinux uses this hook to control such accesses in accordance with the
  security policy configuration.

 include/linux/security.h |   17 +++++++++++++++++
 kernel/sysctl.c          |    5 +++++
 security/dummy.c         |    6 ++++++
 3 files changed, 28 insertions(+)
------

ChangeSet@1.982, 2003-02-04 15:07:23-08:00, gregkh@kernel.bkbits.net
  Merge bk://lsm.bkbits.net/linus-2.5
  into kernel.bkbits.net:/home/gregkh/linux/lsm-2.5

 fs/dcache.c        |    3 +++
 fs/namei.c         |    9 +++------
 fs/super.c         |    8 ++++++++
 include/linux/fs.h |    5 ++++-
 kernel/ksyms.c     |    3 ++-
 5 files changed, 20 insertions(+), 8 deletions(-)
------

ChangeSet@1.952.1.4, 2003-01-16 14:54:42-08:00, sds@epoch.ncsc.mil
  [PATCH] Restore LSM hook calls to setpriority and setpgid
  
  This patch restores the LSM hook calls in setpriority and setpgid to
  2.5.58.  These hooks were previously added as of 2.5.27, but the hook
  calls were subsequently lost as a result of other changes to the code
  as of 2.5.37.
  
  Ingo has signed off on this patch, and no one else has objected.

 kernel/sys.c |   21 ++++++++++++++++-----
 1 files changed, 16 insertions(+), 5 deletions(-)
------

ChangeSet@1.952.1.3, 2003-01-16 14:35:24-08:00, sds@epoch.ncsc.mil
  [PATCH] allocate and free security structures for private files
  
  This patch adds a security_file_alloc call to init_private_file and
  creates a close_private_file function to encapsulate the release of
  private file structures.  These changes ensure that security
  structures for private files will be allocated and freed
  appropriately.  Per Andi Kleen's comments, the patch also renames
  init_private_file to open_private_file to force updating of all
  callers, since they will also need to be updated to use
  close_private_file to avoid a leak of the security structure.  Per
  Christoph Hellwig's comments, the patch also replaces the 'mode'
  argument with a 'flags' argument, computing the f_mode from the flags,
  and it explicitly tests f_op prior to dereferencing, as in
  dentry_open().

 fs/exportfs/expfs.c |    5 ++---
 fs/file_table.c     |   35 +++++++++++++++++++++++++++--------
 fs/nfsd/vfs.c       |    9 +++------
 include/linux/fs.h  |    5 ++++-
 kernel/ksyms.c      |    3 ++-
 5 files changed, 38 insertions(+), 19 deletions(-)
------

ChangeSet@1.952.1.2, 2003-01-16 14:23:59-08:00, sds@epoch.ncsc.mil
  [PATCH] Replace inode_post_lookup hook with d_instantiate hook
  
  This patch removes the security_inode_post_lookup hook entirely and
  adds a security_d_instantiate hook call to the d_instantiate function
  and the d_splice_alias function.  The inode_post_lookup hook was
  subject to races since the inode is already accessible through the
  dcache before it is called, didn't handle filesystems that directly
  populate the dcache, and wasn't always called in the desired context
  (e.g. for pipe, shmem, and devpts inodes).  The d_instantiate hook
  enables initialization of the inode security information.  This hook
  is used by SELinux and by DTE to setup the inode security state, and
  eliminated the need for the inode_precondition function in SELinux.

 fs/dcache.c              |    3 +++
 fs/namei.c               |    9 +++------
 include/linux/security.h |   25 ++++++++++---------------
 security/dummy.c         |   13 +++++++------
 4 files changed, 23 insertions(+), 27 deletions(-)
------

ChangeSet@1.952.1.1, 2003-01-16 14:18:05-08:00, sds@epoch.ncsc.mil
  [PATCH] Add LSM hook to do_kern_mount
  
  This patch adds a security_sb_kern_mount hook call to the do_kern_mount
  function.  This hook enables initialization of the superblock security
  information of all superblock objects.  Placing a hook in do_kern_mount
  was originally suggested by Al Viro.  This hook is used by SELinux to
  setup the superblock security state and eliminated the need for the
  superblock_precondition function.

 fs/super.c               |    8 ++++++++
 include/linux/security.h |   11 +++++++++++
 security/dummy.c         |    6 ++++++
 3 files changed, 25 insertions(+)
------

Re: [BK PATCH] LSM changes for 2.5.59

[Christoph Hellwig]

On Tue, Feb 04, 2003 at 08:15:38PM -0800, Greg KH wrote:
> Hi,
> 
> These changesets include some new LSM hooks, all of which have been sent
> to lkml with no dissenting comments.  Some of these hooks are the same
> ones I sent for 2.5.58, but were not picked up.  These include hooks for
> syslog and sysctl, restores some previously lost hooks, and reworked the
> hooks for the security structures for private files.

I still don't see the issue of each LSM module having to duplicate the list
of sysctls beeing addressed.  Coul you please work something out for that
before sending it for inclusion?