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. > 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. > 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. > 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). Nor would such an ability be desirable. Flask/SELinux can express a wide range of well-defined security models. > (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. > 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. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 11:13:18 PDT