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-next>] [day] [month] [year] [list]

Date:	Thu, 25 Oct 2012 11:00:45 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Paolo Bonzini <pbonzini@...hat.com>
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)

(restoring cc lists)

Hey, Paolo.

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?

> 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?

> 3) what capabilities control the setting?

CAP_SYS_RAWIO seems to be a pretty good fit.

> > What's the rationale for full configurability?
> 
> Depending on the level of trust you have in your users, there are
> different policies that are applicable.  Even virtualization could have
> a range of choices like "permit only standard operations", "also permit
> UNMAP", "also permit persistent reservations", "permit everything
> including vendor specific commands"

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?  What
if we end up actually having to filter cdb contents?

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.

Jens, James, what do you guys think?

Thanks.

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