From owner-freebsd-current Sun May 31 13:50:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA18864 for freebsd-current-outgoing; Sun, 31 May 1998 13:50:09 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18787 for ; Sun, 31 May 1998 13:49:57 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id NAA17705; Sun, 31 May 1998 13:49:56 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpd017686; Sun May 31 13:49:54 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA12752; Sun, 31 May 1998 13:49:51 -0700 (MST) From: Terry Lambert Message-Id: <199805312049.NAA12752@usr06.primenet.com> Subject: Re: I see one major problem with DEVFS... To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Sun, 31 May 1998 20:49:50 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, current@FreeBSD.ORG In-Reply-To: <3354.896616697@critter.freebsd.dk> from "Poul-Henning Kamp" at May 31, 98 02:11:37 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >If a device is removed from a chroot environment, it should be impossible > >to recreate it. > > > >The reasoning should be obvious. > > But the argument is nontheless badly flawed. > > This should be done by disallowing mknods by chrooted processes if > such security is desired. If you disallow all mknods by all processes, then they will be disallowed by chrooted processes, which are a subset of the set of all processes. 8-). The mknod code should go away for anything but named pipes; and since FreeBSD has mkfifo for that case, it should go away, period. If you want a node that is already there, but want it by a different name, then you should use "ln" or "link(2)". That's the method, as I understand Julian's explanation of the security model. Maybe it's time to document the security model, critique it, then refine it, then implement to the documentation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message