2:25 p.m.
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-o...
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 ;)
11:01 a.m.
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(a)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(a)lists.fedorahosted.org
8:06 a.m.
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(a)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(a)lists.fedorahosted.org
8:25 a.m.
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(a)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(a)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(a)lists.fedorahosted.org
_______________________________________________
scap-security-guide mailing list --
scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave(a)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...
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
9:07 a.m.
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(a)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(a)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(a)lists.fedorahosted.org
>
>
>
> _______________________________________________
> scap-security-guide mailing list --
> scap-security-guide(a)lists.fedorahosted.org
> To unsubscribe send an email to
> scap-security-guide-leave(a)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
9:22 a.m.
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(a)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(a)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(a)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(a)lists.fedorahosted.org
> >
> >
> >
> > _______________________________________________
> > scap-security-guide mailing list --
> > scap-security-guide(a)lists.fedorahosted.org
> > To unsubscribe send an email to
> > scap-security-guide-leave(a)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 --
8:34 a.m.
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(a)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(a)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(a)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(a)lists.fedorahosted.org
8:36 a.m.
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(a)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(a)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(a)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(a)lists.fedorahosted.org
>
>
>
> _______________________________________________
> scap-security-guide mailing list --
> scap-security-guide(a)lists.fedorahosted.org
> To unsubscribe send an email to
> scap-security-guide-leave(a)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...
>
_______________________________________________
scap-security-guide mailing list --
scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave(a)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...
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
7:45 a.m.
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(a)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-o...
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(a)lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave(a)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...
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
2055
days inactive
2059
days old
scap-security-guide@lists.fedorahosted.org
8 comments
5 participants
participants (5)
-
Gabe Alford -
Matus Marhefka -
Shawn Wells -
Steve Grubb -
Trevor Vaughan