linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Tejun Heo <tj@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jens Axboe <axboe@kernel.dk>,
	lkml <linux-kernel@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542))
Date: Fri, 24 May 2013 21:35:02 -0700	[thread overview]
Message-ID: <1369456502.5008.5.camel@dabdike> (raw)
In-Reply-To: <CAOS58YODjkSF=V7wADqbn_z8c6bmj=r03hWxEs5B1O+1cd0n6g@mail.gmail.com>

On Fri, 2013-05-24 at 17:02 +0900, Tejun Heo wrote:
> On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >> The same filtering table being applied to different classes of
> >> hardware is a software bug, but my point is that the practive
> >> essentially entrusts non-insignificant part of security enforcement to
> >> the hardware itself.  The variety of hardware in question is very wide
> >> and significant portion has historically been known to be flaky.
> >
> > Unproven theory, and contradicted by actual practice.  Bugs are more
> > common in the handling of borderline conditions, not in the handling of
> > unimplemented commands.
> >
> > If you want to be secure aginst buggy firmware, the commands you have to
> > block are READ and WRITE.  Check out the list of existing USB quirks.
> 
> 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
if we just allowed all commands on either CAP_SYS_RAWIO or opening the
device for write, so we just defer to the filesystem permissions and
restricted read only opens to the basic all device opcodes.

>  You're basically arguing that because what
> we have is already broken, it should be okay to break it further.
> Also, RW commands having more quirks doesn't necessarily indicate that
> they tend to be more broken. They just get hammered on a lot in
> various ways so problems on those commands tend to be more noticeable.

I agree with this, so finding a way to get rid of the opcode table seems
to be what we need.

> > You need to allow more commands.
> > The count-me-out knob allows all commands.
> > You cannot always allow all commands.
> > Ergo, you cannot always use the count-me-out knob.

Do we have a real world example of this?  Getting the kernel out of the
command filtering business does seem to be a good idea to me.

> 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. Not ideal but widening direct
> command access by default is pretty nasty too.

James


  parent reply	other threads:[~2013-05-25  4:35 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-06 15:15 [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542) Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 01/14] sg_io: pass request_queue to blk_verify_command Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 02/14] sg_io: reorganize list of allowed commands Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 03/14] sg_io: use different default filters for each device class Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 04/14] sg_io: resolve conflicts between commands assigned to multiple classes (CVE-2012-4542) Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 05/14] sg_io: whitelist a few more commands for rare & obsolete device types Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 06/14] sg_io: whitelist another command for multimedia devices Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 07/14] sg_io: whitelist a few more commands for media changers Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 08/14] sg_io: whitelist a few more commands for tapes Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 09/14] sg_io: whitelist a few more commands for disks Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 10/14] sg_io: whitelist a few obsolete commands Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 11/14] sg_io: mark blk_set_cmd_filter_defaults as __init Paolo Bonzini
2013-02-06 15:15 ` [PATCH v2 12/14] sg_io: remove remnants of sysfs SG_IO filters Paolo Bonzini
2013-02-06 15:16 ` [PATCH v2 13/14] sg_io: introduce unpriv_sgio queue flag Paolo Bonzini
2013-02-06 15:16 ` [PATCH v2 14/14] sg_io: use unpriv_sgio to disable whitelisting for scanners Paolo Bonzini
2013-02-13  8:32 ` [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542) Paolo Bonzini
2013-02-13 15:35   ` Douglas Gilbert
2013-02-13 15:48     ` Paolo Bonzini
2013-02-20 16:12 ` Paolo Bonzini
2013-03-22 22:30   ` PING^2 " Paolo Bonzini
2013-04-04 18:18     ` PING^3 " Paolo Bonzini
2013-04-17 12:26       ` PING^4 aka The Jon Corbet Effect " Paolo Bonzini
2013-04-27 13:31         ` PING^5 aka New ways to attract attentions " Paolo Bonzini
2013-05-06 20:43   ` PING^6 " Paolo Bonzini
2013-05-22  6:35 ` PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542)) Paolo Bonzini
2013-05-22  9:32   ` Tejun Heo
2013-05-22  9:53     ` Paolo Bonzini
2013-05-22 10:02       ` Tejun Heo
2013-05-22 10:23         ` Paolo Bonzini
2013-05-22 12:07           ` James Bottomley
2013-05-22 14:07             ` Paolo Bonzini
2013-05-22 16:31               ` Paolo Bonzini
2013-05-22 13:41           ` Tejun Heo
2013-05-22 14:12             ` Paolo Bonzini
2013-05-22 14:30               ` Tejun Heo
2013-05-22 15:00                 ` Paolo Bonzini
2013-05-22 19:30                   ` Tejun Heo
2013-05-22 21:18                     ` Paolo Bonzini
2013-05-22 22:17                       ` Tejun Heo
2013-05-23  0:54                         ` Tejun Heo
2013-05-23  7:45                         ` Paolo Bonzini
2013-05-23  9:02                           ` Tejun Heo
2013-05-23  9:47                             ` Paolo Bonzini
2013-05-24  1:44                               ` Tejun Heo
2013-05-24  7:13                                 ` Paolo Bonzini
2013-05-24  8:02                                   ` Tejun Heo
2013-05-24  8:31                                     ` Paolo Bonzini
2013-05-24  9:07                                       ` Tejun Heo
2013-05-24  9:45                                         ` Paolo Bonzini
2013-05-24 22:20                                           ` Tejun Heo
2013-05-25  4:35                                     ` James Bottomley [this message]
2013-05-25  5:27                                       ` Christoph Hellwig
2013-05-25  7:05                                         ` Paolo Bonzini
2013-05-25  7:11                                           ` Christoph Hellwig
2013-05-25  7:21                                             ` Paolo Bonzini
2013-06-21 11:57                                           ` Christoph Hellwig
2013-05-25  8:37                                       ` Tejun Heo
2013-05-25 11:14                                         ` Paolo Bonzini
2013-05-25 12:48                                           ` Tejun Heo
2013-05-25 12:56                                             ` Paolo Bonzini
2013-05-22 15:03               ` Theodore Ts'o
2013-05-22 15:53                 ` Paolo Bonzini
2013-05-22 16:32                   ` Martin K. Petersen
2013-05-22 17:00                     ` Paolo Bonzini
2013-05-22 18:11                       ` Theodore Ts'o
2013-05-22 19:37                         ` Paolo Bonzini
2013-05-22 20:19                           ` Theodore Ts'o
2013-05-22 20:36                             ` Paolo Bonzini
2013-05-25  3:54                     ` Vladislav Bolkhovitin
2013-05-28 20:25                       ` Martin K. Petersen
2013-05-29  6:12                         ` Vladislav Bolkhovitin
2013-05-22 20:39                   ` Tejun Heo
2013-05-22 21:12                     ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1369456502.5008.5.camel@dabdike \
    --to=james.bottomley@hansenpartnership.com \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).