On Sat, 22 Jul 2000, Khimenko Victor wrote:
> In <Pine.LNX.4.10.10007221209030.5294-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
> > On 21 Jul 2000, Henning P. Schmiedehausen wrote:
>
> >> jas88@cam.ac.uk (James Sutherland) writes:
> >>
> >> >> So disk2brick.c will just bypass the kernel API and bit-bang on the IDE
> >> >> controller directly...
> >>
> >> >If a usermode app can hit the hardware directly like that, there's
> >> >something VERY broken...
> >>
> >> If it can not, I'll simply whip up a kernel module which I can acess
> >> from user space, which can.
>
> > There's a hell of a big difference between "type this code into
> > EDITOROFCHOICE, compile and run and your drive is a paperweight" and
> > "rebuilt the kernel, deleting this bit and inserting this replacement
> > driver, then proceed as above".
>
> Not exactly. You can as easily remove all Andre's checks via /dev/kmem.
> Program will be slightly bigger but not much.
/dev/kmem disappears along with all the other bypass routes on a
thoroughly secured system.
> >> What I tried to understand in between Andre's swearwords, is that you
> >> can enable drives to access a full set of parameters ("taskfile") or
> >> you can disable this. If you enable it, you can fry the drive. If you
> >> disable it, you can't but you can still use the regular ATA command
> >> set which is all that the kernel will ever need.
>
> > Yep. There's a big red self-destruct button on the drive. Either we leave
> > it enabled, or switch it off.
>
> 1. We can not switch it off while retaining raw hardware access.
We cannot switch *ANYTHING* off for root while retaining raw hardware
access.
> 2. We can make it inaccessible for someone without CAP_SYS_RAW by two lines
> patch instead of 60K patch.
I'd use another capability (SYS_DESTROY_HARDWARE) which isn't enabled for
anything by default. Apart from that, it's OK.
> > I prefer the latter - leaving those things lying around is just *begging*
> > for the next Linux crack story to go "some bastard got in with an old buffer
> > overflow exploit, and toasted my $10k server just by running a shell script".
> > I don't want to see that one...
>
> I don't as well but we have choice.
We NEED to block this function somehow.
> >> The question now is: Once you disabled this, you can't enable it
> >> again? If this is truw, then I can understand many of the strange
> >> words that Andre used (though I still think that he was/is under deep
> >> sleep deprivation and strong drugs). If you can reenable this access,
> >> then there is no point.
>
> > Once blocked by the kernel, you have to do strange and nasty things
> > (screwing with the kernel, then rebooting with your own version,
>
> Huh ? You just need to grep over /dev/kmem and replace few bytes there.
> Not such a big deal.
Nope - /dev/kmem is gone.
> > or using Linux's biggest security flaw to bypass everything) to get this
> > `feature' available again.
>
> See above.
As above, it's gone.
> > At a later date, I want to see that flaw closed too, but it's harder.
>
> It's IMPOSSIBLE as long as "root is god". And if root was retired from gods
> via /proc/sys/kernel/cap-bound it's impossible at all and you do not need
> this patch for that.
So long as not having CAP_DESTROY_HARDWARE prevents this, and
CAP_DESTROY_HARDWARE isn't available to anything by default, that's OK.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:19 EST