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]

Date:	Mon, 5 Nov 2012 10:26:08 -0800
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)

Hey, Paolo.

On Sat, Nov 03, 2012 at 02:20:14PM +0100, Paolo Bonzini wrote:
> As to implementing the ioctl, it's all but trivial.  For one thing, you
> have to make the block device ioctl op take a "struct file".  I have
> been asking Al Viro about it for 6 months and I haven't got any answer yet.

I don't think that really matters.  If necessary, just change it.

> Second, getting a security-sensitive ioctl right is hard, as you
> demonstrated yourself in this thread by proposing a gapingly insecure
> approach.  Adding a little bit of customization to the current solution
> may be but a local optimum, but you cannot really get it wrong.

Eh?  Sure, I was in "who cares about SG_IO?" area a bit but that has
nothing to do with the interface being an ioctl.  It's a binary switch
ioctl, it's not too difficult to get right.

> Because _this_ is the simplest possible.

I guess we'll have to agree to disagree.  This is way more complex.
You need to review what's going on with the userland tools and inspect
weird sysfs files to actually know what the system policy is.

> I proposed a way to implement the ultimately flexible solution (BPF) and
> you shot it down because it was too complex.  Alan is showing you with
> multiple examples of why the flexibility would be useful (perhaps nobody
> would use it, but the use cases _are_ there), and you are mostly
> ignoring them.

The only valid use case was using proprietary commands during CD
burning.  At this point, that's a really really minor use case IMHO.
I think adding full BPF filtering on SG_IO for that is rather silly.

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/