On Fri, Jul 12, 2019 at 2:25 PM Stephen Smalley <sds@xxxxxxxxxxxxx> 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
