auid=0

[Steve Grubb]

On Monday, August 03, 2015 02:53:52 PM rshaw1 at umbc.edu wrote:
> > On Monday, August 03, 2015 02:11:31 PM rshaw1 at 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