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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.