[Non-DoD Source] Re: [RFC PATCH v2] security, capability: pass object information to security_capable

[Paul Moore]

On Thu, Aug 15, 2019 at 9:11 AM Aaron Goidel <acgoide at tycho.nsa.gov> 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