On 02/13/2012 06:25 PM, Alan Cox wrote:

Firstly blocking CAP_SYS_RAWIO access by any means to a partition is
itself nonsense as the process has enough privilege to go poke the
controller I/O registers by hand.

What if a process has dropped all capabilities except CAP_SYS_RAWIO, and 
has permission to access to /dev/sdb1 and /dev/sda?  If ioctls are 
protected correctly, it will not be able to poke the I/O registers for 
/dev/sdb.  That's pretty much the point of this.

Secondly SG_IO allows users to read and write blocks outside their partition as
far as I can see from the verify logic.

Sure, I do not do any attempt to block anything for CAP_SYS_RAWIO, 
including reads/writes outside partitions.  As far as I undertsood Linus 
agreed to block SG_IO completely, except with a grace period during 
which CAP_SYS_RAWIO will still be able to use SG_IO arbitrarily.  During 
this time they'll get warnings but no change in SG_IO behavior.

What were the SG_IO command blocks that were caught ? It's going to be
pretty trivial to add a filter->partition_ok to some of them if need be.

INQUIRY and SYNCHRONIZE CACHE.  We certainly do not want to break the 
former right away; but given that the cause was a mistake in udev 
configuration, we can expect people to fix their rule files in 2012. 
But the latter was pointless because they should have just typed 
"apropos synchronize" and used fdatasync.

Sure, we can add something like filter->partition_ok and erect a 
security vulnerability to the status of feature.  It doesn't mean that's 
the right thing to do.

Anyway it fails both by stopping valid stuff and not stopping insecure and
unsafe stuff.

It is not "valid", it's at best "not harmful".

Paolo