On Sun, Jul 23, 2000 at 09:45:35AM +0100, James Sutherland wrote:
> > If the system is secure, then adding sanity checking to the ATA code
> > makes no difference: nobody gets to do anything improper anyway.
>
> That assumes an infallible root, which is a bit optimistic. What reason is
> there NOT to have sanity checking, other than some people liking the
> thrill of Russian roulette with their hardware?
>
> I know enough about electricity not to prod the live wire in my mains
> supply. Does this mean I should leave the cover off my fusebox? After all,
> my house is secure, so nobody gets to do anything improper there...
Actually, the situation is more like that you have a covered fusebox in
your house, but you don't have a lock on it. Yes, you can unscrew the
cover and get yourself screwed (write a program that uses the ioctl and
kills the drive), and no lock is protecting you from fiddling with the
wires, but you can't get killed by just simply touching the thing when
walking through your house in the dark.
This amount of protection (I don't say security, this can't ever be
secure) seems to be fine for most households.
Normal programs won't ever have the chance to do anything bad using the
ioctl. They don't use it. They don't even have /dev/hda open.
By the way, the ioctl exists since 2.0 days, very likely since 1.0 even.
Has *anyone* killed their drive by accident this way?
Seems like the current protection against accidental damage is ok.
Against intentional damage only disabling all raw io access can help.
> Seriously, in the NT case at least, the kernel is expected to validate the
> parameters it is passed from userland. It doesn't matter what user or
> capability set the process has - it can still only pass valid parameters.
> Where a parameter is being accepted unchecked, the code in question is
> regarded as a bug, and fixed as such.
The kernel validates the parameters. The inode, the ioctl number, the
pointer to the structure, and then passes the data to the drive. It
doesn't validate the data. It cannot reliably - either it'll filter too
much or too little, but never get it right with not all of the commands
being known.
> This isn't a security issue, really, just a "this is a dangerous
> implementation" issue. As a longer term aim, I'd like to see this sort of
> loophole for hardware manufacturers to bypass the kernel closed off, too -
> I don't want to see a load of vendor-specific binaries screwing with the
> hardware completely outside the kernel's control.
This is a good point. But in that case, the right solution would be just
to simply remove this raw hd io ioctl and replace it with hardware
abstracted (best independent on IDE/ATAPI) get/set info/options and
read/write firmware commands to the kernel via some interface, be it
another ioctl or /proc tree or /dev node.
That'd be ok. That's hardware abstraction. That's what a kernel is
supposed to do. But not filtering data provided by userland, that's
policy and doesn't belong to the kernel. The difference is subtle, but
still is there.
-- Vojtech Pavlik SuSE Labs- 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:20 EST