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