linux-kernel - Re: [PATCH] scsi: Silence unnecessary warnings about 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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 May 2012 13:05:31 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Jan Kara <jack@...e.cz>, Jens Axboe <axboe@...nel.dk>,
	LKML <linux-kernel@...r.kernel.org>,
	James Bottomley <JBottomley@...allels.com>,
	linux-scsi@...r.kernel.org
Subject: Re: [PATCH] scsi: Silence unnecessary warnings about ioctl to
 partition

> not inventing anything, the old ATA subsystem is already blocking most
> "dangerous" ioctls for partitions, even if you have CAP_SYS_RAWIO.

It blocked a few by default to protect hardware. It's a tricky tradeoff,
which is quite different to this.

> Now of course CAP_SYS_RAWIO lets you use ioperm or iopl, but that's a
> separate issue and only limited to x86.

Ie only 99.99% of the systems running desktop/server Linux OS designs.

> Almost any capability can be abused to bypass checks.  True,
> CAP_SYS_RAWIO is especially good at that, but still you can try.

Why try - you are seeking to arbitarily impose your own worldview on the
interface (and in doing so break back compatibility). The whole basis of
the Unix philosophy is that the OS shouldn't try and micromanage the
priviledged apps because that just leads to crap code.

Think "small government" on this aspect of design. And with the patch you
propose the analogy for your patch is the TSA.

> > A process with CAP_SYS_RAWIO has total power. It's assumed to know what
> > it is doing. Trying to block it doing stuff like that simply makes
> > authors do them via different more crass methods.
> 
> Getting appropriate permission on device nodes is less crass than
> abusing partition device nodes.

Given a passed file handle how do you do that securely. Remember that
open /dev/foo while you have a handle on /dev/foo1 could open a
different disk if a hotplug has occurred.

So there are good reasons to keep the partition behaviour.

Alan

--
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/