--------- Received message begins Here --------- > > * David Wagner (dawat_private) wrote: > > Chris Wright wrote: > > >* jmjonesat_private (jmjonesat_private) wrote: > > >> security_ops->capabilities > > >> security_ops->restrictive > > >> security_ops->permissive > > >> security_ops->audit > > > > > >You still have not convinced me that there is an value in splitting the > > >restrictive and permissive hooks apart like this. I am strongly in > > >favor of a single hook with authoritative control. > > > > Here's my take on it. I don't see the value of exposing > > security_ops->{permit,restrict,...}->hook > > to the base kernel. However, if modules want to separate these different > > types of hooks (and I think there are some benefits to many modules to be > > able to express this), then there is a way that this can be supported > > transparently, without exposing the existence of multiple types of hooks > > to the base kernel. > > > > Here's how. The base kernel sees a single > > security_ops->hook, > > which points to an optional translation layer (think of it as a special > > type of module that just does multiplexing). The underlying policy module > > can register its own favorite type of hook -- lsm->permissive_hook(), > > lsm->restrictive_hook(), whatever -- with the translation layer. When > > the translation layer receives a call to its hook from the base kernel > > (via security_ops->hook()), the translation layer calls each of the hooks > > registered by the policy module, and then combines their results in an > > appropriate way and returns that to the kernel. > > I don't think any of this would be possible without making the hooks > strictly authoritative either by pushing all access control logic into the > module, or by passing the result of kernel DAC logic to module. > Otherwise I don't think the permissive hooks would take on any meaning. > If the hooks are authoritative, this is a nice way to preserve simple > assurance (i.e. does your translation layer ever call a permissive hook?) > > I'm also not convinced that auditing hooks have the same placement > requirements as permissive/restrictive security hooks. I expect the > audit hook to need to know not only was i authorized (obvious overlap > with security check), but also was i sucessful (here we have overlap > with the post hooks added for file object creation). This is likely a little early, but: I think there are two kinds of audit. 1. General audit log (referred to above) where the log module needs/should log the security context plus the success/fail result. As to whether it belongs in the LSM or not is a separate issue (if not, it must request the information from the LSM before passing it to a daemon...) It also brings up the issue of what to do when/if the log daemon is terminated... (shut the system down after log queue fills? Hang the system? panic the system? drop the log entries? I've seen all four, and don't like the last one.) 2. A detailed (and correspondingly very massive) audit used to help check the LSM implementation. This log may have multiple entries for each general audit entry. Sort of like a LSM trace log. This log would be usefull to check that a policy (as checked by some static "verifier") really was implemented by the LSM correctly; or for tracking down where a failure occured. Much of the supporting code for this massive log should be optional, or be switched on/off easily. It would have to be combined with a daemon to acually get the log on disk (which may/may not be the same as the normal audit log daemon). BTW, this detailed log is more usefull if/when IPSec gets layered than right now. Just a thought. ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollardat_private Any opinions expressed are solely my own. _______________________________________________ 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 : Mon Jun 11 2001 - 10:54:47 PDT