On Tuesday, September 4, 2018 9:25:56 AM EDT Trevor Vaughan wrote: > 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.
auditd is just a logger. Something like this would probably go in auditctl. The problem is that it runs once and is gone. So, what happens if someone downloads and installs a new container? You could almost make the case that the container orchestrator should create audit rules since it knows when a container is created or deleted. This is probably not likely to happen because I doubt people doing orchestration care about this. We also have the same issue with libvirt mounted partitions. An admin can execute programs that belong to a vm in /var/lib/libvirt/filesystems/ Besides that, it only takes one command to loopback mount a guest image, which then provides access to all kinds of things. Then we also have the notion of cdroms and usb flash drives. What do we do about these? In someways, this may be easier solved by application whitelisting. Which is why I was wondering if this should be an access control issue rather than audit. But if we did want to do this via audit, its a complicated problem. -Steve > 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] > > dorahosted.org _______________________________________________ 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]
