linux-kernel - Re: [PATCH] block: avoid false positive warnings on ioctl to partition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4F394C35.1020908@redhat.com>
Date:	Mon, 13 Feb 2012 18:45:25 +0100
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Jens Axboe <axboe@...nel.dk>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/