linux-audit.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: rshaw1@umbc.edu
Cc: linux-audit@redhat.com
Subject: Re: auid=0
Date: Mon, 03 Aug 2015 15:06:37 -0400	[thread overview]
Message-ID: <41115001.nqDBLmZtAp@x2> (raw)
In-Reply-To: <5078d5cdd4a92b5757767c0f248ef91b.squirrel@webmail.umbc.edu>

On Monday, August 03, 2015 02:53:52 PM rshaw1@umbc.edu wrote:
> > On Monday, August 03, 2015 02:11:31 PM rshaw1@umbc.edu wrote:
> >> Comparing the "official" STIG content with the scap-security-guide
> >> content, the former seems to have added corresponding rules for "-F
> >> auid=0" that aren't present in scap-security guide.  i.e. where
> >> scap-security-guide will just have one rule:
> >> 
> >> -a always,exit -F arch=ARCH -S <a bunch of stuff> -F auid>=500 -F
> >> auid!=4294967295 -k delete
> >> 
> >> the official content will have the above plus:
> >> 
> >> -a always,exit -F arch=ARCH -S <a bunch of stuff> -F auid=0 -k delete
> >> 
> >> Is the addition necessary?
> > 
> > Does the official STIG allow root logins? If so, I think that is a big
> > mistake
> > and should be fixed.  If it does not allow root logins, then the only way
> > I can
> > think of having auid to be 0 is for root cron jobs.
> 
> It doesn't, but that doesn't mean they don't love to layer the hell out of
> things.

I wouldn't expect root cron jobs to be a threat. But if they are worried about 
insider threats, then there should be a bunch of other new rules that use the 
inter-object comparator.


> >> It doesn't seem to be, as the rules caught root usage of, for example,
> >> chmod
> >> just fine without it (I had used su; not sure if there's a difference
> >> between
> >> that and other ways of being root.) I would like to make sure I'm right
> >> before asking one group or the other to delete or add it, respectively.
> > 
> > Perhaps they consider root cronjobs to be an attack vector?
> 
> Perhaps.  What about exploiting a daemon that runs as root?

Daemons have auid set to -1. To get auid to be anything other than -1, the 
loginuid has to be set. That is typically done by pam_loginuid.so.


> Would cron be the only one to show up as auid=0?

Yes, because cron calls pam_loginuid to setup the user session. Atd would also 
do this, but I think the code is now based off the same executable.


> I know there is some sort of thing that happens where the daemon will
> inherit the <somthing>uid of anyone who restarts it, but I'm not sure what
> it would start as at boot.
> 
> I'm hoping to not have to nearly double the amount of rules, but I'm
> guessing it doesn't work to have auid >=500, !=4294967295, and =0 in the
> same rule (when I tried it, it seemed to stop catching chmod altogether).

Everything in a rule forms an "and" expression. So, auid>=500 && auid=0 is 
logically false.

-Steve

      reply	other threads:[~2015-08-03 19:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-03 18:11 auid=0 rshaw1
2015-08-03 18:21 ` auid=0 Steve Grubb
2015-08-03 18:53   ` auid=0 rshaw1
2015-08-03 19:06     ` Steve Grubb [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41115001.nqDBLmZtAp@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=rshaw1@umbc.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).