Messages in this thread | | | Date | Sat, 22 Jul 2000 12:17:00 +0100 (BST) | From | James Sutherland <> | Subject | Re: disk-destroyer.c |
| |
On Sat, 22 Jul 2000, David Luyer 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.
Nope. Capabilities mean SFA to root ATM: root can just bypass them all. Not a very useful `feature', but hard to remove I suspect.
> 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.)
Root can bypass every piece of sanity and security checking in the kernel ATM. This isn't a feature, it's a bug, but there's not much that can be done about it ATM. In the meantime, we should just make sure the checking is as sane as possible.
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/
| |