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:	Sat, 25 May 2013 13:14:37 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Tejun Heo <tj@...nel.org>
CC:	James Bottomley <James.Bottomley@...senPartnership.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))

Il 25/05/2013 10:37, Tejun Heo ha scritto:
> Hey, James.
> 
> On Fri, May 24, 2013 at 09:35:02PM -0700, James Bottomley wrote:
>>> Well, I'd actually much prefer disabling CDB whitelisting for all !MMC
>>> devices if at all possible.
>>
>> I'll go along with this.  I'm also wondering what the problem would be
> 
> Don't think we can.  It'd be a behavior change clearly visible to
> userland at this point.

We can (and even for MMC) if it is a build-time configuration knob.  It
would satisfy those people who want the CVE fixed, as long as userspace
gets some configurability.

> * Fix the security bug.  I don't really care how it's fixed as long as
>   the amount of whitelisted commands goes down not up.
> 
> * It's not like we can remove the filter for !MMC devices at this
>   point, so I think it makes sense to make it per-class so that we can
>   *remove* commands which aren't relevant for the device type.  Also,
>   we probably wanna add read blinking comment yelling that no further
>   commands should be added.
> 
> * Merge the patch to give out SG_IO access along with write access, so
>   the use cases which want to give out SG_IO access can do so
>   explicitly and be fully responsible for the device.  This makes
>   sense to me.  If one wants to be allowed to issue raw commands to
>   the hardware, one takes the full responsibility.

That's not possible; it would make it impossible to do things like using
a privileged helper to open the file and passing it back via SCM_RIGHTS
to an unprivileged program (running as the user).  This is the ptrace
attack that you mentioned.

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/