Date:	Wed, 10 Apr 2013 12:20:18 -0400
From:	Richard Guy Briggs <rgb@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Steve Grubb <sgrubb@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-audit@...hat.com, linux-kernel@...r.kernel.org,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] [BZ905179] audit: omit check for uid and gid validity in
 audit rules and data

On Tue, Apr 09, 2013 at 02:16:22PM -0700, Eric W. Biederman wrote:
> Steve Grubb <sgrubb@...hat.com> writes:
> 
> > On Tuesday, April 09, 2013 02:39:32 AM Eric W. Biederman wrote:
> >> Andrew Morton <akpm@...ux-foundation.org> writes:
> >> > On Wed, 20 Mar 2013 15:18:17 -0400 Richard Guy Briggs <rgb@...hat.com> 
> > wrote:
> >> >> audit rule additions containing "-F auid!=4294967295" were failing with
> >> >> EINVAL.
> >> >> 
> >> >> UID_INVALID (and GID_INVALID) is actually a valid uid (gid) for setting
> >> >> and
> >> >> testing against audit rules.  Remove the check for invalid uid and gid
> >> >> when
> >> >> parsing rules and data for logging.
> >> 
> >> In general testing against invalid uid appears completely bogus, and
> >> should always return true.  As it is and essentially always has been
> >> incorrect to explicitly set any kernel uid to that value.
> >
> > This is the unset value that daemons would have. 
> 
> As their uid, or gid, or euid, or fsuid.  Not in the least.

Point taken that only a value of UID_INVALID should be accepted for
auid.

> > When a real person logs in, 
> > pam_loginuid writes the loginuid that was authenticated to. So, any time the 
> > value is -1, we are dealing with a daemon or system process. When it comes to 
> > auditing, people usually make an exception so that daemon and normal system 
> > activity is not recorded. So, you would make a rule something like
> 
> > -a always,exit -S open -F exit=-EPERM -F auid>=500 -F auid!=-1
> 
> My point is that -1 is a special case that applies only to loginuid, and
> that when testing for -1 is not testing for a specific loginuid value
> but instead it is testing to see if loginuid has been set.  Semantically
> the last is very different.
> 
> >> The only case where this appears to make the least little bit of sense
> >> is if the goal of the test is to test to see if an audit logloginuid
> >> has been set at all.  In which case depending on a test against
> >> 4294967295 is bogus because you are depending on an intimate internal
> >> kernel implementation detail.
> >
> > Its been this way and documented since at least 9 years ago. The audit system 
> > has been broken for all intents and purposes since the 3.7 kernel was 
> > released.
> 
> I certainly haven't seen the documentation.

It is in the audit manpages.

> And no one has much cared
> about the audit subsystem this "breakage" of the audit
> subsystem. Despite things failing with a clear error code.  So there are
> two choices.  We mark the audit subsystem as broken moving it to staging
> and then delete it because no one cares enough to look after it and
> maintain it.  Or we have a constructive conversation about what to do
> with it.

Ok, politics aside...

> I have proposed a patch that will preserve the existing behavior while
> adding maintainable semantics.  Will someone who cares please test my
> proposed fix?

I'll test it.

> Eric

- RGB

--
Richard Guy Briggs <rbriggs@...hat.com>
Senior Software Engineer
AMER ENG Base Operating Systems
Remote, Canada, Ottawa
Voice: 1.647.777.2635
Internal: (81) 32635
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists