In <Pine.LNX.4.10.10007230932240.7428-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
> 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?
Maintability and clear design as usual.
-- cut --
Finally, even if the above isn't true, I often reject bug-fixes.
Bug-fixes are _often_ worse than the bug they fix, even with serious bugs.
Because a lot of bug-fixes are "band-aid" - not fixing the bug properly.
And band-aid is BAD. It's worse than even a crashing machine. Because
band-aid never goes away, and nobody cleans it up.
Geert, go away. You don't seem to understand what being a maintainer
means. It means saying no to crap.
Linus
-- cut --
It was said long ago. You KNEW that it's how linux is developed when you are
switched to it. So you must accept this style of development or go to other
camp (FreeBSD, NetBSD, HURD or even MAC OS or BeOS -- there are enough).
> 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...
It's YOUR house so it's up to you to decide. Linux is Linus's pet so it's to
him to decide.
>> 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.
And still patch was presented mainly as security fix :-) Guess why ? Since
new features are MUCH less encouraged in deep code-freeze (let alone stable
branch).
> The real issue is just that the kernel is accepting unvalidated parameters
> from userspace, and shooting itself in the foot with them.
Kernel DOES NOT shoot iself in the foot with bad HDIO_DRIVE_CMD parameters.
It's not kernel interface at all. It's more like fclose(3) : GLibC will do
some things with FILE * enveliope and then will pass filehandle to close(2).
It WILL NOT try to safeguard kernel from itself.
> 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.
Even if parameters were given to kernel just to be passed in other place ?
Huh.
> It doesn't matter what user or capability set the process has - it can
> still only pass valid parameters.
Not at all. We know some functions are dangerous (like chown, for example).
Thus not everyone can use them. This function is dangerous due to bad hardware
design. I makes no difference: FOR KERNEL all possible HDIO_DRIVE_CMD are safe.
Just like UID=500 for chown is not better then UID=15. Still FOR SYSTEM AS
WHOLE (usersapce+kernel+hardware) there are BIG difference. So call is
restricted so only tructed processes can issue chown or HDIO_DRIVE_CMD.
This is ALL protection kernel can (and should) offer.
> Where a parameter is being accepted unchecked, the code in question is
> regarded as a bug, and fixed as such.
The only problem is that said code is in HDD firmware, NOT in kernel.
>> 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 such it does not belond to 2.4 kernel in code-freeze time.
> 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.
Kernel-specific binary kernel modules are somehow better ?
> Other things like CPU microcode updates have sanity checking - why not do
> the same here?
Since it's NOT inteface for firmware upgrades. It CAN BE used for this. It
can be used for other things as well. Plus we HAVE NO information needed to
do sanity checks.
> HDD firmware upgrades can hardly be performance critical, after all!
-
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