Question about RHEL-06-000185

Trevor Vaughan tvaughan at onyxpoint.com
Thu Jul 11 16:41:13 UTC 2013


This is actually pretty funny:

On a workstation:

685  /usr/bin/pidgin
377  /usr/lib64/firefox/firefox
186  /usr/libexec/gconfd-2
94  /usr/lib64/vte/gnome-pty-helper
60  /usr/bin/vim
56  /usr/bin/pulseaudio
49  /usr/bin/mesg
36  /bin/sed
30  /bin/vi
10  /usr/libexec/gdm-session-worker
8  /usr/libexec/gnome-settings-daemon
5  /usr/lib64/libreoffice/program/soffice.bin
4  /usr/bin/less
4  /usr/bin/ruby
4  /usr/bin/gnome-volume-control-applet
3  /usr/bin/evince
2  /usr/bin/vinagre
2  /usr/bin/gnome-panel
1  /sbin/rsyslogd

So, it looks like my biggest culprits are...PIdgin and Firefox


On a server:

Executable Summary Report
=================================
total  file
=================================
63360  /usr/bin/ruby
202  /usr/bin/vim
55  /usr/sbin/sshd
36  /usr/bin/mesg
25  /bin/chmod
7  /usr/bin/python
5  /bin/chown
3  /usr/bin/less
2  /usr/sbin/httpd
2  /bin/vi
1  /usr/bin/man
1  /bin/chgrp

Tracking down the hits on Ruby was interesting.

It turns out that the auid > 500 works unless you run the command through a
sudo session. Then, your auid is > 500 but your euid is < 500 for a given
daemon service. Is this something that, from a guidance point of view, you
would recommend ignoring due to the sheer mass of garbage data, or should
it be collected since it's being run as a normal user?

Even so, 202 hits on VIM is a lot of garbage when you start aggregating
systems.

Thanks,

Trevor


On Thu, Jul 11, 2013 at 10:54 AM, Steve Grubb <sgrubb at redhat.com> wrote:

