[PROPOSAL] GEOM probing/tasting firewall

[Rotate 13]

TL;DR: Please, make not the plugging in of arbitrary drive to cause
kernel to stick ring0 tongue in it. lev@ proposal is very good from my
userland perspective. Commentary:

On Wed, 31 Jul 2013 13:09:56 +0400, Lev Serebryakov <lev at FreeBSD.org> wrote:

> condition ::= [not] ( 'class' <mask>' | 'name' <mask> | 'path' <mask> )
> mask ::= <shell-like-glob>
>
>  'path' means "path in /dev hierarchy' here.

User comment: Need means to disable all taste on specific *physical*
hotplug port. I understand this is problem involving different
subsystems, and should be solved there; see recurrent threads on
freebsd-fs etc. about "wiring down" SATA ports, and let's not start
talking USB! But is not good when the emergency red port on front
panel could be /dev/da0, /dev/da1... (or if eSATA: /dev/ada8,
/dev/ada9... etc.). Class and name don't seem to solve this either?

> Of course, default last (and only one, if user does nothing) rule must be
>
> "enable taste by all"

User comment: Please make easiest to set "default deny" after startup!
 (Where to trigger this is userland problem, and good to solve in rc
scripts.) Simplest and best, and solves above problem with device
identification (from my perspective).

I lack kernel skills to build this bigger-thing-than-bikeshed; so I
will not talk more about the colour, except to say please "fail
closed". But, just a few words on why lev@ idea is The Right Thing
from my userland perspective.

Taste system is very convenient, good idea. I like it when I build new
system, or at boot without config headache, and the GEOM layers
magically snap together like Lego bricks. But it needs ability to be
turned off completely, when desired. I just looked for global "enable
tasting" sysctl, which can be set to false; specific already exist in
graid. And lev@ suggestion of the fine-grain control is best, if
easy/not complicated to switch on global "default deny" and then open
holes (i.e.: like firewall rules good, like devfs rules bad!). Think
use cases:

	* USB flash drive found in parking lot. (Set rule to wire down
specific USB port for untrusted media.)

	* Data recovery from known infected Windows hard disk (with unknown
evilness), attached through eSATA (so no good to hack up umass(4)).

	* Bob locks terminal, walks to water cooler. Mallory found bug in
some obscure GEOM, now has 30 seconds to stick in USB drive, pull it
out, and slip away.

	* Sysadmin who is just a control freak. Isn't FreeBSD appeal to
people who want system to do what it is told, *and nothing else*?

I am not kernel hacker, and I know very smart people write GEOMs. But
also, very smart people write VM subsystem (SA-13:06.mmap),
ring-change codes (SA-12:04.sysret), and filesystems (see mount(2)
manpage quoted at end here). (Not mentioning SA-11:05.unix, which was
really stupid.) And there are lot of GEOMs in base system, not
mentioning modular design encourages roll your own kld. Not all GEOMs
are written by the well-known GEOM hackers who write work-of-art C
code.

My policies: (a) Nothing to run automatically after the
carefully-configured boot+rc process, as much as possible. (b)
Everything do from userland, which can be done from userland. (c)
Trust system to not be "helpful" behind my back.

(
Referenced above: mount(2) manpage, emphasis on last sentence wise words:

BUGS
     Some of the error codes need translation to more obvious messages.

     Allowing untrusted	users to mount arbitrary media,	e.g. by	enabling
     vfs.usermount, should not be considered safe.  Most file systems in
     FreeBSD were not built to safeguard against malicious devices.

Taste codes much more simple than filesystems, yes; but is g_foo
tasting guaranteed absolutely bug-free?  I don't care how simple it
is: It runs in the kernel, and licks the USB stick from parking lot!
Ewww.
)