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 <[email protected]> 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
On Wed, 01 Oct 2008 11:32:40 -0400
Eric Paris <[email protected]> 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 <[email protected]> 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
Quoting Eric Paris ([email protected]):
> 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 <[email protected]> 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....
Assuming you have a kernel with your patch for 4, could you just run
some perf tests vs the unpatched kernel to show there's really no
meaningful performance impact?
-serge