On 22 Jul 2000, Linus Torvalds wrote:
> In article <Pine.LNX.4.10.10007221822320.5862-100000@dax.joh.cam.ac.uk>,
> James Sutherland <jas88@cam.ac.uk> wrote:
> >
> >So much for the "root is god" claims made earlier, then. What about iopl()
> >and the like? IF capabilities can be used to block this (and similar), and
> >Andre's "sanity checking" for ATA is added, then surely it *IS* possible
> >to prevent root screwing the HDD (without replacing the kernel, at which
> >point all bets are off, of course).
>
> What's the point?
>
> 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...
> If the system is not secure, then adding sanity checking to the ATA code
> makes no difference: people who could use the ATA thing can use other
> things that are much more insidious.
The "security" aspect of this is largely a red herring, I suspect; at
best, fixing this will make a malicious root marginally less damaging. The
real issue is just that the kernel is accepting unvalidated parameters
from userspace, and shooting itself in the foot with them. MS took a fair
bit of flak, IIRC, for doing this with WIN32K.SYS in NT4. Do we now expect
higher standards of design from NT than Linux? :-)
> The mechanism that everybody wants is _already_ there. It's called
> "permissions". No new driver code necessary.
>
> If those permissions do not work, then they don't work, and adding
> last-minute band-aids makes no difference.
>
> Just as a comparison, look at Windows.
No thanks - I've just eaten :-)
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.
> It takes the opposite approach: it has no real seurity, but a LOT of
> band-aids to avoid the "obvious" holes. Leaving it wide open.
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.
Other things like CPU microcode updates have sanity checking - why not do
the same here? HDD firmware upgrades can hardly be performance critical,
after all!
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