All,
Currently the remediation text for RHEL-06-000198 reads as:
At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid programs:
# find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null
Then, for each setuid program on the system, add a line of the following form to "/etc/audit/audit.rules", where [SETUID_PROG_PATH] is the full path to each setuid program in the list:
-a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged
I would like to suggest that this be changed to
Add the following to audit.rules: -a always,exit -F arch=b64 -F euid=0 -F uid!=0 -S execve -k suid-root-exec -a always,exit -F arch=b64 -F egid=0 -F gid!=0 -S execve -k sgid-root-exec -a always,exit -F arch=b32 -F euid=0 -F uid!=0 -S execve -k suid-root-exec -a always,exit -F arch=b32 -F egid=0 -F gid!=0 -S execve -k sgid-root-exec
From my testing, this appears to catch the execution of all suid/sgit
binaries without digging all over the system to figure out what they are. As an added bonus, you get to find out about binaries that pop onto your system for a brief period.
Thanks,
Trevor
On Jun 27, 2013, at 6:34 PM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
From my testing, this appears to catch the execution of all suid/sgit binaries without digging all over the system to figure out what they are. As an added bonus, you get to find out about binaries that pop onto your system for a brief period.
I think you can email your request to the DISA FSO Helpdesk and they review your suggestion and add it to the next version of the STIG. Here is the address which you can verify on the DISA STIG home page. When I've emailed them in the past, they take a day or two to respond.
disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil
Bryan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/27/2013 04:34 PM, Trevor Vaughan wrote:
All,
Currently the remediation text for RHEL-06-000198 reads as:
At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid programs:
# find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null
Then, for each setuid program on the system, add a line of the following form to "/etc/audit/audit.rules", where [SETUID_PROG_PATH] is the full path to each setuid program in the list:
-a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged
I would like to suggest that this be changed to
Add the following to audit.rules: -a always,exit -F arch=b64 -F euid=0 -F uid!=0 -S execve -k suid-root-exec -a always,exit -F arch=b64 -F egid=0 -F gid!=0 -S execve -k sgid-root-exec -a always,exit -F arch=b32 -F euid=0 -F uid!=0 -S execve -k suid-root-exec -a always,exit -F arch=b32 -F egid=0 -F gid!=0 -S execve -k sgid-root-exec
Wouldn't this miss a lot of interesting setgid/setuid to non root user programs? Whereas the above mentioned fine +4000/+2000 will catch ALL the currently existing setuid/setgid binaries. Probably best to use both.
From my testing, this appears to catch the execution of all suid/sgit binaries without digging all over the system to figure out what they are. As an added bonus, you get to find out about binaries that pop onto your system for a brief period.
Thanks,
Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com mailto:tvaughan@onyxpoint.com
- -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
On Thursday, June 27, 2013 06:34:31 PM Trevor Vaughan wrote:
All,
Currently the remediation text for RHEL-06-000198 reads as:
At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid programs:
# find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null
Then, for each setuid program on the system, add a line of the following form to "/etc/audit/audit.rules", where [SETUID_PROG_PATH] is the full path to each setuid program in the list:
-a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged
I would like to suggest that this be changed to
Add the following to audit.rules: -a always,exit -F arch=b64 -F euid=0 -F uid!=0 -S execve -k suid-root-exec -a always,exit -F arch=b64 -F egid=0 -F gid!=0 -S execve -k sgid-root-exec -a always,exit -F arch=b32 -F euid=0 -F uid!=0 -S execve -k suid-root-exec -a always,exit -F arch=b32 -F egid=0 -F gid!=0 -S execve -k sgid-root-exec
From my testing, this appears to catch the execution of all suid/sgit binaries without digging all over the system to figure out what they are.
The drawback to this method is that you have 4 rules that get evaluated for each and every syscall made to the kernel. Syscall rules have performance impacts. I would also switch out uid!=0 to auid>=500 auid!=4294967295. The reason being that the threat is what a user does rather than normal system operation.
Regarding setgid, there are no apps that are setgid root.
As an added bonus, you get to find out about binaries that pop onto your system for a brief period.
Does that actually happen? World writable dirs should have -noexec mount option and that leaves a user's home dir as the only place that could happen unless an admin installs apps. /home should be mounted -nosuid so...can it happen?
-Steve
Sorry for dropping out for a while.
"The drawback to this method is that you have 4 rules that get evaluated for each and every syscall made to the kernel."
I absolutely agree. But it seems to be a case of consistent minor slowdown where I have tons of cores (usually) vs 'find /....' which KILLS my systems with slow disk I/O and misses things on NFS shares, etc...
"I would also switch out uid!=0 to auid>=500 auid!=4294967295"
I usually have my first rule be one that drops anything below 500 or equal to 4294967295 or the 32 bit equivalent on 32 bit systems since pretty much everything from that range is useless but, barring that, you should definitely do this.
"Does that actually happen? World writable dirs should have -noexec"
Of course it does. They *should* have -noexec indeed but many/most lovely commercial vendors out there tend to not like that setting very much on /tmp or /var/tmp since they expect to install things from there (or /home or something equally horrible). Or, someone drops something into NFS/AFS or...pick your annoying misconfiguration of the day. ( http://www.moreajays.com/2013/03/createouiprocess-13-permission-denied.html)
Interestingly, looking through the latest STIG at stigviewer.com, I don't see the requirement for setting /tmp and /var to noexec or nosuid.
Honestly, I haven't really noticed that much in the way of system impact with the full CAPP profile enabled on systems. A lot of it comes down to tailoring your rules so that most of the chaff gets killed by the first few rules, just like iptables.
Thanks,
Trevor
On Fri, Jun 28, 2013 at 10:59 AM, Steve Grubb sgrubb@redhat.com wrote:
On Thursday, June 27, 2013 06:34:31 PM Trevor Vaughan wrote:
All,
Currently the remediation text for RHEL-06-000198 reads as:
At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid programs:
# find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null
Then, for each setuid program on the system, add a line of the
following
form to "/etc/audit/audit.rules", where [SETUID_PROG_PATH] is the full
path
to each setuid program in the list:
-a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged
I would like to suggest that this be changed to
Add the following to audit.rules: -a always,exit -F arch=b64 -F euid=0 -F uid!=0 -S execve -k
suid-root-exec
-a always,exit -F arch=b64 -F egid=0 -F gid!=0 -S execve -k
sgid-root-exec
-a always,exit -F arch=b32 -F euid=0 -F uid!=0 -S execve -k
suid-root-exec
-a always,exit -F arch=b32 -F egid=0 -F gid!=0 -S execve -k
sgid-root-exec
From my testing, this appears to catch the execution of all suid/sgit binaries without digging all over the system to figure out what they are.
The drawback to this method is that you have 4 rules that get evaluated for each and every syscall made to the kernel. Syscall rules have performance impacts. I would also switch out uid!=0 to auid>=500 auid!=4294967295. The reason being that the threat is what a user does rather than normal system operation.
Regarding setgid, there are no apps that are setgid root.
As an added bonus, you get to find out about binaries that pop onto your system for a brief period.
Does that actually happen? World writable dirs should have -noexec mount option and that leaves a user's home dir as the only place that could happen unless an admin installs apps. /home should be mounted -nosuid so...can it happen?
-Steve
Rr-read the SSG section and see the settings for /tmp and the bind mount on /var/tmp which makes sense.
I'm still curious as to how this will affect various vendor applications (and customer developer hackery) in the field though.
Thanks,
Trevor
On Wed, Jul 10, 2013 at 11:29 PM, Trevor Vaughan tvaughan@onyxpoint.comwrote:
Sorry for dropping out for a while.
"The drawback to this method is that you have 4 rules that get evaluated for each and every syscall made to the kernel."
I absolutely agree. But it seems to be a case of consistent minor slowdown where I have tons of cores (usually) vs 'find /....' which KILLS my systems with slow disk I/O and misses things on NFS shares, etc...
"I would also switch out uid!=0 to auid>=500 auid!=4294967295"
I usually have my first rule be one that drops anything below 500 or equal to 4294967295 or the 32 bit equivalent on 32 bit systems since pretty much everything from that range is useless but, barring that, you should definitely do this.
"Does that actually happen? World writable dirs should have -noexec"
Of course it does. They *should* have -noexec indeed but many/most lovely commercial vendors out there tend to not like that setting very much on /tmp or /var/tmp since they expect to install things from there (or /home or something equally horrible). Or, someone drops something into NFS/AFS or...pick your annoying misconfiguration of the day. ( http://www.moreajays.com/2013/03/createouiprocess-13-permission-denied.html )
Interestingly, looking through the latest STIG at stigviewer.com, I don't see the requirement for setting /tmp and /var to noexec or nosuid.
Honestly, I haven't really noticed that much in the way of system impact with the full CAPP profile enabled on systems. A lot of it comes down to tailoring your rules so that most of the chaff gets killed by the first few rules, just like iptables.
Thanks,
Trevor
On Fri, Jun 28, 2013 at 10:59 AM, Steve Grubb sgrubb@redhat.com wrote:
On Thursday, June 27, 2013 06:34:31 PM Trevor Vaughan wrote:
All,
Currently the remediation text for RHEL-06-000198 reads as:
At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid programs:
# find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null
Then, for each setuid program on the system, add a line of the
following
form to "/etc/audit/audit.rules", where [SETUID_PROG_PATH] is the full
path
to each setuid program in the list:
-a always,exit -F path=[SETUID_PROG_PATH] -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged
I would like to suggest that this be changed to
Add the following to audit.rules: -a always,exit -F arch=b64 -F euid=0 -F uid!=0 -S execve -k
suid-root-exec
-a always,exit -F arch=b64 -F egid=0 -F gid!=0 -S execve -k
sgid-root-exec
-a always,exit -F arch=b32 -F euid=0 -F uid!=0 -S execve -k
suid-root-exec
-a always,exit -F arch=b32 -F egid=0 -F gid!=0 -S execve -k
sgid-root-exec
From my testing, this appears to catch the execution of all suid/sgit binaries without digging all over the system to figure out what they
are.
The drawback to this method is that you have 4 rules that get evaluated for each and every syscall made to the kernel. Syscall rules have performance impacts. I would also switch out uid!=0 to auid>=500 auid!=4294967295. The reason being that the threat is what a user does rather than normal system operation.
Regarding setgid, there are no apps that are setgid root.
As an added bonus, you get to find out about binaries that pop onto your system for a brief period.
Does that actually happen? World writable dirs should have -noexec mount option and that leaves a user's home dir as the only place that could happen unless an admin installs apps. /home should be mounted -nosuid so...can it happen?
-Steve
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide@lists.fedorahosted.org
-
Bryan Harris -
Kurt Seifried -
Steve Grubb -
Trevor Vaughan