lkml.org 
[lkml]   [2012]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] block: avoid false positive warnings on ioctl to partition
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


\
 
 \ /
  Last update: 2012-02-13 18:47    [W:0.050 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site