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
prev parent 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).