On Fri, 13 Jul 2001, Chris Wright wrote: > * jmjonesat_private (jmjonesat_private) wrote: > > On Fri, 13 Jul 2001, Crispin Cowan wrote: > > > > > As I understand Shane's original request, it is to get away from the > > > UNIX all-or-nothing "root" security model, without totally throwing away > > > UNIX. > > > > It seems to me that this is most easily done with a wrapper application > > that setuid's root then drops all privs but the necessary ones based on > > some policy. Of course, this goes to the granularity of the ability to > > drop privs. At this point in history, the granularity is not too fine. > > > > Heaven help the person who is using a setuid wrapper that has "holes." > > > > A permissive interface, right now, is a big leap. I agree (after > > significant consideration) that the "restrictive-only" case is the best > > way to proceed FIRST, but am somewhat concerned about the implication > > that other security strategies will never be tackled. > > > > Going back to one of my previous suggestions: wouldn't it still be fairly > > simple and useful to move > > > > security_ops-> > > > > to > > > > security_ops->restrictive-> > > > > and allow other submissions for potential > > > > security_ops->permissive_ops-> > > or even > > security_ops->authoritative_ops-> > > i don't see that this buys us anything. we know we have divided policy > decisions into these camps. placing blank placeholders don't seem to > add any value. let's get something working with the work we have done. > the trick, as i'm sure you already know, is not adding the hook to the > interface, but placing it in the kernel. we have enough work placing > the hooks we have identified now. focus...capabilities gives us > guidance (and placement) for permissive hooks. all new hooks are > restrictive, and geared towards access control of kernel objects. to > this end we should be looking for kernel objects that are not covered > and hook placements that are incomplete or buggy... [ Lost Cause Argument ] it buys us more minds working toward the ultimate end of Linux Security within the LSM framework, I believe. Admittedly, it does cost us something also: more argument with the Kernel Developers. If the consensus seems to be that the cost outweighs the benefit... so be it. > > we will have a much more convincing story that we are competent when we > have implemented the hook set that we are focused on right now, and have > some security modules working with it. This is true, although the restrictive-only hook set seems most arguable and, therefore, has some benefit above and beyond what we minimally need, imho. Leveraging that against some things that are "useful but not so arguable" seems indicated. If the KD's are going to buy into our idea, here, it would seem valuable to "pre-sell" Stage II. > > > > > hooks in the future... perhaps after the original set of restrictive hooks > > is accepted into the kernel, > > > > Also, along these lines, move all capabilty-specific functions to > > > > security_ops->capabily_ops-> > > and security_ops->SELinux_ops-> > and security_ops->Janus_ops-> > and security_ops->LIDS_ops-> > and security_ops->SubDomain_ops-> > > i disagree with this approach. Well, perhaps "security_ops->vendor" has some value. There WILL be implementation specific hooks, I think, patched in the kernel. The "mimimalist" concept we're following virtually guarantees it. If not, then we're inhibitting innovation, or sealing the fate of LSM in the long term as being "antiquated." By encompassing that realization in LSM, we create a "track" for vendor specific patches to enter our system and move toward eventual acceptance in the core interface. Not strictly functional, but arguable in a general sense. security_ops->capability is "core", so I don't see the direct relationship. The concept is to "synthesize" numerous needs into a common interface. To do that, we have to pay some homage to those needs as they arise... as they undoubtedly will. > > -chris > J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Jul 20 2001 - 22:11:40 PDT