From owner-freebsd-arch@FreeBSD.ORG Wed Jul 31 11:58:24 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CD724461; Wed, 31 Jul 2013 11:58:24 +0000 (UTC) (envelope-from rabgvzr@gmail.com) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F7DD2D70; Wed, 31 Jul 2013 11:58:24 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id i11so302722qej.5 for ; Wed, 31 Jul 2013 04:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dK5TLSXbSx7vZSGSu8yK3Dj4fXZ+oyRsZxEycztGB18=; b=i8nt93h14JE8KMALHZa7S73IF09hCrIz7I8UnA7KCaC5R1UiHJLrhvaUgo2Jnmmlk4 Fk+I61bpol72A0DZh5NVEqDslYr37I82IIYkfzGfSvn4JcPNFTm0YyvkxhI7i3bJo61e cEfhpxeBnFWPuZaD7rd1owB1DI5l2SNJC0fMDuIex/K5/ENF7gaRApLts857AiNM3RPm QshCxaf2uaVATDewAEzjkwue7xL/DucIKLuWbbGvDroq2u2xqxoAw4SeeCjFozBuV6/m j5b2dcVe92n8KL7U35JOtAH3cO4if57DU0xZ3HweC9tlQ2E1f4HH2wWTUDGCb0FES3gj Z75A== MIME-Version: 1.0 X-Received: by 10.224.75.196 with SMTP id z4mr11937228qaj.20.1375271903589; Wed, 31 Jul 2013 04:58:23 -0700 (PDT) Received: by 10.49.74.1 with HTTP; Wed, 31 Jul 2013 04:58:23 -0700 (PDT) In-Reply-To: <447183917.20130731130956@serebryakov.spb.ru> References: <447183917.20130731130956@serebryakov.spb.ru> Date: Wed, 31 Jul 2013 11:58:23 +0000 Message-ID: Subject: Re: [PROPOSAL] GEOM probing/tasting firewall From: Rotate 13 To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arch@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:58:24 -0000 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 wrote: > condition ::= [not] ( 'class' ' | 'name' | 'path' ) > mask ::= > > '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. )