On Sun, 23 Jul 2000, Vojtech Pavlik wrote:
> > 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.
Which should really be done anyway wherever possible. Possibly make an
exception for graphics - give the X server and co "direct" access to the
graphics card only.
> > 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.
It shouldn't allow these blocks of unvalidated data through at all, then -
that's too dangerous. If the kernel doesn't know what's going on, HTF is
it supposed to enforce any kind of security or other system policy??
> > 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's exactly what I wanted all along: remove the "do something
arbitrary, and no I won't tell you [the kernel] what it is" function, and
replace it with "update HDD firmware", "change PIO mode", etc.
> 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.
It's not filtering; IDE commands shouldn't originate in userland to begin
with. Userland apps should make a request to the kernel for a specific
kernel facility; the kernel then implements this by sending IDE commands
as needed.
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:20 EST