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]

Message-ID: <20081001083909.0d4e8ea3@infradead.org>
Date:	Wed, 1 Oct 2008 08:39:09 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Eric Paris <eparis@...hat.com>
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 Wed, 01 Oct 2008 11:32:40 -0400
Eric Paris <eparis@...hat.com> wrote:

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

No!
If you don't compile the module against the right kernel you get what
you deserve, and to be honest, this one is the least of your problems.


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

really; if you get garbage into the security system, BUG/panic is the
only way to go. You *know* there is an issue around security somehow,
(be it the "give me root" ioctl in fireglx or something else), and
to continue just keeps your machine exposed. That really is no option.

As to current users of said broken module: they crash-and-burn today
already, but that's between them and their module vendor if they chose
to run some binary clunker.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/