On Sat, 22 Jul 2000, Miquel van Smoorenburg wrote:
> According to James Sutherland:
> > On 21 Jul 2000, Miquel van Smoorenburg wrote:
> > > It _is_ possible. Check out "capabilities".
> >
> > It isn't possible. Root can bypass them all completely, as long as
> > /dev/kmem etc. exist.
>
> If CAP_SYS_RAWIO isn't set, even root cannot open /dev/mem /dev/kmem
> and /dev/port. Read linux/char/mem.c, check open_port etc
Now, if only that were actually honoured properly by the kernel (it isn't
yet - this particular piece of kernel does NOT require this cap yet), AND
it were not present on any process except under very special circumstances
(i.e. a firmware update tool or similar), we'd be OK.
> > Shall we delete capabilities on this basis? I think
> > not - so why apply that argument to Andre's bugfix?
>
> Well no, as many others have pointed out, it's the other way around-
> capabilities should be applied to everything that gives access to
> some hardware's firmware programming interface.
The "correct" solution, IMO, is twofold:
1. Require and enforce CAP_SYS_RAWIO for this area of kernel. Not doing so
ATM is surely a clear bug?
2. When a use is found for prodding the hardware directly for this, make
sure it is NOT done from userspace directly - provide a suitable kernel
API, with appropriate sanity checks. There is a clear precedent for this;
look at the CPU microcode updates, for example. The kernel handles this,
and WILL prevent you from loading the `wrong' update (an earlier version,
or the wrong CPU's microcode, for example).
We should be able to avoid ANY normal need to bypass the kernel and hit
the hardware directly for this sort of thing; if you are trying to perform
a firmware upgrade, do it via /dev/hda-firmware or whatever, NOT by doing
an end-run around the kernel and giving userspace omnipotence. If I wanted
a truly unprotected/unrestricted root, I'd be running MS DOS...
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:19 EST