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 <sgrubb@redhat.com> 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 <sgrubb@redhat.com> 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 <shawn@redhat.com> 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-> >
> >
> > security-guide@lists.fedorahosted.org
> >
> >
> >
> > _______________________________________________
> > 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-security-guide@lists.fe
> > dorahosted.org






--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --