Steve, Would it be feasible to have the code that makes the central audidt.conf support pre-processing path wildcards and adding those to the ruleset? It's not great, and they should probably all have a comment but it would be closer to what I would expect to happen.
Alternatively, I guess a cron job could look for things and manipulate the rules on the fly but that doesn't let you set '-e 2'. But, given the dynamic nature of most systems, '-e 2' really isn't practical. Trevor On Tue, Sep 4, 2018 at 9:07 AM Steve Grubb <[email protected]> wrote: > On Monday, September 3, 2018 12:01:11 PM EDT Matus Marhefka wrote: > > Hello, > > > > I would discuss this with the people working on Audit. Adding them into > the > > conversation. > > What this sounds like is 2 requests. > > 1) Be able to audit all use of a command wherever it is. > 2) Have OVAL rules that can check that the rule is in place. > > For item 1, remember that auditing is done by the kernel and it has no > concept of strings such as path names. That is a human convenience. What > it > knows is numbers like inodes and device numbers. This is how the original > disk auditing worked on RHEL 4. On RHEL 5 we picked up a convenience > feature > that took the string and looked up the inode and device and watched that. > From those days its moved from inotify to fsnotify. Neither support > globbing. > So, it will likely not be possible to specify a wildcard for any audit > rule. > > > On Fri, Aug 31, 2018 at 9:25 PM, Shawn Wells <[email protected]> wrote: > > > Received an interesting question from a colleague today. > > > > > > The various STIG requirements have full paths for auditing, e.g. for > > > /usr/bin/chage: > > > > > > https://rhel7stig.readthedocs.io/en/latest/medium.html#v-> > > 72155-all-uses-of-the-chage-command-must-be-audited-rhel-07-030660 > > > > > > Which call for an audit rule similar to: > > > > > > -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F > > > auid!=4294967295 -k privileged-passwd > > > > > > > > > However, on a container platform (e.g. OpenShift), the root user on > nodes > > > can execute chage in its own */usr/bin/* as well as within all the > > > containers */var/lib/docker/*<UUID>/bin/chage. > > Should this be allowed at all? I'm wondering if the right answer is access > control vs auditing. But I'd say that for now at least you'd need to set > up > rules with the full paths into each docker dir to things you want to know > about. > > > > What's the best way to capture this in OVAL rules? > > Don't worry about OVAL until we figure out what the right approach is for > manually entering audit rules. > > -Steve > > > > Was thinking updating > > > the regex on path to include the full-path > > > (/usr/bin/chage|/var/lib/docker/*/bin/chage).... but not sure if that's > > > a standard path that would work for non-OpenShift platforms. > > > > > > +cc Jeff Pullen who asked the question. Jeff... note this is a *public* > > > mailing list ;) > > > > > > _______________________________________________ > > > scap-security-guide mailing list -- scap-security-guide@lists. > > > fedorahosted.org > > > To unsubscribe send an email to scap-security-guide-leave@ > > > lists.fedorahosted.org > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: https://lists.fedorahosted.org/archives/list/scap-> > > [email protected] > > > > _______________________________________________ > scap-security-guide mailing list -- > [email protected] > To unsubscribe send an email to > [email protected] > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
