linux-kernel - Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG

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:	Fri, 24 May 2013 18:07:11 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	"James E.J. Bottomley" <JBottomley@...allels.com>,
	Jens Axboe <axboe@...nel.dk>,
	lkml <linux-kernel@...r.kernel.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of
 the SG_IO command whitelist (CVE-2012-4542))

On Fri, May 24, 2013 at 5:31 PM, Paolo Bonzini <pbonzini@...hat.com> wrote:
> I agree intuition may not count, and it's perfectly possible that
> firmware writers forgot a "break;" or put the wrong location in a jump
> table, so that unimplemented commands give interesting results.

It's not just unimplemented commands. Exposing any new command exposes
its borderline problems together with it.

> However, the _fact_ is that this might happen anyway with the buttload
> of commands that are already enabled by the whitelist and that most
> disks will never implement.

Yes and that's why the whitelist is generally frowned upon. It's
inherently fragile. These devices simply aren't designed and
implemented to be exposed to lesser security domains directly. It's
true that it's already kinda broken that way but as I wrote before
it's a vicious cycle and we don't wanna keep building on top of it.
This expansion is gonna increase the usage of whitelisting which will
in turn attract further use cases which are likely to call for even
more expansion.

>> The thing is that both approaches aren't perfect here so you can make
>> similar type of argument from the other side. If the system wants to
>> give out raw hardware access to VMs, requiring it to delegate the
>> device fully could be reasonable.
>
> No, it is not unfortunately.  Allowing to do discards is one thing,
> allowing to disrupt the settings of a SAN is another.  You can only
> delegate the device fully in these cases:
>
> (a) of course, if the guest is trusted;
>
> (b) if QEMU is running as a confined user, then you can get by with a
> userspace whitelist.  (Otherwise you're just a ptrace away from
> arbitrary access, as you pointed out).
>
> Unfortunately, there are _real_ problems that this patches fix, such as
> log spews due to blocked commands, and these happen even if neither of
> the above conditions is true.
>
> Is there anything else I can do?  Sure, I can check for the presence of
> the whitelist and hack the VPD pages to hide features that I know the
> whitelist will block.  Is it the right thing to do?  In my opinion no.
> It makes no sense to have raw device access _disable_ features compared
> to emulation.

If the bulk of filtering can be solved with userland whitelisting as a
confined user, it should be possible to resolve peripheral problems
like log messages in simpler way, no? Can you please elaborate on the
log message problem? Who's spewing those messages?

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