On Wed, 16 Feb 2000, Richard Gooch wrote:
> > > Is there any reason why does mtrr (e.g. mtrr_ioctl()) use the old
> > > suser() instead of the new capable() (e.g. CAP_SYS_ADMIN seems the
> > > closest) to do permission check?
> >
> > I don't know about the reason, but I would prefer CAP_SYS_RAWIO, if
> > it's messing with hardware settings.
> Frankly, before you start messing with replacing suser(), I'd rather
> that we hammer out the exact meaning of capability bits, and what the
> "range" of each bit is. The very fact that there are two separate
> suggestions for which bit to use for MTRR bothers me: the decision
> should be obvious from the documentation on capabilities. It leaves me
> less than lukewarm about capabilities.
As far as I'm concerned, CAP_SYS_RAWIO is obvious. A fairly
shocking amount of stuff appears to fall under the CAP_SYS_ADMIN
banner, and I don't think that messing with hardware settings,
directly or otherwise, should be included there. I think that
CAP_SYS_RAWIO rather fits, but CAP_SYS_ADMIN certainly doesn't.
CAP_SYS_RAWIO defends from user programs:
* poking at hardware
* changing hardware settings via the kernel
My intention with the small patches which went into 2.2 and
2.3 was that by turning off CAP_SYS_RAWIO and CAP_SYS_MODULE
(the purpose of which is fairly clear) it should, in theory,
be impossible to subvert the kernel or kill the box.
I have a patch which turns a lot of CAP_SYS_ADMINs into
CAP_SYS_RAWIO, for things like serial device config ioctls,
writes to /proc/bus/pci, etc.
The onlycomplaint I can imagine about it is that some of
thee things should perhaps fall under CAP_SYS_HWCONFIG, as
it could be argued that they don't quite fit under the
original CAP_SYS_RAWIO.
Matthew.
-
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 : Wed Feb 23 2000 - 21:00:14 EST