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: <20121102235243.60dfa772@pyramind.ukuu.org.uk>
Date:	Fri, 2 Nov 2012 23:52:43 +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)

> > - giving people access to parts of disks
> 
> Are we gonna implement random range restriction inside a partition
> too?  If we want to check against partition ranges for allowed SG_IO
> commands, by all means, but it can easily be implemented as part of
> the fixed filter.

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.

> > - allowing access to specific vendor specific commands on certain
> >   non-standard CD and DVD drives so they can be used for burning but you
> >   can't trash them
> 
> At this point, most burning commands are standardized, and optical
> drives are generally on the way out.  If you absolutely have to use
> some vendor specific commands, be root.

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.

> > - giving end users minimal access to things like SMART but only on drives
> >   where it is safe
> 
> End users already have pretty good access to SMART data via udisks and
> it's way more flexible and intelligent than some in-kernel filter.

Thats a bit Gnome developer - "Our way or the highway". The point of
having a filter is that you put policy in user space. If you don't care
the default filter carries on just working, if you do care you can change
stuff with BPF.

> > - giving a user a SCSI disk or partition to play with but preventing them
> >   issuing weird ass commands that can disrupt other devices in the fabric
> >   (like drive to drive transfers, some kinds of resets, management
> >   commands)
> > - minimising the ability of a VM to do damage if compromised while
> >   maximising its raw access to a device
> 
> Maybe, I don't know.  It all sounds highly marginal to me.

If you are doing virtual machines it is far from marginal.

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

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/