Re: [PATCH] capability: WARN when invalid capability is requestedrather than BUG/panic

[Eric Paris]

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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/