Linux-kernel mailing list archive 2000-07,: Re: why does mtrr use suser() and not capable(CAP_SYS_ADMIN)?

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

Matthew Kirkwood (weejock@ferret.lmh.ox.ac.uk)
Wed, 16 Feb 2000 10:11:44 +0000 (GMT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Bernhard Kaindl: "Re: Capturing the raw keyboard presses."
- Previous message: Rogier Wolff: "Re: [patch-2.3.46-p2] P6 microcode update support"
- In reply to: Richard Gooch: "Re: why does mtrr use suser() and not capable(CAP_SYS_ADMIN)?"

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/

- Next message: Bernhard Kaindl: "Re: Capturing the raw keyboard presses."
- Previous message: Rogier Wolff: "Re: [patch-2.3.46-p2] P6 microcode update support"
- In reply to: Richard Gooch: "Re: why does mtrr use suser() and not capable(CAP_SYS_ADMIN)?"