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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:18 EST