Messages in this thread | | | Date | Wed, 16 Feb 2000 10:11:44 +0000 (GMT) | From | Matthew Kirkwood <> | Subject | 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/
| |