linux-kernel - Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices

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]

Message-ID: <CA+55aFxqy1wJFFVbykBJWuGm8YAjA-VP=xAqHttVOwC_zuxvOA@mail.gmail.com>
Date:	Thu, 22 Dec 2011 16:07:46 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	linux-kernel@...r.kernel.org, security@...nel.org,
	pmatouse@...hat.com, agk@...hat.com, jbottomley@...allels.com,
	mchristi@...hat.com, msnitzer@...hat.com
Subject: Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices

On Thu, Dec 22, 2011 at 3:48 PM, Alasdair G Kergon <agk@...hat.com> wrote:
> On Thu, Dec 22, 2011 at 02:25:56PM -0800, Linus Torvalds wrote:
>> I don't *think* anybody does something as crazy as giving actual block
>> device ownership to people,
>
> That can happen when running virtual machines backed by logical volumes.

So my worry is not so much the security fix for the vm case, but
simply normal people - who don't hit the issue to begin with - now
being screwed because what their distro does no longer works.

For example, I just traced it, and "eject /dev/sdb1" does a CDROMEJECT
ioctl when used as the root user. I haven't tested the patch, but just
reading it, I'd expect it to break that.

And that's the *natural* way to eject a mounted device. Look at the
USB memory sticks you have. They are almost all partitioned to have
one partition, and that one partition doesn't cover the whole device.
And it's that one partition you use to interact with it - it's what
you mount, and what you eject.

Breaking things like that is not an option. It's stuff people do every
day. And there may be some very non-obvious reason that I don't see
why it's not broken by this patch-series, but that's the kind of thing
that I worry about.

And I worry about it a *lot* more than I worry about some broken
virtualization setup where you have system engineers that could patch
their own kernel if they feel strongly about this. We simply
*must*not* break things.

I absolutely do not get the feeling that this has been tested so much
and is so obvious that there is no risk of breakage.

I suspect one thing that would be reasonable would be to just say
"Root can do any ioctl's he damn well wants on a partial device". That
would make me worry much less about the "normal" setup breaking where
you don't give regular users direct access to partitions to begin
with.

But even that might not work reliably. Maybe the system deamon that
actually does the eject (when a normal user does an eject) has been
setguid to 'disk' instead, and isn't root. I don't know. I doubt you
know either.  Maybe some of them have fallback code to find the parent
device. Do you know? Do you know that all do? I doubt it.

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