Crispin Cowan wrote: > Christoph's objection is that each module would have to list all the > sysctl variables. Can the hook be modified so that a module need only > decide whether or not the subject process can call sysctl? A security module writer can use the existing sysctl hook in this manner (i.e. purely process-based restrictions) as well as in a finer-grained manner (i.e. distinguishing individual sysctl variables). The hook provides the full range of flexibility to the module writer. And, of course, the module writer can not implement the hook at all if no restrictions are desired beyond the DAC logic. Also, note that Christoph's objection was to having to list all of the _sensitive_ sysctl variables, not listing all the sysctl variables. Even SELinux does not list ALL of the sysctl variables; we group most of them into equivalence classes based on the sysctl hierarchy and only individually identify a few highly sensitive variables. Christoph's concern is that identifying that set of highly sensitive variables is tightly coupled to the particular kernel and should not be duplicated among the various security modules. I agree that it would be nice if the kernel provided a hint regarding its view of the sensitivity of a sysctl variable, but a particular security module might have a different view (and how it chooses to protect that variable may vary widely depending on the security model and attributes that it implements). Hence, you would still want the hook, and the hint would simply become part of the ctl_table state that is already passed to the hook. No change required to the hook interface itself. -- Stephen Smalley, NSA sdsat_private _______________________________________________ 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 Jan 21 2003 - 07:26:33 PST