Re: why does mtrr use suser() and not capable(CAP_SYS_ADMIN)?

From: Matthew Kirkwood (weejock@ferret.lmh.ox.ac.uk)
Date: Wed Feb 16 2000 - 05:11:44 EST


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