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-t...
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.
What's the best way to capture this in OVAL rules? 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 ;)
Hello,
I would discuss this with the people working on Audit. Adding them into the conversation.
Regards, Matus Marhefka
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.
What's the best way to capture this in OVAL rules? 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
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-%3E > 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-%3E > security-guide@lists.fedorahosted.org
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 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.
- Be able to audit all use of a command wherever it is.
- 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-%3E >
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-%3E >
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.fedor...
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.
- Be able to audit all use of a command wherever it is.
- 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-%3E >
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-%3E >
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
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.
- Be able to audit all use of a command wherever it is.
- 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-%3E >
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-%3E
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
CIS Benchmark requires the auditing of /var/lib/docker for this reason which might be the simplest answer to handling these cases.
On Tue, Sep 4, 2018 at 7:06 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.
- Be able to audit all use of a command wherever it is.
- 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-%3E >
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-%3E >
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.fedorahosted.org
Gabe,
Has anyone tried that in real life? Sounds like a recipe for more audit logs than you'll ever be able to handle on a high-use OpenShift or k8s system.
On Tue, Sep 4, 2018 at 9:35 AM Gabe Alford redhatrises@gmail.com wrote:
CIS Benchmark requires the auditing of /var/lib/docker for this reason which might be the simplest answer to handling these cases.
On Tue, Sep 4, 2018 at 7:06 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.
- Be able to audit all use of a command wherever it is.
- 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-%3E >
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-%3E >
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.fedor...
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.fedor...
That will probably have to be completely variable.
For instance, I run containers directly out of systemd (including namespaced applications that aren't traditional containers) so this is going to get really complicated unless you want to start dictating specific software sets.
Trevor
On Fri, Aug 31, 2018 at 3: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-t...
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.
What's the best way to capture this in OVAL rules? 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.fedor...
scap-security-guide@lists.fedorahosted.org
-
Gabe Alford -
Matus Marhefka -
Shawn Wells -
Steve Grubb -
Trevor Vaughan