All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Ric Wheeler <rwheeler@redhat.com>,
	Petr Matousek <pmatouse@redhat.com>, Kay Sievers <kay@redhat.com>,
	Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Subject: Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs)
Date: Fri, 02 Nov 2012 15:49:02 +0100	[thread overview]
Message-ID: <5093DD5E.6030808@redhat.com> (raw)
In-Reply-To: <20121031212241.GZ2945@htj.dyndns.org>

Il 31/10/2012 22:22, Tejun Heo ha scritto:
> Hello, Paolo.
> 
> On Thu, Oct 25, 2012 at 02:35:20PM -0400, Paolo Bonzini wrote:
>>> Disabling filters if opened by root and tranfering via SCM_RIGHTS
>>> would be the simplest interface-wise (there's no new interface at
>>> all).  Would that be too dangerous security-wise?
>>
>> That would be a change with respect to what we have now.  After
>> transferring a root-opened (better: CAP_SYS_RAWIO-opened) file
>> descriptor to an unprivileged process your SG_IO commands get
>> filtered.  So a ioctl is needed if you want to rely on SCM_RIGHTS.
> 
> Yeah, I get that it's a behavior change, but would that be a problem?

Worse, it's a potential security hole because previously you'd get
filtering and now you wouldn't.

Considering that SCM_RIGHTS is usually used to transfer a file
descriptor from a privileged process to an unprivileged one, I'd be very
worried of that.

>>> I guess I just feel quite reluctant to expose another rather obscure
>>> userland configurable in-kernel filter and at the same time I'm not
>>> sure whether this is flexible enough.  What if a device is shared by
>>> multiple virtual machines which are trusted at different levels?
>>
>> No, you just don't do that.  If a device is passed through to virtual
>> machines, it is between similar virtual machines (for some definition
>> of similar).  The only case where you have this sharing is in practice
>> if either the device is read-only (my patch does give you a basic
>> two-level filtering, with two separate bitmaps for RO and RW) or if you
>> allow persistent reservations (which is as close to full trust as you
>> can get).
> 
> What disturbs me is that it's a completely new interface to userland
> and at the same a very limited one at that.  So, yeah, it's
> bothersome.  I personally would prefer SCM_RIGHTS behavior change +
> hard coded filters per device class.

I think hard-coded filters are bad (I prefer to move policy to
userspace), and SCM_RIGHTS without a ioctl is out of question, really.

> But, I'd really like to hear what other guys are thinking.  Jens?
> Jens? Jens? Jens? Jens? Jens? Jens? Jens? Jens? Jens? Jens? Jens? :P

:P

Paolo


  reply	other threads:[~2012-11-02 14:49 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-25 15:30 [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs Paolo Bonzini
2012-09-25 15:30 ` [PATCH v2 1/3] block: add back queue-private command filter Paolo Bonzini
2012-09-25 15:30 ` [PATCH v2 2/3] scsi: create an all-zero filter for scanners Paolo Bonzini
2012-09-25 15:30 ` [PATCH v2 3/3] block: add back command filter modification via sysfs Paolo Bonzini
2012-10-04 10:12 ` [PATCH v2 0/3] block: add queue-private command filter, editable " Paolo Bonzini
2012-10-04 10:12   ` Paolo Bonzini
2012-10-19  0:22   ` Tejun Heo
2012-10-19  9:07     ` Paolo Bonzini
     [not found]       ` <2007908429.13363375.1350637872646.JavaMail.root@redhat.com>
     [not found]         ` <20121019201058.GP13370@google.com>
     [not found]           ` <5087E093.50700@redhat.com>
     [not found]             ` <CAOS58YM5ZO9h0XUCNxV+6U3UzpeUen5ZuyqsNEUaJ81ux=QKvw@mail.gmail.com>
     [not found]               ` <5088EC43.2010600@redhat.com>
2012-10-25 18:00                 ` setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs) Tejun Heo
2012-10-25 18:35                   ` Paolo Bonzini
2012-10-31 12:52                     ` Paolo Bonzini
2012-10-31 21:22                     ` Tejun Heo
2012-11-02 14:49                       ` Paolo Bonzini [this message]
2012-11-02 15:35                         ` Alan Cox
2012-11-02 16:48                           ` Tejun Heo
2012-11-02 17:21                             ` Alan Cox
2012-11-02 17:30                               ` Tejun Heo
2012-11-02 20:18                                 ` Alan Cox
2012-11-02 20:21                                   ` Tejun Heo
2012-11-02 20:48                                     ` Alan Cox
2012-11-02 22:59                                       ` Tejun Heo
2012-11-02 23:52                                         ` Alan Cox
2012-11-02 23:58                                           ` Tejun Heo
2012-11-03  0:19                                             ` Alan Cox
2012-11-03  0:23                                               ` Tejun Heo
2012-11-03  0:52                                                 ` Alan Cox
2012-11-02 16:51                         ` Tejun Heo
2012-11-02 17:49                           ` Paolo Bonzini
2012-11-02 17:53                             ` Tejun Heo
2012-11-03 13:20                               ` Paolo Bonzini
2012-11-03 14:50                                 ` Alan Cox
2012-11-05 11:08                                   ` Paolo Bonzini
2012-11-05 18:18                                   ` Tejun Heo
2012-11-05 20:12                                     ` Alan Cox
2012-11-05 20:09                                       ` Tejun Heo
2012-11-05 20:17                                         ` Alan Cox
2012-11-05 20:15                                           ` Tejun Heo
2012-11-05 18:26                                 ` Tejun Heo

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=5093DD5E.6030808@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=axboe@kernel.dk \
    --cc=kay@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmatouse@redhat.com \
    --cc=rwheeler@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.