linux-kernel - Re: [PATCH] capability: WARN when invalid capability is requested rather than BUG/panic

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, 01 Oct 2008 11:32:40 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	sds@...ho.nsa.gov, morgan@...nel.org, selinux@...ho.nsa.gov
Subject: Re: [PATCH] capability: WARN when invalid capability is requested
	rather than BUG/panic

On Tue, 2008-09-30 at 10:28 -0700, Arjan van de Ven wrote:
> On Tue, 30 Sep 2008 13:22:30 -0400
> Eric Paris <eparis@...hat.com> wrote:
> > 
> > No argument from me that patching up for buggy drivers sucks.  Yours
> > would be less overhead, and it would return the cap system back to
> > pre-2.6.25 operation (garbage in garbage out but no panic).  Since we
> > already have the branch in SELinux its no 'extra' overhead to EPERM
> > there instead of here (garbage in EPERM out).
> 
> to be honest, this is really a case of 
> panic("This stuff is really borken")
> 
> if it passes some random value, what other api's does it pass a random
> value to ?
> 
> (and in addition, random values to security critical APIs deserve a
> process kill, because it could well be an exploit attempt at guessing
> something. At least by not letting it live it's harder to get such type
> of exploits to be able to guess things. So imo, BUG() is the right
> answer)

Do we have any concern of a module being compiled against a new kernel
say with cap number 35 defined and then loaded into a kernel with only
34 capabilities?  Do we care about that forward compatibility?  If we
care BUG is scary.  EPERM would be the right thing since clearly on this
kernel the process can't possibly have cap #35.

We really have 4 options (in the order I like them).

1) do nothing (garbage in garbage out, sometimes panic sometimes not)
2) mask CAP_TO_INDEX (garbage in garbage out, no panic)
3) BUG_ON(!cap_valid(flag)) (garbage in BUG out, no panic)
4) WARN_ON/EPERM (garbage in EPERM out, no panic)

SELinux already sorta does #3 and #4 (we will panic if cap > 64 and will
EPERM between the max cap and 64) but I really don't like being blamed
when it's not my fault.  SELinux takes enough crap when people's systems
don't work and this time its clearly not my fault, which is why I'm
pushing this.

If we believe the capability system should take path's 1, 2, or 4 I'm
going to take path 4 in SELinux.  If capabilities wants to take path 3,
I'm ok with that too.  Its going to break a lot of people's machines I'm
afraid, but it would force ATI to fix their crap....

-Eric

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