Alan Cox wrote:
> > subvert the mechanism. Being 'root', with no CAP's, I could probably write to
> > /dev/mem or /dev/kmem I would think. So we can't get too smug about protection.
>
> The intention of CAP_SYS_RAWIO is that it takes away _all_ ability to talk
> directly to hardware. That includes /dev/mem and /dev/kmem.
--- Hmmm. Not that I can say that is "bad", but it does confuse security policy w/respect to DAC. Root normally has r/w to the files it owns. Under normal circumstances, if I wanted to prevent that on a CAP based system, I'd assign ownership of raw-io devices to a user 'rawio' with pw '*' and group 'rawio' with a password. In that event, does CAP_SYS_RAWIO override the DAC controls on a file (assuming, of course, that root is not running with CAP_DAC_OVERRIDE). I can't think of circumstances where CAP_SYS_RAWIO is needed if DAC controls are properly configured. If a sysadmin who has the 'root' password, if they needed RAWIO, they could be given the rawio group password and newgrp to that group -- perform their actions, then exit. Sorry to be dense, but are there areas where that wouldn't work?-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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 Apr 23 2000 - 21:00:09 EST