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: <20121103001905.6f894267@pyramind.ukuu.org.uk>
Date:	Sat, 3 Nov 2012 00:19:05 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Tejun Heo <tj@...nel.org>
Cc:	Paolo Bonzini <pbonzini@...hat.com>,
	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 Fri, 2 Nov 2012 16:58:11 -0700
Tejun Heo <tj@...nel.org> wrote:

> Hello, Alan.
> 
> On Fri, Nov 02, 2012 at 11:52:43PM +0000, Alan Cox wrote:
> > Really. Can your filter implement it only for certain commands, and only
> > for certain vendor specific commands ? Not really because your filter is
> > fixed - it has policy in kernel which is the wrong place for device
> > specific stuff.
> > 
> > And if you add it to the "fixed" policy how much code and ioctls is that
> > to specify ranges by command and pass partitions when they are device
> > mapper user space created mappings ? More code than the BPF interface and
> > more new APIs.
> 
> Hmmm?  You know which commands you're allowing.  You can definitely
> filter those commands for their ranges.  What ioctls?

How do you know what the rules are in kernel. If I'm locking you to fixed
mappings you have no idea in kernel what my user policy model is.

> > So that translates to me as "There is a good reason, but if your drive is
> > one of the awkward ones then f**k you go use root". Again policy in the
> > kernel just creates inflexibility and is the wrong place for it.
> 
> Yes, pretty much. 

Unfortunate and guaranteed to end up with problems not getting fixed
again - or having to redo the work a second time later on. Plus this is
but one example and you are blocking all the ones that haven't been
considered.

> > If you are doing virtual machines it is far from marginal.
> 
> Yeah, I agree VMs are the only one which isn't marginal, but then
> again, VMs can work reasonably well with far simpler mechanism.

I'm dying to see your "simpler mechanism" - I bet by the time you've
written the code it isn't simpler than calling the existing BPF logic.
Your kernel already has all the BPF stuff in it unless you are building
with no networking support so its essentially free.

The BPF execution is a call to sk_run_filter(). Is your mechanism simpler
than that ? It's also been closely audited.

> > > For complex/intelligent access policies, kernel isn't the right place
> > > to do it anyway
> > 
> > So why are you arguing for kernel policies which is exactly what the
> > fixed ones are ? The BPF ones moves the policy to user space !
> 
> No, it's doing something half-way inbetween in unnecessarily complex
> way when you can get by with much simpler mechanism.  We are stuck
> with the in-kernel whitelist for historical reasons (the proper way
> would be implementing burning service in userspace with proper
> integration with the rest of userland).  The in-kernel whitelist is

The burning service is one tiny example.

> broken for different classes of devices, so let's fix that in simple
> way and give userland a simple mechanism to solve the VM case.

Which you haven't done, because you've not provided a filter mechanism
that is flexible and takes policy from user space.

> It's unfortunate that we have this SG_IO filtering in kernel at all.
> Let's please not make it larger.

We have filtering because it is necessary. All you are doing is putting
off the inevitable by adding more kernel hack "one true kernel enforced
religion" policy and putting off the inevitable while adding APIs you'll
then have to maintain until the job is done right.

Ultimately policy has to be user space driven, adding more temporary
hacks is just a waste.

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