On Sun, 23 Jul 2000, Linus Torvalds wrote:
>
>
> On Sun, 23 Jul 2000, James Sutherland wrote:
> >
> > 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? :-)
>
> What validation?
>
> The OS doesn't even know what the commands do. They are undocumented. And
> they vary from drive to drive.
>
> How do you expect the OS to validate the drive firmware update commands
> for every drive manufacturer?
>
> In short, should we
>
> - know every single drive, know every command it can take, and do all of
> this inside the OS
>
> OR should we
>
> - move this policy into user space, and potentially have programs that
> know what different drives can do, and upgrade them the proper way
Or validate the commands listed in the SPEC for the default enable
interface, and grant unrestriced access to all command with a compile
option plus a sysctl flag that defaults in the off.
You will then no longer violate the usage of the SPEC by default.
You will preserve the drive warrenties, and protect the commerial
distribution market place for being liable for intent.
Specifically, it is public record that a distribution shipping without a
taskfile filter in ATA and SCSI (I have this now) to carry copablity of
knowingly with intent to sell product that allows no protection for
improper calls to the hardware.
All you have to do is provide a default approved filter, and include the
non-default option to disable the filter to not violate unix policies of
no-policies and cover linux and distrubtors from issues that can be deemed
actionable.
Upon the user disabling the command-filter, everyone is cleared of any and
all issues that can be deemed actionable, and make the individual
responsible for their actions and not you or the maintainers copablity.
This is all I want.........not to be sued in the future for decisions that
are not mine to be made.
Respectfully,
Andre Hedrick
The Linux ATA/IDE guy
-
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 : Mon Jul 31 2000 - 21:00:15 EST