On Fri, Aug 30, 2019 at 11:31 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 8/30/2019 6:44 AM, Stephen Smalley wrote: > > On 8/15/19 1:41 PM, Aaron Goidel wrote: > >> Presently, there is no way for LSMs to enable collection of supplemental > >> audit records such as path and inode information when a permission denial > >> occurs. Provide a LSM hook to allow LSMs to selectively enable collection > >> on a per-task basis, even if the audit configuration would otherwise > >> disable auditing of a task and/or contains no audit filter rules. If the > >> hook returns a non-zero result, collect all available audit information. If > >> the hook generates its own audit record, then supplemental audit > >> information will be emitted at syscall exit. > >> > >> In SELinux, we implement this hook by returning the result of a permission > >> check on the process. If the new process2:audit_enable permission is > >> allowed by the policy, then audit collection will be enabled for that > >> process. Otherwise, SELinux will defer to the audit configuration. > > > > Any feedback on this RFC patch? I know Paul provided some thoughts on the general topic of LSM/audit enablement in the other patch thread but I haven't seen any response to this patch. > > Audit policy should be independent of security module policy. > I shouldn't have to change SELinux policy to enable this data > collection. I should be able to change the audit configuration > to get this if I want it. The idea is that the LSM can request that the audit subsystem selectively enable auditing (per-task, and hopefully per-record-type); the audit policy can still be configured as you normally. This is to work around people (and distros) that disable audit, yet still want to audit some information (yeah, I know ...). -- paul moore www.paul-moore.com
