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: <20121103005210.1f66b568@pyramind.ukuu.org.uk>
Date:	Sat, 3 Nov 2012 00:52:10 +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)

> So, my first response was whether you mean to add arbitrary range
> filtering for standard read/writes too.  If you're not gonna do that

Thats relevant for /dev/sd but not /dev/sg. Now it might be the sane
thing to do is to support BPF filters on /dev/sg only ?

> But we should't add features for the ones which haven't been
> considered.  Unless you can actually justify with actual use cases,
> it's just hand waving.

The CD writer one isn't but you tried to dismiss that too. 

> The suggested mechanism is just having a switch to allow all SG_IO
> commands and pass it to the hypervisor.  There's no filtering in
> kernel at all.

That requires you have a very trusted hypervisor, that to me is a
weaker model because it increases the probability that a hack on a
guest of a cloud becomes a hack of the cloud itself at least in terms of
quiet data theft from other guests. It's still a minor risk because
you've got to break the guest then break the hypervisor from guest
virtual ring 0, but the hypervisor is a large target,

For a lot of cases being able to do the filtering in the hypervisor makes
sense and I don't have a problem with that except that you do need to
enforce CAP_SYS_RAWIO on the process setting the flags or you break the
kernel capability model. For a hypervisor guest flipping flags at boot
thats not a big deal.

> > 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.
> 
> Exactly, let's provide a turn-off switch for in-kernel filtering and
> let userland drive any appropriate access policy on it.  Let's please
> stay away from doing deep packet inspecting on SG_IO commands.

And you've left stuff like CD burning broken still despite people pointing
out for years that sorting out the filtering would fix it.

> I don't think we're disagreeing on the principle.  It's just that
> we're drawing different where the line lies between mechanisms and
> policies.

On the CD burning case and on generality I think we are disagreeing in
principle. Which isn't to say there is a right answer and one of us is an
idiot, just that there are things to consider carefully here.

IMHO you are hacking kernel policy by a magic flag to support a specific
problem case, not fixing the problem. The question is whether the problem
needs fixing 8)

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/