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: <20121102225912.GD27843@mtj.dyndns.org>
Date:	Fri, 2 Nov 2012 15:59:12 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
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)

Hello, Alan.

On Fri, Nov 02, 2012 at 08:48:25PM +0000, Alan Cox wrote:
> If you look back through the archive you'll find people have been
> spending a good decade bitching about the lack of filter configurability
> and trying to get someone else to fix it.
> 
> The BPF filter is simpler than just about any other implementation
> because the tools exist and are used for lots of other things and it has
> an API that is precisely defined as well as kernel calls to run the
> filter.

Sure, if we *have* to go for flexible filtering, BPF would be the
right way to do it.  I'm just not convinced such flexibility is
justified.

> Some reasons for it
> 
> - 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.

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

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

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

For complex/intelligent access policies, kernel isn't the right place
to do it anyway - you want strong integration with the rest of the
system especially for desktop.  Ones which can justify kernel-side
filtering would be things which are pretty low-level and require low
overhead.  I think VMs fall in this category, but then again being
able to bypass standard filters seems workable enough for that.  Sure,
an extra layer of filtering on top could be nice but again I just
don't think that's a strong enough justification.

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/