lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectDo we need papering the hole or proper fix ? (was Re: disk-destroyer.c)
In <200007220225.MAA26318@typhaon.pacific.net.au> David Luyer (david_luyer@pacific.net.au) wrote:
>> Think about this: there are situations where root *MUST* be subject to
>> various restrictions (via capabilities, immutable files, etc). If root is
>> able to talk directly to the hardware, these restrictions become
>> unenforcable - security just went out of the window. This is unacceptable:
>> Linux must not do it. (Or rather, it must be possible to prevent Linux
>> doing it.)

> Root can only talk directly to the hardware when given appropriate
> capabilities - CAP_RAW_IO I believe.

And this is NOT the case here. You need ONLY CAP_SYS_ADMIN to use
HDIO_DRIVE_CMD , not CAP_SYS_RAW. And THAT can (and should) be fixed.
Kernel SHOULD NOT try to prevent exploits, but kernel MUST prevent
access to hardware when user (and root!) have no rights to do so.
Unfortunatelly Andre goes completely other way: ide.2.4.0-t5-2.all.4c.patch.bz2
does not have CAP_SYS_RAW word at all !

> If anything Andre should just be looking at adding that capability to
> the accesses which allow you to destroy things - because those same
> ioctls potentially serve useful purposes (yes, one day you will want
> to upgrade your drive firmware without running DOS/Win - I already
> don't have DOS/Win on any of my computers or laptops, the closest I
> have to it is a small portion microcode from the Hollywood Plus driver
> extracted to use with the Linux driver for that card...).

> And believe it or not, on a laptop which is only ever used behind a
> company firewall or when dialed up over a rather securely filtered
> dial-up, the chances of someone locating it on a dynamic IP and
> hacking root given no access to any open ports are somewhat more
> remote than the chance of the drive vendor developing a firmware
> upgrade tool for Linux, given appropriate interfaces.

> Remember, as long as root can insert a module root can re-write the
> kernel security model from the inside... and as soon as root can't
> insert a module you've removed popular functionality. (Personally I
> don't use modules but honestly - the vast majority do and probably
> always will.)





-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.318 / U:0.060 seconds]
©2003-2014 Jasper Spaans. Advertise on this site