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.
>> There is simply no point in hiding anything from root.
> Disagreed. You want to make directories editable directly, perhaps? How
> about just running root's apps in ring 0? After all, you assume root is
> perfect and infallible, right?
You CAN edit dirictiries directly (on unmounted system). It's prohibeted for
mounted system by speed reason, not by security reason. About ring 0... You
CAN reduce root power with capabilities. And you CAN forbid this ioctl as well.
Via /proc/sys/kernel/cap-bound ...
>> 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.
2. We can make it inaccessible for someone without CAP_SYS_RAW by two lines
patch instead of 60K patch.
> 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.
>> 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.
> or using Linux's biggest security flaw to bypass everything) to get this
> `feature' available again.
See above.
> 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.
-
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