Re: New stacker performance results

From: Casey Schaufler (casey@schaufler-ca.com)
Date: Wed May 25 2005 - 15:16:06 PDT


--- Stephen Smalley <sds@private> wrote:
> On Wed, 2005-05-25 at 10:29 -0700, Casey Schaufler
> wrote:
> > The introductory paragraph is used in this case
> > to set the stage for the upcoming argument.
> 
> Except that it wasn't supportive of the upcoming
> argument AFAICS, i.e.
> combining add-on modules with security
> implementations considered
> harmful.  With which I would agree.  A robust
> security implementation by
> nature has to be tightly integrated into the kernel,
> and userspace can't
> cope with arbitrary security models being plugged
> into the kernel.

But... but... Then, you go on to extoll the
virtues of SELinux as a mechanism to implement
that very thing!

> > I refer you to the message archives for this list.
> > Look up "authoritative hooks".
> 
> The hooks, whether authoritative or restrictive, are
> only a small part
> of the security implementation; they just expose the
> kernel abstractions
> and operations to the security module.  You still
> have to implement a
> real security architecture in the "module", which is
> what Flask/SELinux
> provides.

See?!?
 
> > Perhaps. I understand the general notion that
> > it's easier to write in PERL than C. Does that
> > mean the overhead of PERL is worth the cost?
> > I suggest that in many cases it is not.
> 
> If you weren't going to leverage anything provided
> to you by the perl
> runtime, then that would make sense.  But you are
> going to have to
> reinvent a lot of what SELinux already does to
> implement any access
> control scheme.  

No. You are going to have to do what your policy
requires. You may well not need all the tools
and utilities required by SELinux.
 
> > Ah, but such is nonetheless necessary. For LSM
> > the complete, general, and arbitrary description
> > is not only possible, but reasonably strait
> forward.
> 
> Nonsense, LSM cannot express arbitrary policies; it
> is limited by its
> interface (the set of hooks, their interfaces, and
> their placement).

In this, I disagree, having used similar mechanisms
elsewhere to do whatever I <adjective> well pleased.

> Nor would such an ability be desirable. 

Bah! (Waves paw)

> Flask/SELinux can express a
> wide range of well-defined security models.

Yes, we know.

> > (No, I do not intend to write it. Had LSM gone
> with
> > Authoritative hook I'd already have provided it.)
> 
> Right.  Pass the pipe, please.

Ooh! Ooh! Thems fight'n words!
I'll buy you a beer instead. Then we can
really get the debate flowing...
     "Type Enforcement!"
     "Authoritative Hooks!"
     ....
 
> > For SELinux I expect no less if y'all want it to
> > replace LSM as the "general" advanced security
> > interface.
> 
> Then you don't understand at all.  Generality for
> the sake of generality
> is not desirable and is particularly not well
> received in the kernel -
> see SubmittingPatches #4.

SELinux should replace LSM because it's NOT general?

EGADS
      Concept fails the principle of least 
      astonishment.



Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/



This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 15:18:10 PDT