lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 10 Apr 2013 13:35:26 -0400
From:	Richard Guy Briggs <rgb@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>,
	linux-audit@...hat.com
Subject: Re: [PATCH] [BZ905179] audit: omit check for uid and gid validity in
 audit rules and data

On Wed, Apr 10, 2013 at 12:20:18PM -0400, Richard Guy Briggs wrote:
> 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.

> > 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.

Meanwhile, could you please respond to my other comments interlaced in my
previous reply earlier in the thread?  In particular the question about
f->val == 1.

> > Eric
> 
> - RGB

- 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