> On Wednesday, July 10, 2013 11:36:47 PM Trevor Vaughan wrote:
> > Unfortunately, I completely understand the threat.
> >
> > I believe the threat to be: If we know when all of these happen, then
> we'll
> > be able to figure out who is trying to do what in case something bad
> > happens.
> >
> > I completely get it, but that's a heck of a lot of garbage data 99% of
> the
> > time. I guess the real question is: Is the garbage data worth the 1%?
>
> Where are you seeing all these permission changes and what is doing it? You
> gave a syscall report as evidence which is not helpful to understand what
> the
> issue is and how we might resolve it.
>
>
> > In response to Steve:
> >
> > Wouldn't it be interesting to see a permission change in a user's home
> > directory to 777 followed by some 644's or more 755's? This happens far
> too
> > often to get around pesky noexec settings on /tmp ;-).
>
> If you wanted it, this will get it for you:
>
> -a always,exit -S fchmodat -F dir=/home -F a2&0111 -F filetype=file  -k
> mkexe
> -a always,exit -S fchmod,chmod -F dir=/home -F a1&0111 -F filetype=file -k
> mkexe
>
> But this will catch only a naive user. The truly crafty users have to be
> caught another way. I'm still experimenting on how to do that.
>
> -Steve
>
>
>
> > On Mon, Jul 1, 2013 at 9:04 PM, Jeffrey Blank <blank at eclipse.ncsc.mil
> >wrote:
> > > I think it was based on some set of (possibly now outmoded) DoD policy.
> > >
> > >  And so the relationship to threat may not be clear.  The DISA folks
> are
> > >
> > > most likely to know where it came from.  Perhaps they could chime in.
> > >
> > > Since it was originally written a while ago, prior to the transition to
> > > SRGs based on security controls in NIST 800-53, it's likely worth
> > > revisiting.  If the OS SRG contains all the auditing rules necessary
> for a
> > > STIG, and there are no additional DoD requirements, then we should
> > > certainly be able to consider adjustment.
> > > This has the OS SRG reqs:
> > >
> > >
> http://www.stigviewer.com/stig/8ac5f3a06149beaa9ce61225390a6d60f88b2ac9/MA
> > > C1PublicProfile/>
> > > On Fri, Jun 28, 2013 at 10:36 AM, Steve Grubb <sgrubb at redhat.com>
> wrote:
> > >> On Thursday, June 27, 2013 06:30:00 PM Trevor Vaughan wrote:
> > >> > I've been running in compliance with this rule for quite some time
> now
> > >>
> > >> and
> > >>
> > >> > I'm noticing that the amount of noise that it produces is simply
> > >>
> > >> outrageous.
> > >>
> > >> > The suggestion is:
> > >> >
> > >> > At a minimum the audit system should collect file permission changes
> > >> > for
> > >> > all users and root. Add the following to "/etc/audit/audit.rules":
> > >> >
> > >> > -a always,exit -F arch=b32 -S chown -F auid>=500 -F
> auid!=4294967295 \
> > >> > -k perm_mod
> > >> >
> > >> > If the system is 64 bit then also add the following:
> > >> >
> > >> > -a always,exit -F arch=b64 -S chown -F auid>=500 -F
> auid!=4294967295 \
> > >> > -k perm_mod
> > >>
> > >> And these rules are incomplete. You also need -S fchmod -S fchmodat -S
> > >> setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S
> > >> fremovexattr
> > >>
> > >> > And here is the output of a normal workstation over about a week of
> > >>
> > >> > auditing and normal usage:
> > >> This is not the output generated by the rule above. :-) To get that
> you
> > >> would
> > >> to run:
> > >>
> > >> ausearch --start this-week -k perm_mod
> > >>
> > >> What is more interesting than the syscall list you have below is the
> > >> files and
> > >> programs causing it
> > >>
> > >> ausearch --start this-week -k perm_mod --raw | aureport -x --summary
> > >> and
> > >> ausearch --start this-week -k perm_mod --raw | aureport -f --summary
> > >>
> > >> Personally, I don't think its terribly interesting to see permission
> > >> changes
> > >> in a user's home directory. You might want to know that permissions
> > >> changed on
> > >> the user's home dir, but its uninteresting for anything it contains.
> > >>
> > >> I can certainly see this as interesting for system directories. Anyone
> > >> recall
> > >> what the threat was that this rule was watching for?
> > >>
> > >> -Steve
> > >>
> > >> > Syscall Summary Report
> > >> > ==========================
> > >> > total  syscall
> > >> > ==========================
> > >> > 24907  chmod
> > >> > 15870  chown
> > >> > 11169  rename
> > >> > 7409  open
> > >> > 6462  fchmod
> > >> > 5290  fchown
> > >> > 3687  umount2
> > >> > 1443  setsid
> > >> > 1166  fsetxattr
> > >> > 869  removexattr
> > >> > 456  adjtimex
> > >> > 360  fchmodat
> > >> > 337  lchown
> > >> > 211  setuid
> > >> > 69  mkdir
> > >> > 63  setsockopt
> > >> > 33  unlink
> > >> > 22  setxattr
> > >> > 20  clone
> > >> > 19  execve
> > >> > 7  fchownat
> > >> > 7  mount
> > >> > 7  creat
> > >> > 4  close
> > >> > 4  ioctl
> > >> > 3  symlink
> > >> > 2  mknod
> > >> > 1  rmdir
> > >> > 1  lsetxattr
> > >> > 1  clock_settime
> > >> > 1  capset
> > >> >
> > >> > So, I get why this can be useful. But I'm not so sure that it's
> useful
> > >>
> > >> to
> > >>
> > >> > know that Pidgin dropped a new temp file every few minutes or that,
> > >> > each
> > >> > time I open a file (and write a temp file), that I did this as a
> normal
> > >> > user.
> > >> >
> > >> > I just can't see the practicality of going through those top three
> > >>
> > >> calls on
> > >>
> > >> > a regular basis.
> > >> >
> > >> > I'm not necessarily suggesting that this type of thing be dropped
> but
> > >>
> > >> I'd
> > >>
> > >> > like to understand how auditors won't fall into just ignoring them
> > >> > completely.
> > >> >
> > >> > Thoughts?
> > >> >
> > >> > Thanks,
> > >> >
> > >> > Trevor
> > >>
> > >> _______________________________________________
> > >> scap-security-guide mailing list
> > >> scap-security-guide at lists.fedorahosted.org
> > >> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> > >
> > > _______________________________________________
> > > scap-security-guide mailing list
> > > scap-security-guide at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>



-- 
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/20130711/23498e58/attachment-0001.html>


More information about the scap-security-guide mailing list