linux-kernel - Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20081030133541.GA4385@us.ibm.com>
Date:	Thu, 30 Oct 2008 08:35:41 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Eric Paris <eparis@...hat.com>
Cc:	"Andrew G. Morgan" <morgan@...nel.org>,
	linux-kernel@...r.kernel.org, linux-audit@...hat.com,
	sgrubb@...hat.com, viro@...IV.linux.org.uk
Subject: Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or
	inheritable capabilities

Quoting Eric Paris (eparis@...hat.com):
> On Wed, 2008-10-22 at 21:13 -0700, Andrew G. Morgan wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Serge E. Hallyn wrote:
> > >>> ... except if (!issecure(SECURE_NOROOT) && uid==0) I guess?
> > >>>
> > >>> And then it also might be interesting in the case where
> > >>> (!issecure(SECURE_NOROOT) && uid==0) and pP is not full.
> > >> I guess so, although this seems like a case of being interested in a
> > >> (unusual) non-privileged execve().
> > > 
> > > I'm not sure what you mean - but this can only happen if bits are taken
> > > out of the capability bounding set, right?
> > 
> > Yes, it can happen as you say.
> > 
> > This is a case of an unprivileged uid==0 execution. Since we don't
> > appear to want to audit other non-privileged execve()s, its not clear to
> > me that this one deserves attention.
> 
> So what did you two agree on for when to collect fcaps type information?
> Any time bprm->cap_post_exec_permitted is non-zero?

And (bprm->e_uid!=0 && current->uid!=0 && !issecure(SECURE_NOROOT)) -
otherwise you'll get a hit for every file executed by root.  If you're
ok with that noise, then it's fine with me.  (I assume it can be
filtered out using an audit rule by userspace anyway?)

The inverse case that I suggested is interesting because root was
prevented from running with full capabilities - which could be
indicative of a sendmail-capabilities-bug style of attack.

-serge
--
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/