On Tue, 12 Jun 2001, Greg KH wrote: > On Tue, Jun 12, 2001 at 12:10:39PM -0400, Stephen Smalley wrote: > > > > I've developed and attached a new LSM patch against the original 2.4.5 > > sources that diverges in several ways, detailed below, from the current > > LSM patch. I'm attaching this patch for consideration by the LSM > > "community" as a new starting point for discussions. I started over with > > the original 2.4.5 sources and selectively merged portions of the old LSM > > patch, since it seems that a number of the changes in the old LSM patch > > (e.g. removing the capability bits from the linux_binprm structure, > > replacing calls to capable with permissive hook calls, replacing all calls > > to compute_creds, some extraneous changes inherited from Immunix) may not > > be desirable. > > Thanks for the patch. As a comparison, I've included the diff between > your patch, and the current (for me) lsm patch (which includes the > current lsm.immunix.org bitkeeper tree + my ia64 patch). It makes it > easier to compare by looking at this diff. Thanks. It's helpful. > > I haven't had much time to compare but here are a few comments: > > > 2) Parameters were added to a number of the hooks, including ioperm, iopl, > > setuid, setgid, setrlimit, sethostname, setdomainname, reboot, and acct > > so that they are more generally useful. In a few cases, like > > sethostname and setdomainname, this required changing the kernel > > code to copy the parameter from user space to an intermediate location > > first for the hook and then copying from the intermediate location to > > the final destination after authorization by the hook. In other > > cases, like acct, it required relocating the hook to after useful > > information like the file was available. > > I like these. Authoritative passing kern_retval, in all cases. Restrictive NOT? (Still following code.) I agree. More generally: I miss "kern_retval=NOKERNELOPINION" in those places where kern_retval isn't available, but without the argument, it's implicit... just less forward compatible (imho). A semantic, naming differentiation between the two would be quite helpful. Either 1) passing the distinction with kern_retval for analysis by the module code, which would allow future "migration" from "restrictive-only" to "authoritative" by a simple value check would allow more flexable, forward sensitive coding. 2) naming or sub-structuring the authoritative calls vs. the restrictive would also provide a more forward sensitive interface. Form, Fit, and Function. I argue FORM, agree (now) the fit is "minimal kernel invasion with acceptable function", and Function... this patch seems to provide a better functional model. > > > 3) Recent changes made here by Chris Vance are integrated, > > including the patch he submitted recently to the mailing list > > and recent changes to support append vs. write distinctions. > > I think Chris Wright is just now applying those patches. Apples vs. Apples. > > > 4) Capabilities in the base kernel were left unmodified, since I > > wasn't clear what direction we are heading in for capabilities. > > If we do decide to retain a capabilities module, I would still > > favor leaving the existing capable() calls unchanged and being > > very conservative in only moving the real capabilities logic > > out of the base kernel, leaving the basic DAC/superuser/set[ug]id > > logic intact so that the base kernel remains useable. I > > left the base kernel compute_creds function intact (and > > all calls to it) and merely added a call to our hook at > > the end of the function. > > One of the explicit requirements to get LSM into the kernel was to have > the ability to make capabilities be a module. This allows the embedded > people to completely remove capabilities, as they really want this. I > don't think we can ignore this, no matter how much of a pain in the butt > it is :) > Now, listen: I've been "trounced" both ways. Careful reading of Linus' original message DOES seem to suggest it's "advisary" and not "required" on the point of moving capabilities out to a module. If we are going to putz with capabilities, Mr. Smalley's suggestion of reverting some and intercepting capable() does seem to be the easiest/cleanest solution currently under consideration. I'd also prefer a semantic distinction between "capabilities" and "security" in the LSM MPI (module programming interface.), allowing clarification for current and future coders. The distinction addresses NOT functionality, but rather FORM, and form influences module coding practices. By dividing, we conquer. I still argue for "pushing" all the capabilities work to a unique subinterface, and defaulting that interface to "as close as possible to current form" in dummy, or, better, a "default load", although I'm not sure any filesystems are "awake" at the point security_scaffolding_... is called. It should be there until replaced... Possibly, now that I think of it, providing an option to "retain"... perhaps just a write-back into security_ops triggered on a NULL capability subinterface value. Capabilites are lame right now. There are people working on UN-laming them. They're "pre-existing". A solution here that preserves them with the possibility of "removing them totally" for those who don't like them is most desirable, ducks-in-a-row-wise. I propose we decide *right now* before we put more work into it, if "capabilities" will be addressed by the LSM project. > > 5) A few changes in the old LSM patch that seemed to be > > inherited from Immunix or irrelevant to LSM were omitted. > > I did leave the changes to the Makefiles for people with > > StackGuard compilers for the convenience of WireX folks, but I > > don't really expect that change to be in the final version > > for inclusion in the mainstream kernel. > > The new Kbuild system that will be in 2.5 has support for the StackGuard > compiler. In the meantime it doesn't hurt anything to have this patch > in the lsm tree for those developers who use this compiler. And you are > correct, the lsm patch, whenever it will be submitted, will not have > this patch in it. > > What other changes (besides the elf header change) did you see that was > left over from Immunix changes, or were irrelevant? I thought I got all > of those out :) > StackGuard appears to "rock". Why not "tie" the LSM patch in such a way to option it, since IMMUNIX is a major player? Do any other projects have a "companion" sort of support at that level? I don't see any problems with an option... since the "option" will go away and be "standard support" in the 2.5+ tree. I might suggest deleting all #5 concerns. We get into "issues" with #5, more often than not, being generally attacks on "firmly held beliefs." (joke.) > thanks, > > greg k-h > J. Melvin Jones PITA |>------------------------------------------------------ || 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 : Tue Jun 12 2001 - 11:18:59 PDT