From owner-freebsd-security Sun Jul 6 11:28:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA00879 for security-outgoing; Sun, 6 Jul 1997 11:28:09 -0700 (PDT) Received: from chaos.amber.org (root@chaos.amber.org [205.231.232.12]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA00872 for ; Sun, 6 Jul 1997 11:28:06 -0700 (PDT) Received: from [205.231.232.194] (ab2-002.dial.nova.org [205.231.232.194]) by chaos.amber.org (8.7.5/8.6.12) with SMTP id OAA23298; Sun, 6 Jul 1997 14:27:51 -0400 (EDT) Message-Id: <199707061827.OAA23298@chaos.amber.org> Subject: Re: Security Model/Target for FreeBSD or 4.4? Date: Sun, 6 Jul 97 14:27:48 -0400 x-sender: petrilli@mx.amber.org x-mailer: Claris Emailer 2.0, March 15, 1997 From: Christopher Petrilli To: "Jordan K. Hubbard" , "Colman Reilly" cc: "Adam Shostack" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard (jkh@time.cdrom.com) on 7/5/97 7:47 PM: >> I also spent a couple of hours fighting with Alta Vista looking for relevant >> documents and didn't find very much. Any other suggestions? > >/usr/src? :) > >Seriously, I doubt you'll find that anyone has sat down and documented >this aspect of the system specifically. If you want to study the >security implementation in detail, the sources remain the first and >foremost resource. In fact, they probably represent the ONLY resource. >Good luck! I will note that there has been off and on talk of a C2 certified FreeBSD implementation, which would require documentation. I think it's important to understand that few OSes (outside the "big boys" like VMS, MVS, VM, GUARDIAN, etc.) have documented formal security polcies. Mostly it's just whatever a programmer feels like. Christopher -- | Christopher Petrilli "That's right you're | petrilli@amber.org not from Texas." From owner-freebsd-security Sun Jul 6 14:50:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA07552 for security-outgoing; Sun, 6 Jul 1997 14:50:59 -0700 (PDT) Received: (from jmb@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA07546; Sun, 6 Jul 1997 14:50:47 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199707062150.OAA07546@hub.freebsd.org> Subject: Re: Security Model/Target for FreeBSD or 4.4? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 6 Jul 1997 14:50:46 -0700 (PDT) Cc: careilly@monoid.cs.tcd.ie, adam@homeport.org, freebsd-security@FreeBSD.ORG In-Reply-To: <13612.868146464@time.cdrom.com> from "Jordan K. Hubbard" at Jul 5, 97 04:47:44 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > > I also spent a couple of hours fighting with Alta Vista looking for relevant > > documents and didn't find very much. Any other suggestions? > > /usr/src? :) > > Seriously, I doubt you'll find that anyone has sat down and documented > this aspect of the system specifically. If you want to study the > security implementation in detail, the sources remain the first and > foremost resource. In fact, they probably represent the ONLY resource. > Good luck! in a nutshell, the security model is "you must have permission to do something". the superuser (aka root: uid 0) is can do anything. command audit trail (logging) is not provided. the holes have been in the implementation of that model. the source shows the implementation. which has been of greatly varying quality regarding security. ;( jmb From owner-freebsd-security Sun Jul 6 15:33:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA08957 for security-outgoing; Sun, 6 Jul 1997 15:33:15 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA08950; Sun, 6 Jul 1997 15:33:10 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id PAA20728; Sun, 6 Jul 1997 15:21:15 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id SAA13458; Sun, 6 Jul 1997 18:21:14 -0400 (EDT) Date: Sun, 6 Jul 1997 18:21:13 -0400 (EDT) From: Brian Mitchell To: "Jonathan M. Bresler" cc: "Jordan K. Hubbard" , careilly@monoid.cs.tcd.ie, adam@homeport.org, freebsd-security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <199707062150.OAA07546@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 6 Jul 1997, Jonathan M. Bresler wrote: > Jordan K. Hubbard wrote: > in a nutshell, the security model is > "you must have permission to do something". > the superuser (aka root: uid 0) is can do anything. > command audit trail (logging) is not provided. > the holes have been in the implementation of that model. > the source shows the implementation. which has been of greatly > varying quality regarding security. ;( > jmb > I'm not sure that's entirely corrent - superuser, for instance, can not (with the exception of holes in various subsystems...) lower the securelevel. I'm not sure what you mean by command audit trail, but process accounting is available, and is pretty darned close to logging commands. Stuff like syscall level accounting such as available in sun's bsm stuff is, unfortunately, not available presently. Brian Mitchell brian@firehouse.net "BSD code sucks. Of course, everything else sucks far more." - Theo de Raadt From owner-freebsd-security Sun Jul 6 17:14:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA13091 for security-outgoing; Sun, 6 Jul 1997 17:14:33 -0700 (PDT) Received: (from jmb@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA13078; Sun, 6 Jul 1997 17:14:12 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199707070014.RAA13078@hub.freebsd.org> Subject: Re: Security Model/Target for FreeBSD or 4.4? To: brian@firehouse.net (Brian Mitchell) Date: Sun, 6 Jul 1997 17:14:11 -0700 (PDT) Cc: jmb@FreeBSD.ORG, jkh@time.cdrom.com, careilly@monoid.cs.tcd.ie, adam@homeport.org, freebsd-security@FreeBSD.ORG In-Reply-To: from "Brian Mitchell" at Jul 6, 97 06:21:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brian Mitchell wrote: > > On Sun, 6 Jul 1997, Jonathan M. Bresler wrote: > > > Jordan K. Hubbard wrote: > > in a nutshell, the security model is > > "you must have permission to do something". > > the superuser (aka root: uid 0) is can do anything. > > command audit trail (logging) is not provided. > > the holes have been in the implementation of that model. > > the source shows the implementation. which has been of greatly > > varying quality regarding security. ;( > > jmb > > > > I'm not sure that's entirely corrent - superuser, for instance, can not a nutshell is never entirely correct. securelevels were introduced in 4.4BSD, if i remember correctly. they are an innovation > (with the exception of holes in various subsystems...) lower the > securelevel. I'm not sure what you mean by command audit trail, but > process accounting is available, and is pretty darned close to logging command logging is one example of the more rigorous control that some other systems have. mind they are a royal pain. they remember ever passwd you have used for xx months and refuse all attempts to re-use them, while at teh same time expiring passwords every xx days. but no one uses reuseable passwords anymore, right ;) jmb > commands. Stuff like syscall level accounting such as available in sun's > bsm stuff is, unfortunately, not available presently. From owner-freebsd-security Mon Jul 7 01:47:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA03423 for security-outgoing; Mon, 7 Jul 1997 01:47:48 -0700 (PDT) Received: from monoid.cs.tcd.ie (ts07-12.dublin.indigo.ie [194.125.148.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA03414; Mon, 7 Jul 1997 01:47:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with SMTP id JAA01325; Mon, 7 Jul 1997 09:46:09 +0100 (BST) Message-Id: <199707070846.JAA01325@monoid.cs.tcd.ie> X-Authentication-Warning: monoid.cs.tcd.ie: localhost [127.0.0.1] didn't use HELO protocol To: "Jonathan M. Bresler" , freebsd-security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: (Home)+353-(0)1-6765859 (College)+353-(0)1-7021321 X-PGP: Public Key on Request In-reply-to: Message from "Jonathan M. Bresler" dated Sunday at 14:50. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1320.868265168.1@monoid> Date: Mon, 07 Jul 1997 09:46:09 +0100 From: Colman Reilly Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk JMB says: in a nutshell, the security model is "you must have permission to do something". the superuser (aka root: uid 0) is can do anything. command audit trail (logging) is not provided. the holes have been in the implementation of that model. the source shows the implementation. which has been of greatly varying quality regarding security. ;( Sure, that's the thought underlying the security model, sort of, but it fails to catch the whole intended behaviour, and certainly isn't complete enough to help decide whether a piece of code preservses system security or not, which is probably part of the problem. Implementors can't really be sure whether or not their code is secure because it's not entirely obvious what secure means. Colman From owner-freebsd-security Mon Jul 7 08:06:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA17823 for security-outgoing; Mon, 7 Jul 1997 08:06:05 -0700 (PDT) Received: from androcles.com (androcles.com [204.57.240.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA17813 for ; Mon, 7 Jul 1997 08:06:00 -0700 (PDT) Received: (from dhh@localhost) by androcles.com (8.8.6/8.6.12) id IAA02876; Mon, 7 Jul 1997 08:01:43 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199707061827.OAA23298@chaos.amber.org> Date: Mon, 07 Jul 1997 07:48:48 -0700 (PDT) From: "Duane H. Hesser" To: Christopher Petrilli Subject: Re: Security Model/Target for FreeBSD or 4.4? Cc: freebsd-security@FreeBSD.ORG, Adam Shostack , Colman Reilly , "Jordan K. Hubbard" Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk There is a Version 7 document by Dennis Ritchie, available online, which ought to be a good beginning for a study or discussion of Unix security: http://plan9.bell-labs.com/7thEdMan/vol2/security This is troff source (and the marcros are also available). In fact, most of the Version 7 manual sources for volumes 1 and 2 are at that address (bookmark it NOW, before you forget). Another applicable document you will find there is http://plan9.bell-labs.com/7thEdMan/vol2/password This is a short discussion by Robert Morris and Ken Thompson regarding password security. I seem to recall another document--prbably from around that same time-- which discussed the "friendly enemies" approach to checking security. I'll see if I can find it in my old manuals (does it ring a bell with anyone?). On 06-Jul-97 Christopher Petrilli wrote: >In reply to Jordan K. Hubbard (jkh@time.cdrom.com) on 7/5/97 7:47 PM: > >>> I also spent a couple of hours fighting with Alta Vista looking for relevant >>> documents and didn't find very much. Any other suggestions? >> >>/usr/src? :) >> >>Seriously, I doubt you'll find that anyone has sat down and documented >>this aspect of the system specifically. If you want to study the >>security implementation in detail, the sources remain the first and >>foremost resource. In fact, they probably represent the ONLY resource. >>Good luck! > >I will note that there has been off and on talk of a C2 certified FreeBSD >implementation, which would require documentation. > >I think it's important to understand that few OSes (outside the "big >boys" like VMS, MVS, VM, GUARDIAN, etc.) have documented formal security >polcies. Mostly it's just whatever a programmer feels like. > >Christopher > >-- >| Christopher Petrilli "That's right you're >| petrilli@amber.org not from Texas." > > -------------- Duane H. Hesser dhh@androcles.com From owner-freebsd-security Mon Jul 7 09:57:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA23310 for security-outgoing; Mon, 7 Jul 1997 09:57:35 -0700 (PDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA23305 for ; Mon, 7 Jul 1997 09:57:31 -0700 (PDT) Received: from apriori.cc.cmu.edu (APRIORI.CC.CMU.EDU [128.2.72.117]) by cmu1.acs.cmu.edu (8.8.2/8.8.2) with SMTP id MAA14345; Mon, 7 Jul 1997 12:57:21 -0400 Date: Mon, 7 Jul 1997 12:57:20 -0400 (EDT) From: Robert N Watson X-Sender: rnw@apriori.cc.cmu.edu To: Jim Binkley cc: freebsd-security@FreeBSD.ORG Subject: Re: apology and question re certificate servers In-Reply-To: <199707011702.KAA07768@sirius.cs.pdx.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Jul 1997, Jim Binkley wrote: > > I hate it when I try and send personal mail and send it to > a mailing list... Sigh. Sorry ... shoot too quick and the foot hurts. > > but on the other hand, a question for anyone on the mailing list. > > Has anybody tried to setup any kind of certificate server > on any kind of system? With what results? > I'm not even sure what is available to play with at this point; > e.g., that might cost money or be free. > > 1. netscape server + certificate server I presume to do ssl > 3.0 stuff with netscape clients. > 2. dns sec stuff somewhere? > 3. ssleay? A free reference DNSsec implementation is available from Trusted Information Systems (TIS) at: http://www.tis.com/docs/research/network/dns.html It is based on BIND 4.9.5, although we currently have a BIND8 DNSsec implementation in the workings. Information on getting/configuring/etc DNSsec is all on that page. You'll need to get a copy of RSARef (free but export-restricted.) Instructions are all there. Since DNSsec is still under development (NXT records, dynamic DNS interaction, etc, are still underway, as is a clarify document, I believe.) With regards to other stuff -- haven't tried SSL/TLS in any of its forms, server-side. I noticed the other day that MIT now has their own certificate service (was grabbing some IETF Security Directorate stuff, and had to install a certificate in my browser before I could view the pages.) Seemed a little unusual -- I guess they are not interested in Verisign's offerings? Robert Watson (rwatson@tis.com for Trusted Information Systems related mail) From owner-freebsd-security Mon Jul 7 09:59:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA23390 for security-outgoing; Mon, 7 Jul 1997 09:59:57 -0700 (PDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA23385 for ; Mon, 7 Jul 1997 09:59:55 -0700 (PDT) Received: from apriori.cc.cmu.edu (APRIORI.CC.CMU.EDU [128.2.72.117]) by cmu1.acs.cmu.edu (8.8.2/8.8.2) with SMTP id MAA14419; Mon, 7 Jul 1997 12:59:41 -0400 Date: Mon, 7 Jul 1997 12:59:40 -0400 (EDT) From: Robert N Watson X-Sender: rnw@apriori.cc.cmu.edu To: "Jordan K. Hubbard" cc: freebsd-security@FreeBSD.ORG Subject: Re: apology and question re certificate servers In-Reply-To: <29187.867785429@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Jul 1997, Jordan K. Hubbard wrote: > > Has anybody tried to setup any kind of certificate server > > on any kind of system? With what results? > > www.c2.org offers StrongHold, which I've set up on several FreeBSD > systems for secure ordering. We also use the Netscape commerce > server for BSDI here at Walnut Creek CDROM. Both work well. Is that actually running on BSDI, or running under FreeBSD? :) I was disappointed when development of Fastrack for BSD/OS moved to a BSDI thing, as it means I can no longer grab educational pricing on the server from Netscape (free :). I'm stuck with an old Communications server. Maybe BSDI will decide to continue with the Netscape licensing arrangement? Robert Watson From owner-freebsd-security Mon Jul 7 10:08:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA24208 for security-outgoing; Mon, 7 Jul 1997 10:08:42 -0700 (PDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA24201; Mon, 7 Jul 1997 10:08:36 -0700 (PDT) Received: from apriori.cc.cmu.edu (APRIORI.CC.CMU.EDU [128.2.72.117]) by cmu1.acs.cmu.edu (8.8.2/8.8.2) with SMTP id NAA14803; Mon, 7 Jul 1997 13:08:34 -0400 Date: Mon, 7 Jul 1997 13:08:32 -0400 (EDT) From: Robert N Watson X-Sender: rnw@apriori.cc.cmu.edu To: "Jonathan M. Bresler" cc: freebsd-security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <199707062150.OAA07546@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 6 Jul 1997, Jonathan M. Bresler wrote: > Jordan K. Hubbard wrote: > > > > > I also spent a couple of hours fighting with Alta Vista looking for relevant > > > documents and didn't find very much. Any other suggestions? > > > > /usr/src? :) > > > > Seriously, I doubt you'll find that anyone has sat down and documented > > this aspect of the system specifically. If you want to study the > > security implementation in detail, the sources remain the first and > > foremost resource. In fact, they probably represent the ONLY resource. > > Good luck! > > in a nutshell, the security model is > "you must have permission to do something". > the superuser (aka root: uid 0) is can do anything. > command audit trail (logging) is not provided. > the holes have been in the implementation of that model. > the source shows the implementation. which has been of greatly > varying quality regarding security. ;( I've heard that OpenBSD now has a feature to allow non-root users to bind to <1024 ports. It would be nice to see something similar to that under FreeBSD -- half the daemons (not a verified figure) that run as root probably don't need root access, except to bind to the port (named, sendmail, web servers, etc.) I believe the OpenBSD implementation just gives this access to the daemon user (or something to that extent? Would love details), but perhaps we could go for something a little more sophisticated if it doesn't up the overhead too much on the kernel? A limited list of (port, user) (say a max of 64, except as configured in the kernel), and if the bind() call matches this for TCP, allow the program to bind, for example. An appropriate root-owned file (/etc/rc.conf?) could define those permissions in an ipfirewall-style setup, running early in the rc sequence. This would potentially open up more holes as extra configuration files have to be monitored, and add more overhead on bind() calls, not to mention adding a configuration mechanism, but not suffering from the numerous problems involving daemons running as root (without having to rewrite all the daemons) would be nice. Even the single-user unconfigurable approach (root and daemon can bind) would be better than nothing. Just a thought.. Robert Watson From owner-freebsd-security Mon Jul 7 10:59:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA27449 for security-outgoing; Mon, 7 Jul 1997 10:59:47 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27420; Mon, 7 Jul 1997 10:59:31 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id NAA16320; Mon, 7 Jul 1997 13:59:09 -0400 (EDT) Date: Mon, 7 Jul 1997 13:59:08 -0400 (EDT) From: Brian Mitchell To: Robert N Watson cc: "Jonathan M. Bresler" , freebsd-security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 7 Jul 1997, Robert N Watson wrote: > > I've heard that OpenBSD now has a feature to allow non-root users to bind > to <1024 ports. It would be nice to see something similar to that under > FreeBSD -- half the daemons (not a verified figure) that run as root > probably don't need root access, except to bind to the port (named, > sendmail, web servers, etc.) I believe the OpenBSD implementation just > gives this access to the daemon user (or something to that extent? Would > love details), but perhaps we could go for something a little more > sophisticated if it doesn't up the overhead too much on the kernel? A > limited list of (port, user) (say a max of 64, except as configured in the > kernel), and if the bind() call matches this for TCP, allow the program to > bind, for example. An appropriate root-owned file (/etc/rc.conf?) could > define those permissions in an ipfirewall-style setup, running early in > the rc sequence. > > This would potentially open up more holes as extra configuration files > have to be monitored, and add more overhead on bind() calls, not to > mention adding a configuration mechanism, but not suffering from the > numerous problems involving daemons running as root (without having to > rewrite all the daemons) would be nice. Even the single-user > unconfigurable approach (root and daemon can bind) would be better than > nothing. I kinda doubt openbsd has such a facility, but i dont know. I'll have to look into that when I get home :). I implemented such a feature for port 20 binds via a sysctl net.inet.ip.ftpbinduid: 0 theo thought the idea for it was ... less than good, and said he did not like the whole idea of nonroot users being able to bind privledged ports. Brian Mitchell brian@firehouse.net "BSD code sucks. Of course, everything else sucks far more." - Theo de Raadt From owner-freebsd-security Mon Jul 7 11:06:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA27818 for security-outgoing; Mon, 7 Jul 1997 11:06:47 -0700 (PDT) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA27809; Mon, 7 Jul 1997 11:06:43 -0700 (PDT) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id OAA08144; Mon, 7 Jul 1997 14:03:46 -0400 (EDT) From: Adam Shostack Message-Id: <199707071803.OAA08144@homeport.org> Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: from Robert N Watson at "Jul 7, 97 01:08:32 pm" To: rnw@andrew.cmu.edu (Robert N Watson) Date: Mon, 7 Jul 1997 14:03:46 -0400 (EDT) Cc: jmb@FreeBSD.ORG, freebsd-security@FreeBSD.ORG, tech@openbsd.org (OpenBSD Mailing List) X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I brough up the idea of doing this on the openbsd list. We agreed that there wasn't a clean way to do it. I'm experimenting with ways of doing it, leaning towords a sysctl controlled list of port, gid pairs. I don't know of anyone who has implemented it. The overhead should be pretty minimal. I chose not to depend on files, which is ugly, but not so ugly as having the kernel depend on files during startup. The other thought that has occured to me, but I expect it to be more expensive, is to use a packet filter with NAT capabilities to translate port bindings to high numbers for appropriate daemons. Since this has a per packet hit, I expect it to be very expensive on an ongoing basis. Adam Robert N Watson wrote: | I've heard that OpenBSD now has a feature to allow non-root users to bind | to <1024 ports. It would be nice to see something similar to that under | FreeBSD -- half the daemons (not a verified figure) that run as root | probably don't need root access, except to bind to the port (named, | sendmail, web servers, etc.) I believe the OpenBSD implementation just | gives this access to the daemon user (or something to that extent? Would | love details), but perhaps we could go for something a little more | sophisticated if it doesn't up the overhead too much on the kernel? A | limited list of (port, user) (say a max of 64, except as configured in the | kernel), and if the bind() call matches this for TCP, allow the program to | bind, for example. An appropriate root-owned file (/etc/rc.conf?) could | define those permissions in an ipfirewall-style setup, running early in | the rc sequence. | This would potentially open up more holes as extra configuration files | have to be monitored, and add more overhead on bind() calls, not to | mention adding a configuration mechanism, but not suffering from the | numerous problems involving daemons running as root (without having to | rewrite all the daemons) would be nice. Even the single-user | unconfigurable approach (root and daemon can bind) would be better than | nothing. | | Just a thought.. | | Robert Watson | -- He has erected a multitude of new offices, and sent hither swarms of officers to harrass our people, and eat out their substance. From owner-freebsd-security Mon Jul 7 11:38:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA29849 for security-outgoing; Mon, 7 Jul 1997 11:38:01 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA29844 for ; Mon, 7 Jul 1997 11:37:59 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id LAA23476; Mon, 7 Jul 1997 11:37:57 -0700 Date: Mon, 7 Jul 1997 11:37:57 -0700 From: Sean Eric Fagan Message-Id: <199707071837.LAA23476@kithrup.com> To: security@freebsd.org Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: References: Organization: Kithrup Enterprises, Ltd. Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article you write: >I kinda doubt openbsd has such a facility, but i dont know. I'll have to >look into that when I get home :). I implemented such a feature for port >20 binds via a sysctl > >net.inet.ip.ftpbinduid: 0 > >theo thought the idea for it was ... less than good, and said he did not >like the whole idea of nonroot users being able to bind privledged ports. This was discussed here a few months ago (a year ago?). It would have been something along the lines of: net.inet.ip. and then using it like sysctl -w net.inet.ip.25=`id smtp` or somesuch. From owner-freebsd-security Mon Jul 7 11:48:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA00607 for security-outgoing; Mon, 7 Jul 1997 11:48:16 -0700 (PDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA00595 for ; Mon, 7 Jul 1997 11:48:09 -0700 (PDT) Received: from apriori.cc.cmu.edu (APRIORI.CC.CMU.EDU [128.2.72.117]) by cmu1.acs.cmu.edu (8.8.2/8.8.2) with SMTP id OAA17853; Mon, 7 Jul 1997 14:47:16 -0400 Date: Mon, 7 Jul 1997 14:47:12 -0400 (EDT) From: Robert N Watson X-Sender: rnw@apriori.cc.cmu.edu To: Adam Shostack cc: freebsd-security@FreeBSD.ORG, OpenBSD Mailing List Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <199707071803.OAA08144@homeport.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 7 Jul 1997, Adam Shostack wrote: > I brough up the idea of doing this on the openbsd list. We agreed > that there wasn't a clean way to do it. I'm experimenting with ways > of doing it, leaning towords a sysctl controlled list of port, gid > pairs. I don't know of anyone who has implemented it. > > The overhead should be pretty minimal. > > I chose not to depend on files, which is ugly, but not so ugly as > having the kernel depend on files during startup. My assumption was a default boot config of only root being able to bind <1024, but then using syscall adding port,uid pairs. I'm not sure what all the connotations of using port,gid vs port,uid are -- gid does seem to be a better idea, as it seem to fit the existing daemon, mail, bin, www, groupings, and in the context of FreeBSD's default matching of one group per uid, it is just as flexible. Are there any other issues involved here? What daemons would end up running as the same user? fingerd could run as nobody (or a finger user) as it needs minimal access. bind, for example, would benefit more from a seperate dns user (which would be nice also when it comes to implementing a secure resolver and key management system), and sendmail could finally run as group mail, user mail (?) and just have the local delivery agents run as suid root? Not sure what all the implications are there, either. Some rewriting of code would have to take place, and that might not work as well. > The other thought that has occured to me, but I expect it to be more > expensive, is to use a packet filter with NAT capabilities to > translate port bindings to high numbers for appropriate daemons. > Since this has a per packet hit, I expect it to be very expensive on > an ongoing basis. I had also hoped for something a little more flexible/portable, or something based a little more on a traditional interface to the system. I also considered a less open approach to port permissions -- requiring that all port binding in any range be permitted by a system-wide policy. Under such a system, rc.ports would be called by the rc boot sequence (prior to going multi-user) to enable binding access for various gids or uids using sysctl. When the securelevel increased, the default permissions for binding a port would change from default-permit (except <1024) to default-deny, meaning that only explicitely permitted services would be disabled. One can argue that this might cause more prolems than it solved, as it would effectively cripple many of the more useful UNIX daemons, not to mention normal user applications :). In particular, you would lose portmapper-related utilities, not to mention UDP-based query services (like DNS.) Obviously, such an implementation would require a much more significant rewrite of user-side code, and is not feasible for general-release systems in the short term. A few more comments on implementing port-binding permissions: Verifying permission on a port would require high-order operations, even allowing for hashing: any attempted bind to a <1024 port would require many comparisons against gid, etc. Would we require the only gid be compared be the first in the gid list? Just to throw out another idea I had floating around, which may not be a useful one: would a /ports filesystem mapping be useful for permissions? All ports < 1024 would have a filesystem entry, and permissions on the port file would determine whether they could be bound or not (possibly overkill on the whole concept, but if we're trhowing around extending the socket facilities..) Additionally, maybe permissions on port access could be applied to other port ranges than <1024. For example, we could prevent non-root users from binding port 6000-6010, preventing a local denail of service attack. (not very useful, but..) A stricter security policy could then optionally be implemented. I'd rather not have users clog up ports 6000-6010, as they could prevent an X server for running, or break X forwarding in ssh, so could add a requirement that root access be used to bind that port. Again, the securelevel + sysctl could be used to determine the default action. Well, just some speculation. Finding an elegant way to implement permissions on ports would be nice. Since the filesystem is the traditional approach to permissions, maybe we should be looking at that as a mechanism, similar perhaps to /proc. This seems a bit redundant given that sockets already have a filesystem representation.. Robert Watson From owner-freebsd-security Mon Jul 7 11:53:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA01077 for security-outgoing; Mon, 7 Jul 1997 11:53:43 -0700 (PDT) Received: (from jmb@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA01057; Mon, 7 Jul 1997 11:53:34 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199707071853.LAA01057@hub.freebsd.org> Subject: Re: Security Model/Target for FreeBSD or 4.4? To: adam@homeport.org (Adam Shostack) Date: Mon, 7 Jul 1997 11:53:33 -0700 (PDT) Cc: rnw@andrew.cmu.edu, jmb@FreeBSD.ORG, freebsd-security@FreeBSD.ORG, tech@openbsd.org In-Reply-To: <199707071803.OAA08144@homeport.org> from "Adam Shostack" at Jul 7, 97 02:03:46 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk hmm....from memory: jan simon-pendry created a filesystem called portals for just this purpose or allowing non-root processes access to low numbered ports using filesystem permissions. put sendmail as user sendmail and only let user sendmail read/write to port 25. teh 4.4BSD ssm (system ... manual) has a usenix paper on portals jmb Adam Shostack wrote: > > I brough up the idea of doing this on the openbsd list. We agreed > that there wasn't a clean way to do it. I'm experimenting with ways > of doing it, leaning towords a sysctl controlled list of port, gid > pairs. I don't know of anyone who has implemented it. > > The overhead should be pretty minimal. > > I chose not to depend on files, which is ugly, but not so ugly as > having the kernel depend on files during startup. > > The other thought that has occured to me, but I expect it to be more > expensive, is to use a packet filter with NAT capabilities to > translate port bindings to high numbers for appropriate daemons. > Since this has a per packet hit, I expect it to be very expensive on > an ongoing basis. > > Adam > > > > Robert N Watson wrote: > > | I've heard that OpenBSD now has a feature to allow non-root users to bind > | to <1024 ports. It would be nice to see something similar to that under > | FreeBSD -- half the daemons (not a verified figure) that run as root > | probably don't need root access, except to bind to the port (named, > | sendmail, web servers, etc.) I believe the OpenBSD implementation just > | gives this access to the daemon user (or something to that extent? Would > | love details), but perhaps we could go for something a little more > | sophisticated if it doesn't up the overhead too much on the kernel? A > | limited list of (port, user) (say a max of 64, except as configured in the > | kernel), and if the bind() call matches this for TCP, allow the program to > | bind, for example. An appropriate root-owned file (/etc/rc.conf?) could > | define those permissions in an ipfirewall-style setup, running early in > | the rc sequence. From owner-freebsd-security Mon Jul 7 13:05:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA04918 for security-outgoing; Mon, 7 Jul 1997 13:05:46 -0700 (PDT) Received: from cyrus.watson.org (robert@cyrus.watson.org [207.86.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA04913 for ; Mon, 7 Jul 1997 13:05:42 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id QAA03342; Mon, 7 Jul 1997 16:05:07 -0400 (EDT) Date: Mon, 7 Jul 1997 16:05:07 -0400 (EDT) From: Robert Watson To: Sean Eric Fagan cc: security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <199707071837.LAA23476@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 7 Jul 1997, Sean Eric Fagan wrote: > [...] > > This was discussed here a few months ago (a year ago?). It would have been > something along the lines of: > > net.inet.ip. > > and then using it like > > sysctl -w net.inet.ip.25=`id smtp` > > or somesuch. Unfortunately, that doesn't address the distinction between TCP and UDP services.. I'm not sure that is a huge issue, but it seems relevant. The formatting for this is looking more an more like an ipfirewall config file. I wonder if the similarities between the interfaces could be merged in some way? Also, since we're looking at putting permissions on port-binding, are there any other related resources or capabilities under BSD that are not limited by the current restrictions? Various types of socket communication don't appear to be. On a related note, has anyone given any thought to making chroot() a user-accessible call? I haven't really looked at it, so am not sure why it can only be called by uid root programs. In terms of sandboxing (which seems to be popular these days for various applications), it would be nice to restrict programs to specific regions of the disk, etc. Especially if you are a non-root user developing programs that require special libraries, etc. Or if you want to run a restricted web or ftp server, but don't have root access (as hopefully would be the case with the lighter restrictions on binding ports <1024.) Robert From owner-freebsd-security Mon Jul 7 13:07:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA04965 for security-outgoing; Mon, 7 Jul 1997 13:07:25 -0700 (PDT) Received: from diswww.disclosure.com (diswww.disclosure.com [206.181.208.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA04959; Mon, 7 Jul 1997 13:07:14 -0700 (PDT) Received: from elbereth.disclosure.com (elbereth [192.168.57.210]) by diswww.disclosure.com (8.7.3/8.7.3) with ESMTP id QAA08517; Mon, 7 Jul 1997 16:05:36 -0400 (EDT) Received: (from kstailey@localhost) by elbereth.disclosure.com (8.8.5/8.8.5) id QAA15506; Mon, 7 Jul 1997 16:05:35 -0400 (EDT) Date: Mon, 7 Jul 1997 16:05:35 -0400 (EDT) Message-Id: <199707072005.QAA15506@elbereth.disclosure.com> From: Kenneth Stailey To: jmb@freebsd.org CC: adam@homeport.org, rnw@andrew.cmu.edu, jmb@freebsd.org, freebsd-security@freebsd.org, tech@openbsd.org In-reply-to: <199707071853.LAA01057@hub.freebsd.org> (jmb@freebsd.org) Subject: Re: Security Model/Target for FreeBSD or 4.4? Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > teh 4.4BSD ssm (system ... manual) has a usenix paper on portals This is not in the OpenBSD tree (it is probably not in the other trees either.) See http://www.kohala.com/~rstevens/portals.ps for a PostScript version of Stevens, W. R., and Pendry, J.-S. 1995. "Portals in 4.4BSD," Proceedings of the 1995 Winter USENIX Technical Conference, pp. 1-10, New Orleans, La. From owner-freebsd-security Mon Jul 7 13:39:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA06866 for security-outgoing; Mon, 7 Jul 1997 13:39:54 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA06849 for ; Mon, 7 Jul 1997 13:39:49 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id QAA16773; Mon, 7 Jul 1997 16:39:03 -0400 (EDT) Date: Mon, 7 Jul 1997 16:39:01 -0400 (EDT) From: Brian Mitchell To: Robert Watson cc: Sean Eric Fagan , security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 7 Jul 1997, Robert Watson wrote: > On a related note, has anyone given any thought to making chroot() a > user-accessible call? I haven't really looked at it, so am not sure why > it can only be called by uid root programs. In terms of sandboxing (which > seems to be popular these days for various applications), it would be nice > to restrict programs to specific regions of the disk, etc. Especially if > you are a non-root user developing programs that require special > libraries, etc. Or if you want to run a restricted web or ftp server, but > don't have root access (as hopefully would be the case with the lighter > restrictions on binding ports <1024.) picture this, /usr/home is the same fs as /usr/bin - you create a reasonable tree with its own passwd file, you populate your usr/bin with hardlinks, you chroot and run su su will read your passwd file, giving you root. you create a setuid shell or something similar and then log out of the shell and go back to the nonchrooted environment and run the suid root shell. Brian Mitchell brian@firehouse.net "BSD code sucks. Of course, everything else sucks far more." - Theo de Raadt From owner-freebsd-security Mon Jul 7 14:20:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA09173 for security-outgoing; Mon, 7 Jul 1997 14:20:58 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA09166 for ; Mon, 7 Jul 1997 14:20:55 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id OAA21902; Mon, 7 Jul 1997 14:20:31 -0700 (PDT) To: Robert N Watson cc: freebsd-security@FreeBSD.ORG Subject: Re: apology and question re certificate servers In-reply-to: Your message of "Mon, 07 Jul 1997 12:59:40 EDT." Date: Mon, 07 Jul 1997 14:20:31 -0700 Message-ID: <21897.868310431@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is that actually running on BSDI, or running under FreeBSD? :) I was Go look? Again, the IRL is www.c2.org. :-) Jordan From owner-freebsd-security Mon Jul 7 14:29:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA09713 for security-outgoing; Mon, 7 Jul 1997 14:29:46 -0700 (PDT) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA09697 for ; Mon, 7 Jul 1997 14:29:41 -0700 (PDT) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [198.142.2.24]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id OAA29517 for ; Mon, 7 Jul 1997 14:33:25 -0700 (PDT) Received: (qmail 12942 invoked by uid 110); 7 Jul 1997 21:29:23 -0000 Message-ID: <19970707212923.12941.qmail@suburbia.net> Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: from Robert Watson at "Jul 7, 97 04:05:07 pm" To: robert@cyrus.watson.org (Robert Watson) Date: Tue, 8 Jul 1997 07:29:23 +1000 (EST) Cc: sef@kithrup.com, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Unfortunately, that doesn't address the distinction between TCP and UDP > services.. I'm not sure that is a huge issue, but it seems relevant. The > formatting for this is looking more an more like an ipfirewall config > file. I wonder if the similarities between the interfaces could be > merged in some way? > > Also, since we're looking at putting permissions on port-binding, are > there any other related resources or capabilities under BSD that are not > limited by the current restrictions? Various types of socket > communication don't appear to be. > > Robert I wrote code to do just this (and more) over six months ago. It's still in the GNATS database rotting as far as I know. Except from my ipfw man page below: [...] uid user Matches if the packet is associated with a socket created by user. The username any matches any user. gid group Matches if the packet is associated with a socket created by a user who at the time held the primary or secondary group group. The group any matches any group. Socket credential rule-matching on packets varies slightly according to the direction of the packet being examined. This is necessitated, as to start with we do not know if an incoming packet is asso- ciated with a local client, is being forwarded, or is to be handled by the kernel directly. First the incoming packet is matched against all non-creden- tial rules. If the packet is accepted, it then passes to the protocol layer. If the protocol layer is sucessful in locating a socket on which to de- liver the packet, then the packet is re-examined, passing through the firewall ruleset for the second time. On the second occasion only socket credential rules are matched against. If packet is accepted, it is delivered to the socket, otherwise it is dropped or rejected. Output is somewhat simpler, as we immediately know the socket credentials of the socket sending the packet. This means we can match against the ruleset in one pass. Socket credential matches are not enabled unless the kernel was compiled with IPFIREWALL_CREDEN- TIALS. bind Don't match this rule against packets, but against the system call bind(). Only a specific set of in- formation can be used for matches when this keyword is specified: protocol, src, sport, interface, uid and gid. src is the interface address requested or 0.0.0.0 if no specific interface address was requested. interface is the interface address, if requested, unless the address belongs to a multi-cast group. sport is the port requested, unless no specific port was requested. In this latter case the source port will be the port is the port allocated by the system. uid and gid are those credentials held at the time of socket() creation, not those held at the instant bind() was called. The bind flag is not enabled unless the kernel was compiled with IPFIREWALL_CREDENTIALS. > On a related note, has anyone given any thought to making chroot() a > user-accessible call? I haven't really looked at it, so am not sure why > it can only be called by uid root programs. In terms of sandboxing (which > seems to be popular these days for various applications), it would be nice > to restrict programs to specific regions of the disk, etc. Especially if > you are a non-root user developing programs that require special > libraries, etc. Or if you want to run a restricted web or ftp server, but > don't have root access (as hopefully would be the case with the lighter > restrictions on binding ports <1024.) this is why: $ cd /tmp $ ln /bin/sh sh $ ln /bin/su su $ mkdir etc $ echo root::0:0::/:/sh >etc/passwd $ chroot . /su root # whoami root # I submitted a (tiny) patch to ld.so that provides for a LD_CHROOT environmental variable, which allows for automatic chrooting() after dynamic symbol resolution. Any other way of doing this, apart from source-level modification of the program to be chrooted is incredibly painful and inherently insecure (not to mention grossly inefficient), because your binary or your libraries have to be within the chroot()ed zone. PHK (FreeBSD core) decided to zorch the LD_CHROOT patch under the basis that the efficiency gains could be realised by hardlinking all your system libraries into the chroot()ed area. The mind boggles. -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-security Mon Jul 7 15:48:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA13897 for security-outgoing; Mon, 7 Jul 1997 15:48:04 -0700 (PDT) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA13879 for ; Mon, 7 Jul 1997 15:47:58 -0700 (PDT) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id PAA25097; Mon, 7 Jul 1997 15:46:57 -0700 (PDT) Date: Mon, 7 Jul 1997 15:46:57 -0700 (PDT) From: Jim Shankland Message-Id: <199707072246.PAA25097@biggusdiskus.flyingfox.com> To: robert@cyrus.watson.org Subject: Re: Security Model/Target for FreeBSD or 4.4? Cc: security@freebsd.ORG Sender: owner-security@freebsd.ORG X-Loop: FreeBSD.org Precedence: bulk > > something along the lines of: > > > > net.inet.ip. > > > > and then using it like > > > > sysctl -w net.inet.ip.25=`id smtp` > > Unfortunately, that doesn't address the distinction between TCP and UDP > services.. I'm not sure that is a huge issue, but it seems relevant. Sure, that should be: sysctl -w net.inet.tcp.25=`id smtp` sysctl -w net.inet.udp.53=`id named` or whatever. No biggie. Of course, we already have a permissions system. Why not: -rw-rw---- 1 root smtp Feb 18 09:33 /protocols/inet/tcp/25 Or is that just too weird? Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Mon Jul 7 16:21:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA15152 for security-outgoing; Mon, 7 Jul 1997 16:21:09 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA15145 for ; Mon, 7 Jul 1997 16:21:04 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id JAA25320; Tue, 8 Jul 1997 09:20:54 +1000 (EST) Date: Tue, 8 Jul 1997 09:20:53 +1000 (EST) From: "Daniel O'Callaghan" To: Jim Shankland cc: robert@cyrus.watson.org, security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <199707072246.PAA25097@biggusdiskus.flyingfox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 7 Jul 1997, Jim Shankland wrote: > > > something along the lines of: > > > > > > net.inet.ip. > > > > > > and then using it like > > > > > > sysctl -w net.inet.ip.25=`id smtp` > > > > Unfortunately, that doesn't address the distinction between TCP and UDP > > services.. I'm not sure that is a huge issue, but it seems relevant. Julian Assange wrote patches for IPFW which did this sort of thing in December, 1996, posted to -hackers. Danny From owner-freebsd-security Mon Jul 7 18:02:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA19301 for security-outgoing; Mon, 7 Jul 1997 18:02:44 -0700 (PDT) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA19293 for ; Mon, 7 Jul 1997 18:02:39 -0700 (PDT) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id UAA20028; Mon, 7 Jul 1997 20:58:56 -0400 (EDT) From: Adam Shostack Message-Id: <199707080058.UAA20028@homeport.org> Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <199707072246.PAA25097@biggusdiskus.flyingfox.com> from Jim Shankland at "Jul 7, 97 03:46:57 pm" To: jas@flyingfox.com (Jim Shankland) Date: Mon, 7 Jul 1997 20:58:56 -0400 (EDT) Cc: robert@cyrus.watson.org, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jim Shankland wrote: | Of course, we already have a permissions system. Why not: | | -rw-rw---- 1 root smtp Feb 18 09:33 /protocols/inet/tcp/25 | | Or is that just too weird? That seems like a great idea, modulo the amount of work needed to implement it. (do you want to extend that so that /protocols/inet/tcp/10.2.23.45:25 allows you to control permissions on a per IP address basis? That might be too baroque for not enough gain..) -- He has erected a multitude of new offices, and sent hither swarms of officers to harrass our people, and eat out their substance. From owner-freebsd-security Mon Jul 7 18:12:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA19637 for security-outgoing; Mon, 7 Jul 1997 18:12:42 -0700 (PDT) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA19631 for ; Mon, 7 Jul 1997 18:12:38 -0700 (PDT) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id VAA21941; Mon, 7 Jul 1997 21:10:01 -0400 (EDT) From: Adam Shostack Message-Id: <199707080110.VAA21941@homeport.org> Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: from Robert N Watson at "Jul 7, 97 02:47:12 pm" To: rnw@andrew.cmu.edu (Robert N Watson) Date: Mon, 7 Jul 1997 21:10:00 -0400 (EDT) Cc: freebsd-security@FreeBSD.ORG, tech@openbsd.org X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Robert N Watson wrote: | | On Mon, 7 Jul 1997, Adam Shostack wrote: | | > I brough up the idea of doing this on the openbsd list. We agreed | > that there wasn't a clean way to do it. I'm experimenting with ways | > of doing it, leaning towords a sysctl controlled list of port, gid | > pairs. I don't know of anyone who has implemented it. | > | > The overhead should be pretty minimal. | > | > I chose not to depend on files, which is ugly, but not so ugly as | > having the kernel depend on files during startup. | | My assumption was a default boot config of only root being able to bind | <1024, but then using syscall adding port,uid pairs. I'm not sure what | all the connotations of using port,gid vs port,uid are -- gid does seem to | be a better idea, as it seem to fit the existing daemon, mail, bin, www, | groupings, and in the context of FreeBSD's default matching of one group | per uid, it is just as flexible. Are there any other issues involved | here? What daemons would end up running as the same user? fingerd could | run as nobody (or a finger user) as it needs minimal access. bind, for | example, would benefit more from a seperate dns user (which would be nice | also when it comes to implementing a secure resolver and key management | system), and sendmail could finally run as group mail, user mail (?) and | just have the local delivery agents run as suid root? Not sure what all | the implications are there, either. Some rewriting of code would have to | take place, and that might not work as well. My thought was that you could make programs setgid portbind. Seems intuitively cleaner than making them setuid something. Also, allows you to have a simple implementation with just a list of ports that portbind can bind to (dns, http). I'd leave everyone under a different user who can't do anything, to avoid having daemons running kill each other. As far as sendmail goes, I think that if you use setuid procmail as your delivery agent, sendmail doesn't need to be root. (Use qmail!) | > The other thought that has occured to me, but I expect it to be more | > expensive, is to use a packet filter with NAT capabilities to | > translate port bindings to high numbers for appropriate daemons. | > Since this has a per packet hit, I expect it to be very expensive on | > an ongoing basis. | | I had also hoped for something a little more flexible/portable, or | something based a little more on a traditional interface to the system. I | also considered a less open approach to port permissions -- requiring that | all port binding in any range be permitted by a system-wide policy. Under | such a system, rc.ports would be called by the rc boot sequence (prior to | going multi-user) to enable binding access for various gids or uids using | sysctl. When the securelevel increased, the default permissions for | binding a port would change from default-permit (except <1024) to | default-deny, meaning that only explicitely permitted services would be | disabled. One can argue that this might cause more prolems than it | solved, as it would effectively cripple many of the more useful UNIX | daemons, not to mention normal user applications :). In particular, you | would lose portmapper-related utilities, not to mention UDP-based query | services (like DNS.) Obviously, such an implementation would require a | much more significant rewrite of user-side code, and is not feasible for | general-release systems in the short term. Well, the question also to ask is the value of all this work? I think you get a fair bit of benefit from creating a portbind group, and then the additional benefits give you progressively less value for your time. I don't think that a general port control facility is as worthwhile; the system is the way it is because the implementors decided not to bother pushing it through the filesystem, and fixing it properly will take a fair bit of work. | Well, just some speculation. Finding an elegant way to implement | permissions on ports would be nice. Since the filesystem is the | traditional approach to permissions, maybe we should be looking at that as | a mechanism, similar perhaps to /proc. This seems a bit redundant given | that sockets already have a filesystem representation.. Really? I must have missed it.. Adam -- He has erected a multitude of new offices, and sent hither swarms of officers to harrass our people, and eat out their substance. From owner-freebsd-security Mon Jul 7 20:14:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA24052 for security-outgoing; Mon, 7 Jul 1997 20:14:07 -0700 (PDT) Received: from goliath.camtech.com.au (goliath.camtech.net.au [203.5.73.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA24047 for ; Mon, 7 Jul 1997 20:14:04 -0700 (PDT) Received: from sebastion.sa.camtech.com.au (sebastion.sa.camtech.com.au [203.28.3.2]) by goliath.camtech.com.au (8.8.5/8.8.2) with ESMTP id MAA09527; Tue, 8 Jul 1997 12:41:37 +0930 (CST) Received: (from uucp@localhost) by sebastion.sa.camtech.com.au (8.6.10/8.6.10) id MAA05319; Tue, 8 Jul 1997 12:43:59 +0930 Received: from frenzy(192.168.4.65) by sebastion via smap (V1.3) id sma005280; Tue Jul 8 12:43:37 1997 Received: by communica.com.au (4.1/SMI-4.1) id AA21807; Tue, 8 Jul 97 09:18:17 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9707072348.AA21807@communica.com.au> Subject: Re: Security Model/Target for FreeBSD or 4.4? To: robert@cyrus.watson.org (Robert Watson) Date: Tue, 8 Jul 1997 09:18:17 +0930 (CST) Cc: sef@kithrup.com, security@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Jul 7, 97 04:05:07 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Robert Watson wrote: > On a related note, has anyone given any thought to making chroot() a > user-accessible call? Yow. Extremely bad idea. However, taking it to the opposite extreme is a good idea. chroot() loses its usefulness if a process in a "secured" sandbox can conceivably get root privileges -- Solution: Restrict the chroot() call for *all* processes that are already chroot()ed. This is a patch against a version of FreeBSD that's about six months old, but I can't imagine much would have changed to affect it. The effect of the patch is to cause chroot() to fail with EPERM if it is called by a process that is already chroot()ed. [ patch attached at end of this message ] > a vulnerability > I haven't really looked at it, so am not sure why > it can only be called by uid root programs. In terms of sandboxing (which > seems to be popular these days for various applications), it would be nice > to restrict programs to specific regions of the disk, etc. Especially if > you are a non-root user developing programs that require special > libraries, etc. Or if you want to run a restricted web or ftp server, but > don't have root access (as hopefully would be the case with the lighter > restrictions on binding ports <1024.) The problem is that then any of those, uh, "restricted" processes wouldn't be restricted. chroot()'s semantics are such that any user which is capable of calling it is inherently capable of breaking out of a sandbox. The chroot() system call doesn't change a process' *current* directory - It changes a process' *root* directory. If my current directory is /foo and I say, "chroot("/bar")" the effect of that is to shift my root directory to /bar *but I'm still in /foo until I chdir() into /bar!* [ the chroot(1) command gets around this by doing a chdir() into the directory you want to use as a root then saying `chroot(".")' ] As a result of those semantics, a process that can call chroot() can break out of a sandbox quite easily. To illustrate this, consider the code fragment below which does exactly that (and try it out in your own chroot()ed environment if you don't believe me): void make_sysadmin_grumpy(void) { int i; chdir("/"); /* change to root directory in sandbox */ if (chroot("/some/directory/in/sandbox") == -1) { perror("chroot() won't work - exploit failed"); exit(1); } /* Great - we're now *OUTSIDE* our root directory... but we still * have a ".." directory that takes us back to the parent of our * current directory. That means we can get back to the *real* * root directory by repeatedly changing back to "..", remembering * that the parent of / is itself */ for (i = 0; i < 100; i++) chdir(".."); /* We're now at the *real* root directory, even though this process' * root is in the sandbox */ chroot("."); /* Oops - This process' root directory ain't the sandbox anymore! * start a root shell and start having some fun */ execl("/bin/csh", "-csh", (char *)0L); } Of course, if you allow chroot() for non-root processes, then those non- root processes can break out of ANY chroot()'ed environment. Which kinda misses the point of chroot(), really. Anyway, here's the patch which makes chroot() fail if a process is already chroot()ed -- which has the main benefit of preventing attacks like the one annotated above. Method: The chroot() VFS syscall will compare the root directory in the caller's proc structure against the root directory in init's proc structure; If they aren't the same it'll fail with EPERM even if the caller is a root-owned process. If they are the same chroot() continues as one would normally expect. The effect is to cause chroot() to fail if the caller or any of its ancestors have already called it. This behaviour can be enabled by building a kernel with `options "FUNKY_CHROOT"' in the config file. The patch also contains diffs against the chroot(2) manpage for completeness' sake. - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer and Senior Trainer Phone: +61-8-8303-3300 Communica Systems, a member of the Fax: +61-8-8303-4403 CAMTECH group of companies WWW: http://www.communica.com.au *** /usr/src/lib/libc/sys/chroot.2.orig Tue Nov 5 20:55:43 1996 --- /usr/src/lib/libc/sys/chroot.2 Tue Nov 5 22:27:49 1996 *************** *** 60,65 **** --- 60,71 ---- has no effect on the process's current directory. .Pp This call is restricted to the super-user. + .Pp + If the kernel has been built with the FUNKY_CHROOT compile-time option, + then calling chroot(2) will cause all future invocations for the calling + process and all of its future children to fail. In certain circumstances + this behaviour can enhance security; In other circumstances it can + reduce security and cause existing software to break horribly. .Sh RETURN VALUES Upon successful completion, a value of 0 is returned. Otherwise, a value of -1 is returned and *************** *** 72,78 **** .It Bq Er ENOTDIR A component of the path name is not a directory. .It Bq Er EPERM ! The effective user ID is not the super-user. .It Bq Er EINVAL The pathname contains a character with the high-order bit set. .It Bq Er ENAMETOOLONG --- 78,87 ---- .It Bq Er ENOTDIR A component of the path name is not a directory. .It Bq Er EPERM ! The effective user ID is not the super-user, or this kernel has been ! built with FUNKY_CHROOT and a previous call to ! .Xr chroot 2 ! has been made by the caller or one of its ancestors. .It Bq Er EINVAL The pathname contains a character with the high-order bit set. .It Bq Er ENAMETOOLONG *************** *** 90,95 **** --- 99,106 ---- .It Bq Er EIO An I/O error occurred while reading from or writing to the file system. .El + .Sh BUGS + FUNKY_CHROOT is a stupid name. .Sh SEE ALSO .Xr chdir 2 .Sh HISTORY *** /sys/kern/vfs_syscalls.c.orig Tue Nov 5 18:20:22 1996 --- /sys/kern/vfs_syscalls.c Tue Nov 5 20:42:21 1996 *************** *** 607,612 **** --- 607,619 ---- register struct filedesc *fdp = p->p_fd; int error; struct nameidata nd; + #if defined(FUNKY_CHROOT) + register struct proc *init; + + init = pfind((pid_t)1); /* locate init's proc structure */ + if (fdp->fd_rdir != init->p_fd->fd_rdir) + return(EPERM); /* if p's root != init's root return EPERM */ + #endif /* FUNKY_CHROOT */ error = suser(p->p_ucred, &p->p_acflag); if (error) From owner-freebsd-security Tue Jul 8 00:08:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA02100 for security-outgoing; Tue, 8 Jul 1997 00:08:28 -0700 (PDT) Received: from critter.dk.tfs.com ([140.145.230.252]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA02095 for ; Tue, 8 Jul 1997 00:08:23 -0700 (PDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.6/8.8.5) with ESMTP id IAA01257; Tue, 8 Jul 1997 08:11:20 +0200 (CEST) To: proff@suburbia.net cc: robert@cyrus.watson.org (Robert Watson), sef@kithrup.com, security@FreeBSD.ORG From: Poul-Henning Kamp Subject: Re: Security Model/Target for FreeBSD or 4.4? In-reply-to: Your message of "Tue, 08 Jul 1997 07:29:23 +1000." <19970707212923.12941.qmail@suburbia.net> Date: Tue, 08 Jul 1997 08:11:20 +0200 Message-ID: <1255.868342280@critter.dk.tfs.com> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <19970707212923.12941.qmail@suburbia.net>, proff@suburbia.net writes : >PHK (FreeBSD core) decided to zorch the LD_CHROOT patch under the >basis that the efficiency gains could be realised by hardlinking >all your system libraries into the chroot()ed area. The mind boggles. Hmm, let me try to say it my way: PHK (FreeBSD core) decided that considering the rather marginal gain, there is no point in deliberately creating holes in the chroot armour. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-security Tue Jul 8 08:46:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA23389 for security-outgoing; Tue, 8 Jul 1997 08:46:30 -0700 (PDT) Received: from cyrus.watson.org (robert@cyrus.watson.org [207.86.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA23383 for ; Tue, 8 Jul 1997 08:46:23 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id LAA04747; Tue, 8 Jul 1997 11:45:57 -0400 (EDT) Date: Tue, 8 Jul 1997 11:45:57 -0400 (EDT) From: Robert Watson To: Adam Shostack cc: freebsd-security@FreeBSD.ORG, tech@openbsd.org Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <199707080110.VAA21941@homeport.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 7 Jul 1997, Adam Shostack wrote: > > My thought was that you could make programs setgid portbind. > Seems intuitively cleaner than making them setuid something. Also, > allows you to have a simple implementation with just a list of ports > that portbind can bind to (dns, http). > > I'd leave everyone under a different user who can't do > anything, to avoid having daemons running kill each other. > > As far as sendmail goes, I think that if you use setuid > procmail as your delivery agent, sendmail doesn't need to be root. > (Use qmail!) Running the daemons as different users would be a must, but using a common portbind group could allow a web server to prevent proper mail service by binding the port at an appropriate time (e.g., the mail server reloads, but the penetrated web server binds the port, as it has rights to do, which allows it to intercept all mail, and deny service, etc.) Similarly, if the web server runs as www.portbind, all cgi programs inherit binding rights to any of the reserved ports, and that is a bad thing. While portbind sounds like a good simple setup, I'd like to see the facility that allows us to link (port,protocol) to a specific gid. Possibly a specific interface, if there is a clean way to do that (so that different web servers running virtual domains could run as different users, and not be allowed to interfere with one-another, etc.) E.g., this web server is only allowed to bind to 127.0.0.1:80, not 127.0.0.2:80. With regards to sendmail -- the only program with a lack of suid on sendmail is local mail delivery: pine (and others) rely on calling /usr/sbin/sendmail -etc if not using smtp (and not all clients support smtp). That sendmail attempts to deliver, but if it fails, puts it in /var/mqueue (possibly more complicated behavior here), and cannot do that if it is not suid-something (could be made sgid mail?) For actual delivery, mail.local is already suid-root, I believe. This continues to be fine behavior as far as I'm concerned. > Well, the question also to ask is the value of all this work? > I think you get a fair bit of benefit from creating a portbind group, > and then the additional benefits give you progressively less value for > your time. > > I don't think that a general port control facility is as > worthwhile; the system is the way it is because the implementors > decided not to bother pushing it through the filesystem, and fixing it > properly will take a fair bit of work. I don't debate the diminishing returns theory, but I think diminishing returns may be more of an issue if we push socket permissions onto the file system in /.../inet/tcp/port, etc, than a gid/port pair list. With regards to gid vs. uid -- is either one of this preferable for any particular reason? gid may be more flexible, I guess, as it would allow multiple users to bind the same ports, but without having rights to each others processes, and as such allow a simpler minimum configuration. Robert From owner-freebsd-security Tue Jul 8 08:59:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA23848 for security-outgoing; Tue, 8 Jul 1997 08:59:28 -0700 (PDT) Received: from cyrus.watson.org (robert@cyrus.watson.org [207.86.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA23836 for ; Tue, 8 Jul 1997 08:59:18 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id LAA04771; Tue, 8 Jul 1997 11:58:44 -0400 (EDT) Date: Tue, 8 Jul 1997 11:58:43 -0400 (EDT) From: Robert Watson To: Mark Newton cc: sef@kithrup.com, security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <9707072348.AA21807@communica.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 8 Jul 1997, Mark Newton wrote: > Robert Watson wrote: > > > On a related note, has anyone given any thought to making chroot() a > > user-accessible call? > > Yow. Extremely bad idea. > > However, taking it to the opposite extreme is a good idea. chroot() loses > its usefulness if a process in a "secured" sandbox can conceivably get > root privileges -- Solution: Restrict the chroot() call for *all* processes > that are already chroot()ed. I was familiar with the actual behavior and implementation of chroot with the processes root, but had never really used it for anything, as it tends to be a more-restricted facility. Can the problems with chroot() safely be sumarized in the following categories? 1. Existing libraries and utilities assume that if they attempt to access /etc/spwd.db (or such), they will get these files off of the absolute root. This may not be changeable, as there are a number of environments where this might be appropriate (boot from floppy, but chroot to mfs/mfs, for example -- the mfs/nfs version of the user database should be used, not the floppy version (same with libraries, etc.)) 2. Creation of hard links retains the setuid behavior of the program, as the permissions and ownership of a file are stored in the inode, and a hardlink merely duplicates the reference to the inode (so I can create /tmp/su as a hard link to /usr/sbin/su, assuming they are both on /usr, and retain the suid and ownership.) This has upsides and downsides -- one downside is if I chroot() myself to /tmp, the existing su will suffer from problem 1. The problem here is that I, as a normal user, can create arbitrary references to suid programs (effectively, instances of them) anywhere I can write to on the same file system. /usr/tmp and /tmp are the most common problem in this area. There are other side effects of this behavior -- as a normal user, I can fill up /tmp with files I can't remove (as sticky bit prevents me from removing references to files I don't own.) Additionally, I can hard link /usr/sbin/su (old buggy version) to /usr/tmp/su before an upgrade to fix the bug, and then the upgrade will leave the old version in /usr/tmp/su (I assume it unlinks the /usr/sbin/su version during upgrade?) Programs may assume that by overwriting (unlinking first) the old version of a setuid program, they are disposing of it, but this may not be true since hard links have the same permissions and content (being the same file :). Symlinks don't have the same problem in that they aren't suid (or such), but still cannot be deleted by a regular user if created in a sticky-bit environment. Daily security mails will pick this up, but you probably cannot assume safely that the user couldn't do the link in the morning before the upgrade, and then take advantage of it in the evening? 3. Current chroot() allows you to undo an old chroot(). If chroot were to become a generally useable call (or even if not), chroot() should only be able to move down the hierarchy, not up. This would make it more transparent as far as the caller was concerned -- they would not have ot know if they were already chroot'd. If the entire filesystem is already chroot("/mfsroot"), then an ftpd chroot("/usr/ftp") would chroot effectively to "/mfsroot/usr/ftp", and be allowed because it does not violate a previous chroot? (since I don't chroot(), I don't know the existing behavior here.) Are there any other chroot caveats? Please figve any ignorance as to the current behavior in BSD -- I'm relatively new to the kernel implementation, although have been using and administering BSD-based machines for a number of years. Robert Watson From owner-freebsd-security Tue Jul 8 13:41:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA07305 for security-outgoing; Tue, 8 Jul 1997 13:41:53 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA07259 for ; Tue, 8 Jul 1997 13:41:24 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id WAA20525 for ; Tue, 8 Jul 1997 22:40:50 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id WAA29243 for security@FreeBSD.ORG; Tue, 8 Jul 1997 22:40:20 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.6/keltia-uucp-2.9) id WAA14236; Tue, 8 Jul 1997 22:20:33 +0200 (CEST) Message-ID: <19970708222033.09272@keltia.freenix.fr> Date: Tue, 8 Jul 1997 22:20:33 +0200 From: Ollivier Robert To: security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? References: <9707072348.AA21807@communica.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: ; from Robert Watson on Tue, Jul 08, 1997 at 11:58:43AM -0400 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3392 AMD-K6 MMX @ 208 MHz Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Robert Watson: > Symlinks don't have the same problem in that they aren't suid (or such), > but still cannot be deleted by a regular user if created in a sticky-bit > environment. Just to clarify, they can now be deleted in CURRENT as of 3/31/97 because Peter changed them back (yeah!) peter 97/03/31 04:03:04 Modified: sys/kern vfs_syscalls.c sys/ufs/ufs ufs_lookup.c ufs_vnops.c Log: Treat symlinks as first class citizens with their own uid/gid rather than as shadows of their containing directory. This should solve the problem of users not being able to delete their symlinks from /tmp once and for all. Symlinks do not have modes though, they are accessable to everything that can read the directory (as before). They are made to show this fact at lstat time (they appear as mode 0777 always, since that's how the the lookup routines in the kernel treat them). More commits will follow, eg: add a real lchown() syscall and man pages. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #20: Fri Jun 13 00:16:13 CEST 1997 From owner-freebsd-security Tue Jul 8 14:03:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA08525 for security-outgoing; Tue, 8 Jul 1997 14:03:17 -0700 (PDT) Received: from shandakor.tharsis.com (root@robbins.jvnc.net [204.143.70.105]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA08520 for ; Tue, 8 Jul 1997 14:03:08 -0700 (PDT) Received: (from grr@localhost) by shandakor.tharsis.com (8.7.6/8.7.3) id RAA02949; Tue, 8 Jul 1997 17:00:18 -0400 (EDT) Date: Tue, 8 Jul 1997 17:00:18 -0400 (EDT) From: George Robbins Message-Id: <199707082100.RAA02949@shandakor.tharsis.com> To: adam@homeport.org, robert@cyrus.watson.org Subject: Re: Security Model/Target for FreeBSD or 4.4? Cc: freebsd-security@freebsd.org, tech@openbsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From: Robert Watson > To: Adam Shostack > cc: freebsd-security@freebsd.org, tech@openbsd.org > Subject: Re: Security Model/Target for FreeBSD or 4.4? > > With regards to gid vs. uid -- is either one of this preferable for any > particular reason? gid may be more flexible, I guess, as it would allow > multiple users to bind the same ports, but without having rights to each > others processes, and as such allow a simpler minimum configuration. I don't want to sound like a grinch, but this seems like a poor direction to be headed in. The kernel is blessedly free of "special values" for UID's and GID's. Like one really special UID=0 (*) and done with it. File system protections are the general access control method and if you want to layout something with a lot of cases, this should given first consideration. (*) there are other special values, but typically the kernel does not explicitly test for them, they fail to be 0 or fail to match an opaque ID. Not even sure there are any special GID's, the group 0 allowed to su can be handled at the applications level. Groge From owner-freebsd-security Tue Jul 8 17:34:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA19672 for security-outgoing; Tue, 8 Jul 1997 17:34:26 -0700 (PDT) Received: from goliath.camtech.com.au (goliath.camtech.net.au [203.5.73.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19651 for ; Tue, 8 Jul 1997 17:34:21 -0700 (PDT) Received: from sebastion.sa.camtech.com.au (sebastion.sa.camtech.com.au [203.28.3.2]) by goliath.camtech.com.au (8.8.5/8.8.2) with ESMTP id KAA25628; Wed, 9 Jul 1997 10:02:34 +0930 (CST) Received: (from uucp@localhost) by sebastion.sa.camtech.com.au (8.6.10/8.6.10) id KAA16146; Wed, 9 Jul 1997 10:04:56 +0930 Received: from frenzy(192.168.4.65) by sebastion via smap (V1.3) id sma016128; Wed Jul 9 10:04:28 1997 Received: by communica.com.au (4.1/SMI-4.1) id AA06358; Wed, 9 Jul 97 09:59:34 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9707090029.AA06358@communica.com.au> Subject: Re: Security Model/Target for FreeBSD or 4.4? To: robert@cyrus.watson.org (Robert Watson) Date: Wed, 9 Jul 1997 09:59:33 +0930 (CST) Cc: newton@communica.com.au, sef@kithrup.com, security@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Jul 8, 97 11:58:43 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Robert Watson wrote: > > > On a related note, has anyone given any thought to making chroot() a > > > user-accessible call? > > Yow. Extremely bad idea. > > However, taking it to the opposite extreme is a good idea. chroot() loses > > its usefulness if a process in a "secured" sandbox can conceivably get > > root privileges -- Solution: Restrict the chroot() call for *all* > > processes that are already chroot()ed. > > I was familiar with the actual behavior and implementation of chroot with > the processes root, but had never really used it for anything, as it tends > to be a more-restricted facility. ... which is exactly why those who actually WANT to provide a more restricted facility use it, and will resist efforts to make it less restricted! > Can the problems with chroot() safely be sumarized in the following > categories? > 1. Existing libraries and utilities assume that if they attempt to access > /etc/spwd.db (or such), they will get these files off of the absolute > root. Not necessarily - If I boot from the fixit floppy to repair a filesystem problem, I'd kinda expect my system to behave in a way that closely approximates single-user modem booted from the hard disk if I execute "chroot /rootdisk /bin/sh". It's difficult to perform tests to make sure that the filesystem problem has been fixed if executables I run don't require the dodgy filesystem to run! Also, if I'm using chroot() to make a sandbox for a user in a restricted environment, I'm quite happy to assume that existing utilities will see all files relative to their current root directories, rather than the "absolute" root (if there is such a thing -- All we really have is a vnode address, which eventually translates to an inode number, after all :-). I don't want a user in a restricted environment to type "login unrestricteduser" and have a bash at guessing their password or somesuch, all because the login command is using /etc/spwd.db in the "real" root! If I put a process in a sandbox, I expect it to *stay* in the sandbox. > This may not be changeable, as there are a number of environments > where this might be appropriate (boot from floppy, but chroot to mfs/mfs, > for example -- the mfs/nfs version of the user database should be used, > not the floppy version (same with libraries, etc.)) Bleych. Strongly disagree. If you want to run a binary and use libraries on the "real" root, don't use chroot()! If you've booted from a floppy you have root privileges anyway, and can chroot() to your heart's content. > 2. Creation of hard links retains the setuid behavior of the program, as > the permissions and ownership of a file are stored in the inode, and a > hardlink merely duplicates the reference to the inode (so I can create > /tmp/su as a hard link to /usr/sbin/su, assuming they are both on /usr, > and retain the suid and ownership.) This has upsides and downsides -- one > downside is if I chroot() myself to /tmp, the existing su will suffer from > problem 1. The problem here is that I, as a normal user, can create > arbitrary references to suid programs (effectively, instances of them) > anywhere I can write to on the same file system. /usr/tmp and /tmp are > the most common problem in this area. That's not a "problem", it's just a feature. Under normal circumstances, creating additional references to setuid executables isn't a problem, because those executables will (we hope) carry out suitable permission checks before doing anything nasty. The "problem" is the use of chroot() by those who don't understand how it works, not the user of chroot() per se. > There are other side effects of this behavior -- as a normal user, I can > fill up /tmp with files I can't remove (as sticky bit prevents me from > removing references to files I don't own.) So? You're not really "filling up" /tmp, you're just creating directory entries. And you can do that with hard links whether the files in question are setuid or not. Nobody has really cared all that much for the last fifteen years. > Additionally, I can hard link > /usr/sbin/su (old buggy version) to /usr/tmp/su before an upgrade to fix > the bug, and then the upgrade will leave the old version in /usr/tmp/su (I > assume it unlinks the /usr/sbin/su version during upgrade?) Programs may > assume that by overwriting (unlinking first) the old version of a setuid > program, they are disposing of it, but this may not be true since hard > links have the same permissions and content (being the same file :). Again, this isn't a problem with hard links, it's a problem with negligent system administration. If you've taken on the proactive task of hard linking /usr/sbin/su to /usr/tmp/su, it is expected that you have sufficient presence of mind to clean up after yourself when you don't need it anymore. We don't go altering the semantics of fundamental syscall/kernel behaviour just to make up for the personal deficiencies of sysadmins who don't know what they're doing, or to cater for contrived scenarios which, you'd have to admit, are unlikely to occur anyway. We're not Microsoft: We can't run under the assumption that those looking after a UNIX system are totally brainless. If someone is stupid enough to make a mistake, it isn't the OS's job to proect them from it. > Symlinks don't have the same problem in that they aren't suid (or such), The problem is not the link. The problem is the sysadmin. > 3. Current chroot() allows you to undo an old chroot(). If chroot were to > become a generally useable call (or even if not), chroot() should only be > able to move down the hierarchy, not up. That is a sound description of the current chroot() semantics -- Kinda. Absolute pathnames supplied to chroot() are "relative" to the current root directory. "relative" pathnames are, well, anyone's guess. > This would make it more > transparent as far as the caller was concerned -- they would not have ot > know if they were already chroot'd. If the entire filesystem is already > chroot("/mfsroot"), then an ftpd chroot("/usr/ftp") would chroot > effectively to "/mfsroot/usr/ftp", and be allowed because it does not > violate a previous chroot? That is what currently happens. What I attempted to stress in my last message which I appear to have to stress again is that the act of chroot()ing to /usr/ftp in that case DOESN'T ALTER THE PROCESS' CURRENT DIRECTORY (caps used for emphasis, not shouting :-). If my current directory is /mfsroot and I execute `chroot("/usr/ftp")', my CURRENT directory relative to the "real" root is *STILL* /mfsroot, even though my root directory relative to the "real" root is /mfsroot/usr/ftp. That is to say, by using chroot() I've managed to get myself outside my own root directory heirarchy. The manpage stays this explicitly too, so you can't be forgiven for missing it. From chroot(2): It should be noted that chroot() has no effect on the process's current directory. Despite the fact that I'm now NOT in a directory that's downstairs from my root, the ".." directory will still take me to the parent of my current directory -- FURTHER AWAY from my root directory. So, if my root is /mfsroot/usr/ftp and my current directory relative to the "real" root is /mfsroot, after a `chdir("..")' my current directory will be the "real" root. Then all I need to do is `chroot(".")' and hey presto, I'm out of the chroot()ed environment. To stipulate that chroot() can't do that because "." is further up the heirarchy than /mfsroot/usr/ftp is a difficult problem, because the root directory is not recorded in the proc structure as a pathname: it's recorded as a vnode address (which makes sense: Otherwise every reference to root() would need an additional namei() call, which isn't exactly an efficient way to do things). Even if pathnames were used in the proc structure, that still wouldn't be a win because there's nothing to say that the pathname recorded as your root isn't a symlink or hard link to a directory further "up" the heirarchy anyway: If /mfsroot/usr/ftp is a symlink to /mfsroot/ftp and I do `chroot(".")' when my current directory relative to the "real" root is "/mfsroot/ftp/foo" I *should* be able to do the chroot() successfully, even though the pathname recorded in my proc structure (/mfsroot/usr/ftp) appears to be in a different subdirectory branch to the pathname I'm trying to chroot(). Name to inode number translations are trivial (namei()). Inode number to name translations are non-trivial (find / -inum xxxxx -print). They'd be required to implement your semantics, however. > (since I don't chroot(), I don't know the existing behavior here.) Same as what you're asking for, *EXCEPT* like essentially every other kernel facility, chroot has no idea whether the pathname you're referencing is further "up" the directory than some other arbitrary inode number. The UNIX heirarchical filesystem structure is an illusion created by name-to-inode-number mapping tables that we happen to call directories, provided for no reason other than the fact that humans find it more natural to deal with names than numbers. Internally, the filesystem can be thought of as a single flat address space of inodes. In isolation, an inode number does not provide any clue whatsoever about the location of the file it references in the directory heirarchy because nothing apart from namei() gives a toss about the directory heirarchy. > Are there any other chroot caveats? Please figve any ignorance as to the > current behavior in BSD -- I'm relatively new to the kernel > implementation, although have been using and administering BSD-based > machines for a number of years. Try this out: Build a quick chroot()able environment on any UNIX system (doesn't have to be BSD): unix# cd / unix# mkdir chroot unix# tar cfl - . | (cd chroot; tar xvfp -) Change /chroot/root/.cshrc so that root's prompt is "chrooted# " instead of "unix# " so that you can see which directory root is getting its startup files from. Compile the code fragment I posted yesterday which I claimed broke out of a chroot() environment and stuff the executable into /chroot. Then: unix# rm /chroot/etc/hosts unix# chroot /chroot /bin/csh chrooted# ls /etc/hosts # shoved into our jail ls: /etc/hosts: No such file or directory chrooted# ./breakout-code-fragment unix# ls /etc/hosts # wow! we've broken out! /etc/hosts unix# Study the code carefully in light of this discussion. Realize that providing arbitrary users with the ability to run chroot() would allow arbitrary users to break out of sandboxen. Examine the patch I posted and see how it prevents the scenario listed above, at the sacrifice of a certain amount of existing functionality (I'm not arguing that the patch be made standard; I'm just happy to have it available for those building firewalls and such who might actually need it). Finally, I've been having trouble getting a clear idea of what you're trying to achieve here. I suspect that you have a specific case in mind where providing arbitrary users with the ability to chroot() would solve a problem you've been having. If so, perhaps presenting the problem instead of putting the solution first might be helpful in this discussion, and might enable ConcernedReaders to propose a solution that doesn't involve fundamental redesign (design? not really. re-frobbing :-) of a standard kernel facility that is heavily relied upon in security- critical environments. What applications do you see that'd be more readily implemented if arbitrary users could chroot()? - mark [ oh, for the old days, when "chroot" meant "cigar," and life was that much simpler ] --- Mark Newton Email: newton@communica.com.au Systems Engineer and Senior Trainer Phone: +61-8-8303-3300 Communica Systems, a member of the Fax: +61-8-8303-4403 CAMTECH group of companies WWW: http://www.communica.com.au From owner-freebsd-security Wed Jul 9 02:03:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA06402 for security-outgoing; Wed, 9 Jul 1997 02:03:54 -0700 (PDT) Received: from monoid.cs.tcd.ie (ts19-09.dublin.indigo.ie [194.125.134.159]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA06397 for ; Wed, 9 Jul 1997 02:03:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with SMTP id UAA01307; Tue, 8 Jul 1997 20:33:46 +0100 (BST) Message-Id: <199707081933.UAA01307@monoid.cs.tcd.ie> X-Authentication-Warning: monoid.cs.tcd.ie: localhost [127.0.0.1] didn't use HELO protocol To: Robert Watson cc: freebsd-security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: (Home)+353-(0)1-6765859 (College)+353-(0)1-7021321 X-PGP: Public Key on Request In-reply-to: Message from Robert Watson dated today at 11:45. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1301.868390423.1@monoid> Content-Description: text Date: Tue, 08 Jul 1997 20:33:44 +0100 From: Colman Reilly Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [deleted stuff about changing sockets so that they could be bound to by groups/users] With regards to gid vs. uid -- is either one of this preferable for any particular reason? gid may be more flexible, I guess, as it would allow multiple users to bind the same ports, but without having rights to each others processes, and as such allow a simpler minimum configuration. I think that if someone where to do this sort of thing then it should be according to the normal UNIX rules: (READ,WRITE,EXECUTE)X(USER,GROUP,PUBLIC). I'm not sure execute means anything in this context. This gives you maximal control, and you just default to the current behaviour. (I'd imagine a hash-table based implementation, which only incurs overhead when there are changed permissions. No hit in the hash table means default behaviour - open with port<1024 => fail for everyone except root.) Colman From owner-freebsd-security Wed Jul 9 09:09:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA21676 for security-outgoing; Wed, 9 Jul 1997 09:09:56 -0700 (PDT) Received: from cyrus.watson.org (robert@cyrus.watson.org [207.86.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA21661 for ; Wed, 9 Jul 1997 09:09:51 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id MAA00252; Wed, 9 Jul 1997 12:09:36 -0400 (EDT) Date: Wed, 9 Jul 1997 12:09:35 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: Mark Newton cc: newton@communica.com.au, sef@kithrup.com, security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <9707090029.AA06358@communica.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Study the code carefully in light of this discussion. Realize that > providing arbitrary users with the ability to run chroot() would allow > arbitrary users to break out of sandboxen. Examine the patch I posted > and see how it prevents the scenario listed above, at the sacrifice > of a certain amount of existing functionality (I'm not arguing that > the patch be made standard; I'm just happy to have it available for > those building firewalls and such who might actually need it). > > Finally, I've been having trouble getting a clear idea of what you're > trying to achieve here. I suspect that you have a specific case in > mind where providing arbitrary users with the ability to chroot() would > solve a problem you've been having. If so, perhaps presenting the > problem instead of putting the solution first might be helpful in this > discussion, and might enable ConcernedReaders to propose a solution that > doesn't involve fundamental redesign (design? not really. re-frobbing :-) > of a standard kernel facility that is heavily relied upon in security- > critical environments. > > What applications do you see that'd be more readily implemented if > arbitrary users could chroot()? > > - mark > [ oh, for the old days, when "chroot" meant "cigar," and life > was that much simpler ] > Thank you for your detailed response and description of the chroot() security issues :). I've spent a significant amount of time working in the network security area, but other than as an administrator, not much time on internal issues. I appreciate your clarification of the existing code, and explanations. My interest in making chroot() a general-purpose facility stem from the following concerns: Programs should be able to impose restrictions on their own execution, allowing them to reduce the impact of their running on the system (e.g., setting their nice level higher, or restricting memory allocation), or for security purposes, where the programmer has the best intentions, but cannot garuntee that their code cannot be exploited. If a programmer can restrict the execution of their code to a specific disk area, they have a useful tool. Currently, programs that provide network services and wish to execute in a chroot() environment must be run as root, then seteuid() (is that the correct call) to return to the userid they are intended to run as. Similarly, programs that serve complex network services (such as WWW services) benefit from a chroot() environment. It's popular, for example, to have ftpd or httpd run in chroot(), as enough problems have been found with these pieces of software that chroot() can make a significant difference in their security. This is especially the case where cgi programs are executed, as the system administrator may not want arbitrary user programs run by the web server to have access to the entire system. Right now, all these programs begin execution as root anyway (they must be root to bind <1024, or because they change userid's based on authentication.) In the case of the web server, if chroot() is only offered to uid 0 programs, I have the following choice: 1. Run the server as root, have it bind, chroot, and then seteuid to the www user 2. Run the server as www, have it bind the port (now permitted), but lose the added security of chroot(). Web servers have suffered from security problems for both running as root, and for having general file system access. Other servers suffer similarly. In the case of a commercial web server (not unusual) where the source code is not available, I'm not sure I want to trust their program to correctly give up root access on running, although I do want it to benefit from chroot() and the ability to bind tcp port 80. A few other examples: should a mail server running as user mail have access to the entire file system? It no longer has to run as root because it can bind port 25 by itself (as authorized), and, except for local mail delivery, it doesn't require access to anywhere in the file system but /var/mqueue (and possibly some other config, statistics, user-info files.) Some simple rewriting of sendmail based on running as non-root, and having user-chroot() would be of great benefit. It seems like a fairly simple arguement: I have a server program that provides information on calendar schedules over the network to interested clients. It cannot benefit from access to the entire file system (it has /home/calendar/ as its entire tree of information and responses.) It could do harm to the system if it did have such access. If a suitable security policy is to provide only the rights that are needed to perform the required actions, shouldn't we provide a user facility for this? As a developer, I suspect I should not have to ask my system administrator to make a program suid to take advantage of this. Another example might be a web browser: with the advent of Java, the concept of a "sandbox" for arbitrary program execution has become very popular. But we are consistently finding holes in web browsers, and in the sandboxes, and currently proposals exist to weaken the sandbox. It's easy to answer "if you don't like the behavior of the software, don't run it", but that doesn't make it easier for the administrator of a distributed networking environment to maintain a reasonable version of Netscape across 200 machines. For normal browsing, Java applet execution, there is no reason to allow Netscape read access to my /etc directory, or write access to /usr/tmp. That the current implementation of the chroot() call is not suitable for this use doesn't make the concept of a user-chroot() any less useful. :) As a software designer, I should take every precaution when designing my code that it cannot be abused, but when developing extremely large projects (named, sendmail, httpd) involving many programmers, and much contributed code, I also cannot rely on their being no problems at all. In this case, having the operating system provide some level of buffering might be helpful. A user chroot would presumably have greater limitations, or might prevent the execution of suid(), for example. It might only be available to non-root programs. Are there limitations that could address all of the problems with allowing users to access the uid0 chroot() call we currently are aware of? A question about the creation of hard links: what are the advantages of allowing uid 1000 to create a hard link in his directory to /usr/sbin/su, owned by uid 0? Hard links seem to be a useful facility, but are they commonly used between uids? Robert Watson From owner-freebsd-security Wed Jul 9 09:58:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA24636 for security-outgoing; Wed, 9 Jul 1997 09:58:59 -0700 (PDT) Received: from bitbox.follo.net (eivind@bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24629 for ; Wed, 9 Jul 1997 09:58:55 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.5/8.7.3) id SAA00433; Wed, 9 Jul 1997 18:58:08 +0200 (CEST) Date: Wed, 9 Jul 1997 18:58:08 +0200 (CEST) Message-Id: <199707091658.SAA00433@bitbox.follo.net> From: Eivind Eklund To: Robert Watson CC: adam@homeport.org, freebsd-security@FreeBSD.ORG, tech@openbsd.org In-reply-to: Robert Watson's message of Tue, 8 Jul 1997 11:45:57 -0400 (EDT) Subject: Re: Security Model/Target for FreeBSD or 4.4? References: <199707080110.VAA21941@homeport.org> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > With regards to gid vs. uid -- is either one of this preferable for any > particular reason? gid may be more flexible, I guess, as it would allow > multiple users to bind the same ports, but without having rights to each > others processes, and as such allow a simpler minimum configuration. GIDs are (always?) preferable, as they don't allow overwrite of other programs with the same setgid. They don't even allow overwrite of the same program, come to think of it :) (Ref: `man' exploits) Eivind. From owner-freebsd-security Wed Jul 9 14:50:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA13977 for security-outgoing; Wed, 9 Jul 1997 14:50:56 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA13970 for ; Wed, 9 Jul 1997 14:50:52 -0700 (PDT) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.5/8.6.10) id OAA19064 for ; Wed, 9 Jul 1997 14:50:47 -0700 (PDT) Message-Id: <199707092150.OAA19064@passer.osg.gov.bc.ca> Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost, id smtpdAAAaarxma; Wed Jul 9 14:50:45 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH X-Sender: cschuber To: security@freebsd.org Subject: Divert Sockets Date: Wed, 09 Jul 1997 14:50:43 -0700 From: Regards@uumail.gov.bc.ca, "Phone: (250)387-8437" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Are there any examples on the use of divert sockets to create an application proxy? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca For help with Sun problems, send mail to sun-team@uumail.gov.bc.ca. For help with DEC problems, send mail to dec-team@uumail.gov.bc.ca. For help with Legato problems, send mail to backup-team@uumail.gov.bc.ca. For Legato service requests, send mail to backup-request@uumail.gov.bc.ca. "Quit spooling around, JES do it." From owner-freebsd-security Wed Jul 9 15:10:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA15531 for security-outgoing; Wed, 9 Jul 1997 15:10:48 -0700 (PDT) Received: from burgundy.eecs.harvard.edu (dholland@burgundy.eecs.harvard.edu [140.247.60.165]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA15526 for ; Wed, 9 Jul 1997 15:10:37 -0700 (PDT) Received: (from dholland@localhost) by burgundy.eecs.harvard.edu (8.8.5/8.8.5) id SAA11291; Wed, 9 Jul 1997 18:09:42 -0400 (EDT) From: David Holland Message-Id: <199707092209.SAA11291@burgundy.eecs.harvard.edu> Subject: Re: Security Model/Target for FreeBSD or 4.4? To: newton@communica.com.au (Mark Newton) Date: Wed, 9 Jul 1997 18:09:42 -0400 (EDT) Cc: robert@cyrus.watson.org, newton@communica.com.au, sef@kithrup.com, security@FreeBSD.ORG In-Reply-To: <9707090029.AA06358@communica.com.au> from "Mark Newton" at Jul 9, 97 09:59:33 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Study the code carefully in light of this discussion. Realize that > providing arbitrary users with the ability to run chroot() would allow > arbitrary users to break out of sandboxen. There are two ways to fix this: (1) disallow chroot(8) if a chroot has already been performed, that is, the process's root is not the same as the global root, or (2) fix the mechanism that prevents "cd .." from the chrooted root so that if you set a new root directory it doesn't permit going up past the previous root directory. (If this is what your patch did, never mind.) It's not at all clear that fixing this is sufficient to keep root in a chroot area, though. The general opinion in many circles is that it's too hard to accomplish that and not worth trying. -- - David A. Holland | VINO project home page: dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino From owner-freebsd-security Wed Jul 9 22:03:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA06700 for security-outgoing; Wed, 9 Jul 1997 22:03:26 -0700 (PDT) Received: from obie.softweyr.ml.org ([199.104.124.49]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA06692 for ; Wed, 9 Jul 1997 22:03:19 -0700 (PDT) Received: (from wes@localhost) by obie.softweyr.ml.org (8.7.5/8.6.12) id XAA10500; Wed, 9 Jul 1997 23:07:58 -0600 (MDT) Date: Wed, 9 Jul 1997 23:07:58 -0600 (MDT) Message-Id: <199707100507.XAA10500@obie.softweyr.ml.org> From: Wes Peters To: security@freebsd.org Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: References: <199707061827.OAA23298@chaos.amber.org> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 06-Jul-97 Christopher Petrilli wrote: > I think it's important to understand that few OSes (outside the "big > boys" like VMS, MVS, VM, GUARDIAN, etc.) have documented formal security > polcies. Mostly it's just whatever a programmer feels like. Or SunOS, Solaris, Digital UNIX. Yes, there have been (several) UNIX systems certified at C2, and even B2. It would be interesting to see if Sun still has any white papers or specifications for their B2 certified SunOS, which was (of course) based on 4.3 BSD. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-security Thu Jul 10 03:12:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA22283 for security-outgoing; Thu, 10 Jul 1997 03:12:32 -0700 (PDT) Received: from bitbox.follo.net (eivind@bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA22266 for ; Thu, 10 Jul 1997 03:12:19 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.5/8.7.3) id MAA02476; Thu, 10 Jul 1997 12:11:54 +0200 (CEST) Date: Thu, 10 Jul 1997 12:11:54 +0200 (CEST) Message-Id: <199707101011.MAA02476@bitbox.follo.net> From: Eivind Eklund To: cschuber@uumail.gov.bc.ca, security@freebsd.org In-reply-to: Regards@uumail.gov.bc.ca, "Phone:'s message of Wed, 09 Jul 1997 14:50:43 -0700 Subject: Re: Divert Sockets References: <199707092150.OAA19064@passer.osg.gov.bc.ca> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Are there any examples on the use of divert sockets to create an application > proxy? natd, and that is more or less it. And this question probably belong in -questions or potentially -hackers, not -security. Eivind.