Sorry, on a second look I notice the descriptions in security.h are far less helpful than I'd thought! The new hooks allow an LSM to refuse a process the ability to: view a list of audit rules add to the list of audit rules delete an audit rule set audit parameters (ie enable/disable audit, rate limit, etc) create a 'login' audit record. The last one is the most dubious one in my mind, but we do want to prevent a user from sending fake login audit messages, either to mislead the auditor or to fill the log with garbage. Note that the audit code (kernel/audit.c and kernel/auditsc.c) is in the kernel now. This patch only allows LSMs to restrict processes' interaction with the audit subsystem. At the moment, some of this interaction depends upon CAP_SYS_ADMIN, and some (like listing the audit rules) is always allowed. -serge On Wed, 2004-09-15 at 08:01, Crispin Cowan wrote: > Serge Hallyn wrote: > > >Attached is a patch which provides LSM controls over actions related to > >the new audit framework. As a specific example, we might like to have > >an "audit role", enabled by selinux or some other LSM, which would be > >the only role allowed to add or delete filter rules. > > > >What do people think about adding these hooks, both in general and these > >hooks specifically? > > > > > LSM is about enabling policy modules, not imposing policy. Glancing > through the patch, it appears to put audit-specific stuff into LSM. I > would rather see appropriate hook placement so that an audit module (or > an audit-aware module) could be created, but without imposing > audit-specific semantics on the hooks. > > But then again, I'm just guessing at what the patch does based on > variable names :) Can you post a description of what the patch does? > > Crispin -- ======================================================= Serge Hallyn Security Software Engineer, IBM Linux Technology Center serue@private
This archive was generated by hypermail 2.1.3 : Wed Sep 15 2004 - 06:25:48 PDT