On Thu, Aug 15, 2019 at 9:11 AM Aaron Goidel <acgoide@xxxxxxxxxxxxx> wrote: > I'm looking at how to enable LSMs to selectively turn on audit > collection. So there seems to be two key points: audit_alloc() and > __audit_syscall_entry(). Would it suffice to define a single boolean > hook that takes the task and call it from both functions, to decide > whether to override an AUDIT_DISABLED state in audit_alloc() and to > override a 0 audit_n_rules in __audit_syscall_entry(). In audit_alloc() > if audit_filter_task() returned AUDIT_DISABLED and the hook returned > true, we would change the state to AUDIT_BUILD_CONTEXT. In > __audit_syscall_entry(), if the hook returned true, we would set dummy > to 0. Obviously, we could have a more general hook which lets us return > arbitrary audit states, but, it isn't clear how we would reconcile > conflicting results from audit_filter_task() and the hook for any > situation other than AUDIT_DISABLED. We could also potentially use a > different hook in __audit_syscall_entry(), though I don't think that we > want the LSMs trying to interpret the syscall number or arguments. > > Do you think that is sufficiently general or would you suggest something > different? FWIW, I think treating the per-task audit switch as a boolean is fine; I don't think we want other in-kernel callers to have to worry about the different audit states. From their perspective it is either "on" or "off". However, I think there are two parts of the greater LSM-enables-audit discussion, and we're only discussing the first part: collection. The second part is the actual audit record generation, and I think this part is going to be less clear. While the changes to audit_alloc(), etc. are necessary to be able to do any meaningful audit later on, I'm thinking introducing some granularity and LSM control to what gets generated in audit_log_exit() might be very welcome both from a performance and log cleanliness perspective. Some random thoughts on this (some may be way off, but I want to start with some expectations): * The LSM should never be able to block collection/generation of audit records, just enable additional records. * The LSM controls should only affect what we call the "syscall auditing" bits, e.g. the stuff in auditsc.c. Audit records that happen outside of this should be untouched, the AVC records are an example of a record that exists independent of syscall auditing. * We should be able to have the LSM set a per-syscall audit enable flag which would be checked in audit_log_exit() (or audit_free()/__audit_syscall_exit()). * It's not clear to me if we want to provide some granularity to the LSM regarding what records get generated in audit_log_exit(), for example do we allow the LSM to request just PATH records? I'm guessing we wouldn't want to specify record types directly, but perhaps record "classes", e.g. "file". I'm not sure if any of this is going to be a good idea, but I think we need to discuss it a bit before we start duplicating things in lsm_audit.c. -- paul moore www.paul-moore.com
