* Stephen Smalley (sdsat_private) wrote: > > The attached patch differs from the old LSM patch in the following ways: Thanks for putting something concrete down! In general I like the approach. Some specifics below... > 1) All of the non-capable hooks are now either restrictive or > authoritative. I made the hook functions authoritative where > there was existing base logic, the base logic was cleanly decoupled > from the functional logic, and it was feasible to colocate the hook > with the existing base logic. I reverted the non-capable permissive hooks > to capable() calls and added restrictive or authoritative hooks for those > operations. The following hooks were changed to be authoritative: > permission, setattr, send_sigiotask, kill, ptrace, setnice, setrlimit, > setscheduler, ioperm, iopl, reboot. There are probably other hooks that > could be made authoritative without too much trouble. The only thing I'm skeptical of is the need for authoritative hooks. The checks are after capable() which provides coarse grained permissive hooks since capable calls in to the module. If you pass the capable test, then you have already overriden the DAC logic. Why do you need to give another permissive test? If the second permissive test is useful because the first permissive test was too coarse grained, then we have inserted two permissive hooks in one code path to answer one question. If we limit the hooks other than capable() to being restrictive we at least have no ambiguity from the point of simple assurance. > 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. These look cool. > 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. Any input on the questions I had regarding the fowner changes? > 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. With the dummy default security module, perhaps the capable checks could be compile time configurable as capabilities or superuser checks. Then the base kernel would always have something, the dummy module could remain dumb, and all modules could easily compose with capabilities or superuser. -chris _______________________________________________ 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:50:42 PDT