It does seem like some dynamic capabilities needs to be added to the audit stack in general.
For instance, it's easy to detect udev events and then generate an audit rule on the fly that could audit all executions from that device but there's really no standard for doing something like this. Having a /etc/audit/audit.rules.dynamic.d with a set of 'inotify' rules would make sense to me and then different stacks can just plop whatever they like in there and trigger an audit rule recompile. You'll need to do that with a '-c' in case of errors, of course. In theory, the SSG should be mandating something like USBGuard or the like for removable devices in general. Also, when you start looking at what an *admin* can or can't do, I feel like we're treading heavily into the scenario for pam_tty_audit and tlog. Without SELinux in full MLS mode, admins can do what they darn well please so the best we can do is watch what they're doing without grinding the system to a halt with excessive auditd rules. This, of course, requires coupling with a 'offload first' logging strategy and then you have to decide how important it is to keep the system running versus logging everything. I'm a big fan of keeping the systems running in general but that does leave you open to shenanigans. Trevor On Tue, Sep 4, 2018 at 10:07 AM Steve Grubb <[email protected]> wrote: > 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 > > > > > -- 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]
