linux-kernel - Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs)

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: <1657557410.1945557.1351190120407.JavaMail.root@redhat.com>
Date:	Thu, 25 Oct 2012 14:35:20 -0400 (EDT)
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Ric Wheeler <rwheeler@...hat.com>,
	Petr Matousek <pmatouse@...hat.com>,
	Kay Sievers <kay@...hat.com>, Jens Axboe <axboe@...nel.dk>,
	linux-kernel@...r.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>
Subject: Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block:
 add queue-private command filter, editable via sysfs)


> On Thu, Oct 25, 2012 at 09:37:39AM +0200, Paolo Bonzini wrote:
> > Il 24/10/2012 18:47, Tejun Heo ha scritto:
> > > So, I'm still not convinced we need to go forward with full
> > > configurability. All use cases you described can be covered with
> > > per-class static filters + simple override switch to disable all,
> > > which would result in a lot simpler implementation w/ much
> > > smaller userland interface.
> > 
> > I'm not sure the userland interface would be smaller, and it would
> > be more complex to get right:
> > 
> > 1) how do you override the default?  ioctl+SCM_RIGHTS or sysfs?
> 
> 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.

> > 2) do you need to override the default to "no access", "full
> > access" and "default access", or is a binary knob (default
> > access/full access) sufficient?
> 
> Default / full should be enough, no?

If a ioctl has to be added, I'd rather have at least none/full/default.

> > 3) what capabilities control the setting?
> 
> CAP_SYS_RAWIO seems to be a pretty good fit.

Yes, for a ioctl it is (for sysfs CAP_SYS_ADMIN is better IMHO).

> 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).

> I'm not trying to block it at all cost but let's make sure we looked
> into most possibilities before (re)adding this userland visible
> interface.

Sure, understood. :)

> Jens, James, what do you guys think?

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/