Suggestion for RHEL-06-000198

Trevor Vaughan tvaughan at onyxpoint.com
Thu Jul 11 03:29:03 UTC 2013


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 at 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 at onyxpoint.com

-- This account not approved for unencrypted proprietary information --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130710/22b1790f/attachment.html>


More information about the scap-security-guide mailing list