[RFC PATCH] security, capability: pass object information to security_capable

[Paul Moore]

On Fri, Jul 12, 2019 at 2:25 PM Stephen Smalley <sds at tycho.nsa.gov> wrote:
> That is part of what we want, but not the entire picture.  But with
> respect to audit, the problem today is that one sees SELinux
> dac_read_search, dac_override, etc denials with no indication as to the
> particular file, which is unfortunate both from a security auditing
> perspective and from a policy development perspective.  The only option
> today to gain that information is by enabling system call audit and
> setting at least one audit filter so that the audit framework will
> collect that information and include it in the audit records that are
> emitted upon syscall exit after any such AVC denial.

It might be worth looking into adding some functionality to allow the
LSMs to have some control about when/where to enable auditing.  While
selectively adding records once the denial is triggered isn't going to
be possible (it's too late to collect some of the information we would
want, e.g. file information), it should be possible to allow the LSM
to trigger per-process audit record collection without too much
trouble.  We could potentially take it a step further and on those
processes which have had auditing enabled by the LSM we could allow
the LSM to select when these additional records would be emitted (e.g.
on access denial); you would still incur the collection overhead, but
the logs would be much less.

> And even when one can enable
> syscall audit, one must correlate the syscall audit record to the
> associated AVC record to identify the object rather than having the
> information directly included in the same record.

We've been doing a lot of work to associate related records so that
you don't have to deal with the problem you're describing.  If you are
still seeing problematic records on a modern kernel I would like to
hear about it.

-- 
paul moore
www.paul-moore.com