From owner-freebsd-security Sun Jan 5 16:49:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA25993 for security-outgoing; Sun, 5 Jan 1997 16:49:23 -0800 (PST) Received: from fools.ecpnet.com (moke@fools.ecpnet.com [204.246.64.101]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA25986 for ; Sun, 5 Jan 1997 16:49:20 -0800 (PST) Received: from localhost (moke@localhost) by fools.ecpnet.com (8.8.4/8.8.4) with SMTP id SAA19982 for ; Sun, 5 Jan 1997 18:47:31 -0600 (CST) Date: Sun, 5 Jan 1997 18:47:29 -0600 (CST) From: Jimbo Bahooli To: freebsd-security@freebsd.org Subject: sendmail....tricks... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well in watching this mailing list and many others, the solution to the sendmail problem seems to be not run it as root. Yet, because of the performance hit many do not wish to start it from inetd. I have found somewhat of hack solution with a few downfalls, but seems to work. The first idea, which i have successfully accomplished, is logging and access control via tcp wrappers. This idea uses netcat, /usr/ports/net/netcat, and some configuration. First, I setup sendmail to bind to a different port by changing this line in sendmail.cf to: O DaemonPortOptions=Port=26 This could easily be a port above 1024 allowing it to bind to its port as a non-root user. Second, I linked /usr/local/bin/nc (netcat) to /usr/local/bin/recvmail to make logs more readable when tcp wrappers style logging is used. Third, I added a line to /etc/inetd.conf, smtp stream tcp nowait nobody /usr/libexec/tcpd /usr/local/bin/recvmail -w 3 127.0.0.1 26 (all on one line of course) Restarted everything, and now I get nice log entries of each mail connect, with the increased overhead of running a netcat, which compared to a new sendmail from inetd is very small. Any comments on this? Time permitting I am going to explore running sendmail on a non-root port and having netcat forward connections to it from inetd. -moke@fools.ecpnet.com From owner-freebsd-security Sun Jan 5 18:01:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA29506 for security-outgoing; Sun, 5 Jan 1997 18:01:08 -0800 (PST) Received: from terra.stack.nl (terra.stack.nl [131.155.140.128]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA29494 for ; Sun, 5 Jan 1997 18:01:03 -0800 (PST) Received: (from uucp@localhost) by terra.stack.nl (8.8.4) with UUCP id CAA12812; Mon, 6 Jan 1997 02:58:33 +0100 (MET) Received: (from maikel@localhost) by escape.stack.nl (8.8.4/8.8.4) id CAA09010; Mon, 6 Jan 1997 02:53:06 +0100 From: Maikel Verheijen Message-Id: <199701060153.CAA09010@escape.stack.nl> Subject: Re: sendmail....tricks... To: moke@fools.ecpnet.com (Jimbo Bahooli) Date: Mon, 6 Jan 1997 02:53:05 +0100 (MET) Cc: freebsd-security@freebsd.org In-Reply-To: from "Jimbo Bahooli" at Jan 5, 97 06:47:29 pm Reply-To: maikel@stack.nl 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 Quoting "Jimbo Bahooli": Any comments on this? Time permitting I am going to explore running sendmail on a non-root port and having netcat forward connections to it from inetd. What if people start connecting to the real sendmail??? If there are vulnerabilities in sendmail, they can still read the mails of all users on the system (If the attacker has an account) -moke@fools.ecpnet.com Greetings, Maikel Verheijen From owner-freebsd-security Sun Jan 5 18:15:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA00226 for security-outgoing; Sun, 5 Jan 1997 18:15:26 -0800 (PST) Received: from fools.ecpnet.com (moke@fools.ecpnet.com [204.246.64.101]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA00172 for ; Sun, 5 Jan 1997 18:14:41 -0800 (PST) Received: from localhost (moke@localhost) by fools.ecpnet.com (8.8.4/8.8.4) with SMTP id UAA01072; Sun, 5 Jan 1997 20:09:58 -0600 (CST) Date: Sun, 5 Jan 1997 20:09:57 -0600 (CST) From: Jimbo Bahooli To: maikel@stack.nl cc: freebsd-security@freebsd.org Subject: Re: sendmail....tricks... In-Reply-To: <199701060153.CAA09010@escape.stack.nl> 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, 6 Jan 1997, Maikel Verheijen wrote: > Quoting "Jimbo Bahooli": > Any comments on this? Time permitting I am going to explore running > sendmail on a non-root port and having netcat forward connections to it > from inetd. > What if people start connecting to the real sendmail??? If there are > vulnerabilities in sendmail, they can still read the mails of all users > on the system (If the attacker has an account) > > -moke@fools.ecpnet.com > > Greetings, > Maikel Verheijen Well sendmail needs to access the users mail files, there is no way around this. Its the lesser of two evils, I'd rather have someone reading users emails, then running around my system uid 0. About connecting to the 'real' sendmail, that would just bypass logging. If the sendmail was running non-root on a non-root port it would have no effect because it still would not be running as root, the redirector on port 25 is just to make it compatible with the rest of the worlds systems. -moke@fools.ecpnet.com From owner-freebsd-security Sun Jan 5 18:46:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA01811 for security-outgoing; Sun, 5 Jan 1997 18:46:24 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA01806 for ; Sun, 5 Jan 1997 18:46:21 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id SAA01229 for ; Sun, 5 Jan 1997 18:47:10 -0800 (PST) Received: (qmail 12280 invoked by uid 110); 6 Jan 1997 02:45:58 -0000 Message-ID: <19970106024558.12279.qmail@suburbia.net> Subject: Re: sendmail....tricks... In-Reply-To: from Jimbo Bahooli at "Jan 5, 97 08:09:57 pm" To: moke@fools.ecpnet.com (Jimbo Bahooli) Date: Mon, 6 Jan 1997 13:45:58 +1100 (EST) Cc: maikel@stack.nl, freebsd-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 > > On Mon, 6 Jan 1997, Maikel Verheijen wrote: > > Maikel Verheijen > > Well sendmail needs to access the users mail files, there is no way around > this. Its the lesser of two evils, I'd rather have someone reading users > emails, then running around my system uid 0. > > About connecting to the 'real' sendmail, that would just bypass logging. > If the sendmail was running non-root on a non-root port it would have no > effect because it still would not be running as root, the redirector on > port 25 is just to make it compatible with the rest of the worlds systems. > > -moke@fools.ecpnet.com > > > See my new firewall code for a solution. From owner-freebsd-security Mon Jan 6 01:45:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA23519 for security-outgoing; Mon, 6 Jan 1997 01:45:01 -0800 (PST) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA23507 for ; Mon, 6 Jan 1997 01:44:55 -0800 (PST) Received: (from uucp@localhost) by perki0.connect.com.au id UAA19151 (8.7.6h/IDA-1.6); Mon, 6 Jan 1997 20:41:08 +1100 (EST) >Received: from localhost.nemeton.com.au (localhost.nemeton.com.au [127.0.0.1]) by nemeton.com.au (8.8.4/8.8.4) with SMTP id UAA00711; Mon, 6 Jan 1997 20:04:41 +1100 (EST) Message-Id: <199701060904.UAA00711@nemeton.com.au> To: Jimbo Bahooli cc: freebsd-security@freebsd.org Subject: Re: sendmail....tricks... In-reply-to: Date: Mon, 06 Jan 1997 20:04:41 +1100 From: Giles Lean Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 5 Jan 1997 18:47:29 -0600 (CST) Jimbo Bahooli wrote: > The first idea, which i have successfully accomplished, is logging and > access control via tcp wrappers. Interesting; I think I'd go about it differently: Since sendmail currently supports using libwrap from Wietse Venema's tcp_wrappers distribution, this could be used to block non-local access to sendmail. With remote access to sendmail blocked it can use a non-standard port and smap/smapd from the TIS firewall toolkit could be used to talk to strangers. (Alternative to libwrap is one of the in-kernel firewalling solutions, but I don't think these log as well as application level checking, and must lose at least a little in performance for ordinary traffic.) Access control isn't a lot of use for SMTP, anyway. Remember that a single SMTP connection can transfer multiple independent items of mail (The latest sendmail caches connections, too, making the multiple items per connection much more likely.) Worse than cached connections is the store and forward nature of Internet mail. You can block access to port 25 from my site, but all my mail goes via my ISP. If you block access from my ISP, you lose connectivity to all their clients, and they're about the largest ISP in Australia. Whoops!? Giles From owner-freebsd-security Mon Jan 6 12:01:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA24282 for security-outgoing; Mon, 6 Jan 1997 12:01:57 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA24274 for ; Mon, 6 Jan 1997 12:01:54 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id MAA16299 for ; Mon, 6 Jan 1997 12:02:36 -0800 (PST) Received: (qmail 16169 invoked by uid 110); 6 Jan 1997 20:01:16 -0000 Message-ID: <19970106200116.16168.qmail@suburbia.net> Subject: new firewall code [uid/gid/bind() etc] To: hackers@freebsd.org, security@freebsd.org Date: Tue, 7 Jan 1997 07:01:16 +1100 (EST) 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 I tried posting the patches but, at 55k, it seems majordumbo has (silently) rejected them. You may find them at: ftp://suburbia.net/tmp/ipfw.diff My "socket credentials" patches allow you to: punch wormholes, or restrict access to the IPPORT_RESERVED space, or restrict access to bind() altogether based on: (a) uid (b) gid (including secondary groups) (c) port (d) protocol (e) interface And more importantly: Restrict access to packets being sent/received on any socket based on: (a) the packet (per normal ipfw rules) (b) uid (c) gid (including secondary groups) The former permits constructs like: /* let uid sendmail bind to port 25 */ # ipfw add accept wormhole on tcp from any 25 to any uid sendmail bind /* only let inetd bind - we presume inetd still needs to run as root for uid switching when forking off clients */ # addgroup inetd # chgrp inetd /usr/sbin/inetd # chmod 2700 /usr/sbin/inetd # killall inetd # ipfw add accept all from any to any bind gid inetd uid root # /* default policy is to deny bind */ /* keep those without security clearance out of secret network */ # ipfw add accept all from any to any via ed0 gid secret # ipfw add deny all from any to any via ed0 gid any Loging has also been enhanced: # ipfw add 60000 accept log all from any to any bind /* example of named starting up */ ipfw: 5000 Allow TCP 0.0.0.0:53 0.0.0.0:0 uid 67 gid 0 pid 1280 bind ipfw: 5000 Allow UDP 203.4.184.222:53 0.0.0.0:0 via ed0 uid 67 gid 0 pid 1280 bind ipfw: 5000 Allow UDP 203.4.184.217:53 0.0.0.0:0 via ppp0 uid 67 gid 0 pid 1280 bind ipfw: 5000 Allow UDP 127.0.0.1:53 0.0.0.0:0 via lo0 uid 67 gid 0 pid 1280 bind ipfw: 5000 Allow UDP 0.0.0.0:53 0.0.0.0:0 uid 67 gid 0 pid 1280 bind Cheers, Julian From owner-freebsd-security Mon Jan 6 13:02:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA27827 for security-outgoing; Mon, 6 Jan 1997 13:02:23 -0800 (PST) Received: from fools.ecpnet.com (moke@fools.ecpnet.com [204.246.64.101]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA27822 for ; Mon, 6 Jan 1997 13:02:17 -0800 (PST) Received: from localhost (moke@localhost) by fools.ecpnet.com (8.8.4/8.8.4) with SMTP id PAA00357; Mon, 6 Jan 1997 15:00:17 -0600 (CST) Date: Mon, 6 Jan 1997 15:00:17 -0600 (CST) From: Jimbo Bahooli To: Giles Lean cc: freebsd-security@freebsd.org Subject: Re: sendmail....tricks... In-Reply-To: <199701060904.UAA00711@nemeton.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 Mon, 6 Jan 1997, Giles Lean wrote: > > On Sun, 5 Jan 1997 18:47:29 -0600 (CST) Jimbo Bahooli wrote: > > > The first idea, which i have successfully accomplished, is logging and > > access control via tcp wrappers. > > Interesting; I think I'd go about it differently: > > Since sendmail currently supports using libwrap from Wietse Venema's > tcp_wrappers distribution, this could be used to block non-local > access to sendmail. With remote access to sendmail blocked it can use > a non-standard port and smap/smapd from the TIS firewall toolkit could > be used to talk to strangers. > > (Alternative to libwrap is one of the in-kernel firewalling solutions, > but I don't think these log as well as application level checking, and > must lose at least a little in performance for ordinary traffic.) Going into the experiment I was just trying to transparently move sendmail to a different port, the logging and access control came about from the use of tcp wrappers from inetd. I figured this a plus and decided to add that in. When time permits I am going to work on moving it to a non-root port and sendmail will run soley as user mailer. Another idea, but since I do not know the excacts of sendmail, would be to run a program to bind to port 25. Then start sendmail as user mailer or some other person. I understand this can be done from inetd, but a new sendmail is started each session which is alot of excess overhead even on systems that do not pass much mail. From owner-freebsd-security Mon Jan 6 13:39:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA01095 for security-outgoing; Mon, 6 Jan 1997 13:39:26 -0800 (PST) Received: from cold.org (cold.org [206.81.134.103]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA01037; Mon, 6 Jan 1997 13:39:17 -0800 (PST) Received: from localhost (brandon@localhost) by cold.org (8.8.3/8.8.3) with SMTP id OAA23722; Mon, 6 Jan 1997 14:39:20 -0700 (MST) Date: Mon, 6 Jan 1997 14:39:20 -0700 (MST) From: Brandon Gillespie To: security@freebsd.org, hackers@freebsd.org Subject: FreeBSD as a cleanwall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anybody have a configuration for packet filtering through a FreeBSD router to run a cleanwall? Basically to keep all addresses of a specific IP set (say a class C) on the right sides. I.e. only set addresses of that set leave the network and don't allow any addresses of that set onto the network? I'm mulling through the docs now, but figured to look here for any possible pointers, as this seems like it would be a common enough operation.. -Brandon Gillespie From owner-freebsd-security Mon Jan 6 15:14:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA08900 for security-outgoing; Mon, 6 Jan 1997 15:14:27 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA08895 for ; Mon, 6 Jan 1997 15:14:24 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id PAA19395 for ; Mon, 6 Jan 1997 15:14:46 -0800 (PST) Received: (qmail 23463 invoked by uid 110); 6 Jan 1997 23:12:49 -0000 Message-ID: <19970106231249.23462.qmail@suburbia.net> Subject: Re: FreeBSD as a cleanwall In-Reply-To: from Brandon Gillespie at "Jan 6, 97 02:39:20 pm" To: brandon@cold.org (Brandon Gillespie) Date: Tue, 7 Jan 1997 10:12:49 +1100 (EST) Cc: 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 > Does anybody have a configuration for packet filtering through a FreeBSD > router to run a cleanwall? Basically to keep all addresses of a specific > IP set (say a class C) on the right sides. I.e. only set addresses of > that set leave the network and don't allow any addresses of that set onto > the network? I'm mulling through the docs now, but figured to look here > for any possible pointers, as this seems like it would be a common enough > operation.. > > -Brandon Gillespie > > what you want is something like: # ipfw add pass all from 10.1.2.1 to any in via ed0 # ipfw add pass all from to 10.1.2.1 out via ed0 # ipfw add deny all from 10.1.2.0/24 to any in via ed0 # ipfw add deny all from any to 10.1.2.0/24 any out via ed0 Note that the current ipfw is a little painful, because you can't distinguish packets to be forwarded and packets to be accepted/sent to/from the host. If you are running my ipfw patches, you can (mostly) get avoid this by using: # ipfw add action type from src to dst direction uid any Which will match any packet eminating from or destined to a local socket. I say "mostly", because it is possible the packet is not associated with a socket even though it is addressed to the local host. e.g kernel support for nfs -Julian From owner-freebsd-security Mon Jan 6 15:45:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA10874 for security-outgoing; Mon, 6 Jan 1997 15:45:55 -0800 (PST) Received: from anacreon.sol.net (anacreon.sol.net [206.55.64.116]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA10869; Mon, 6 Jan 1997 15:45:50 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by anacreon.sol.net (8.6.12/8.6.12) with ESMTP id RAA01178; Mon, 6 Jan 1997 17:45:49 -0600 Received: from localhost by solaria.sol.net (8.5/8.5) id RAA02007; Mon, 6 Jan 1997 17:45:46 -0600 From: Joe Greco Message-Id: <199701062345.RAA02007@solaria.sol.net> Subject: Re: FreeBSD as a cleanwall To: brandon@cold.org (Brandon Gillespie) Date: Mon, 6 Jan 97 17:45:44 CST Cc: security@freebsd.org, hackers@freebsd.org In-Reply-To: from "Brandon Gillespie" at Jan 6, 97 02:39:20 pm X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Does anybody have a configuration for packet filtering through a FreeBSD > router to run a cleanwall? Basically to keep all addresses of a specific > IP set (say a class C) on the right sides. I.e. only set addresses of > that set leave the network and don't allow any addresses of that set onto > the network? I'm mulling through the docs now, but figured to look here > for any possible pointers, as this seems like it would be a common enough > operation.. It's called "via" :-) You want something like this. This is designed to run on a gateway router. You have a P2P circuit between you and ISP ("Internet"), and your gateway is on an ethernet. Not that that's required, but just to explain this particular setup. ---- --------- -------------- ISP|<----------->|Gateway|--------|Internal Net| ---- --------- -------------- ^^^ ^^^ ^^^ LINK_IFC GATEWAY_IFC ADDRESS_BLOCK 204.95.219.2 206.55.64.1 206.55.64.0/25 On Gateway, do the following: ipfw f echo "Installing Firewall" # # ----- IP Bad Address Prevention Section ----- # Block RFC1597 "Private Internets" (inbound) ipfw addf deny all from 10.0.0.0/8 to 0/0 via ${LINK_IFC} ipfw addf deny all from 172.16.0.0/12 to 0/0 via ${LINK_IFC} ipfw addf deny all from 192.168.0.0/16 to 0/0 via ${LINK_IFC} # Block other "Shouldn't Exist" Internets (inbound) ipfw addf deny all from 127.0.0.0/8 to 0/0 via ${LINK_IFC} ipfw addf deny all from 0.0.0.0/8 to 0/0 via ${LINK_IFC} # Block RFC1597 "Private Internets" as Source Address (outbound) ipfw addf deny all from 10.0.0.0/8 to 0/0 via ${GATEWAY_IFC} ipfw addf deny all from 172.16.0.0/12 to 0/0 via ${GATEWAY_IFC} ipfw addf deny all from 192.168.0.0/16 to 0/0 via ${GATEWAY_IFC} # Block RFC1597 "Private Internets" as Destination Address (outbound) ipfw addf deny all from 0/0 to 10.0.0.0/8 via ${GATEWAY_IFC} ipfw addf deny all from 0/0 to 172.16.0.0/12 via ${GATEWAY_IFC} ipfw addf deny all from 0/0 to 192.168.0.0/16 via ${GATEWAY_IFC} # Block other "Shouldn't Exist" Internets as Source Address (outbound) ipfw addf deny all from 0/0 to 127.0.0.0/8 via ${GATEWAY_IFC} ipfw addf deny all from 0/0 to 0.0.0.0/8 via ${GATEWAY_IFC} # Block other "Shouldn't Exist" Internets as Destination Address (outbound) ipfw addf deny all from 127.0.0.0/8 to 0/0 via ${GATEWAY_IFC} ipfw addf deny all from 0.0.0.0/8 to 0/0 via ${GATEWAY_IFC} # # ----- IP Spoofing Prevention Section ----- # Block inbound pkts from addresses "on" my net (inbound) # (add as many lines as needed) ipfw addf deny all from ${ADDRESS_BLOCK} to 0/0 via ${LINK_IFC} # # Disallow all Source Addresses (outbound) ipfw addf deny all from 0/0 to 0/0 via ${GATEWAY_IFC} # Only allow outbound pkts from addresses "on" my net (outbound) # (add as many lines as needed) ipfw addf accept all from ${ADDRESS_BLOCK} to 0/0 via ${GATEWAY_IFC} # # Disallow all Destination Addresses (inbound) ipfw addf deny all from 0/0 to 0/0 via ${LINK_IFC} # Only allow inbound pkts to addresses "on" my net (inbound) # (add as many lines as needed) ipfw addf accept all from 0/0 to ${LINK_IFC} via ${LINK_IFC} ipfw addf accept all from 0/0 to ${ADDRESS_BLOCK} via ${LINK_IFC} # This was clearly designed for use on a low speed (SLIP) router, there are lots of optimizations. I wrote it for clarity. I also wrote it under 2.1.0R, so there may be some syntax differences. This will do a pretty thorough job of preventing bogus addresses; it is certainly a good starting point for a "cleanwall" :-) The comments were what I had in the file. If any of it is unclear after inspection, let me know and I will try to clarify. The router itself is mildly trusted to DTRT, by the way, and there are some minor holes. In particular, it is possible for a remote host to send packets with a source address of ${LINK_IFC} which could be fixed by ipfw addf deny all from ${LINK_IFC} to 0/0 via ${LINK_IFC} Some folks will say that this is the long way of doing this. They are right. But it was meant to potentially deal with multiple interfaces... ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-security Mon Jan 6 16:05:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA12809 for security-outgoing; Mon, 6 Jan 1997 16:05:47 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA12804; Mon, 6 Jan 1997 16:05:44 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id QAA01779; Mon, 6 Jan 1997 16:04:47 -0800 (PST) To: proff@suburbia.net cc: hackers@freebsd.org, security@freebsd.org Subject: Re: new firewall code [uid/gid/bind() etc] In-reply-to: Your message of "Tue, 07 Jan 1997 07:01:16 +1100." <19970106200116.16168.qmail@suburbia.net> Date: Mon, 06 Jan 1997 16:04:46 -0800 Message-ID: <1775.852595486@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I tried posting the patches but, at 55k, it seems majordumbo has > (silently) rejected them. You may find them at: Argh! This is not the way to do it - use send-pr(1) please! Jordan From owner-freebsd-security Mon Jan 6 17:49:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA20174 for security-outgoing; Mon, 6 Jan 1997 17:49:29 -0800 (PST) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA20168 for ; Mon, 6 Jan 1997 17:49:23 -0800 (PST) Received: from zen.nash.org (localhost [127.0.0.1]) by zen.nash.org (8.8.4/8.6.12) with SMTP id TAA04045; Mon, 6 Jan 1997 19:47:15 -0600 (CST) Message-ID: <32D1AB23.167EB0E7@mcs.com> Date: Mon, 06 Jan 1997 19:47:15 -0600 From: Alex Nash X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-RELEASE i386) MIME-Version: 1.0 To: Brandon Gillespie CC: security@freebsd.org Subject: Re: FreeBSD as a cleanwall References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [hackers removed] Brandon Gillespie wrote: > > Does anybody have a configuration for packet filtering through a FreeBSD > router to run a cleanwall? Basically to keep all addresses of a specific > IP set (say a class C) on the right sides. I.e. only set addresses of > that set leave the network and don't allow any addresses of that set onto > the network? I'm mulling through the docs now, but figured to look here > for any possible pointers, as this seems like it would be a common enough > operation.. If I understand you correctly, I think what you want is this extract from /etc/rc.firewall: ############ # This is a prototype setup for a simple firewall. Configure this machine # as a named server and ntp server, and point all the machines on the inside # at this machine for those services. ############ # set these to your outside interface network and netmask and ip oif="ed0" onet="192.168.4.0" omask="255.255.255.0" oip="192.168.4.17" # set these to your inside interface network and netmask and ip iif="ed1" inet="192.168.3.0" imask="255.255.255.0" iip="192.168.3.17" # Stop spoofing /sbin/ipfw add deny all from ${inet}:${imask} to any in via ${oif} /sbin/ipfw add deny all from ${onet}:${omask} to any in via ${iif} Alex From owner-freebsd-security Mon Jan 6 21:14:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA28809 for security-outgoing; Mon, 6 Jan 1997 21:14:45 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA28796 for ; Mon, 6 Jan 1997 21:14:41 -0800 (PST) Message-Id: <199701070514.VAA28796@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA138974049; Tue, 7 Jan 1997 16:14:09 +1100 From: Darren Reed Subject: Re: FreeBSD as a cleanwall To: proff@suburbia.net Date: Tue, 7 Jan 1997 16:14:09 +1100 (EDT) Cc: brandon@cold.org, security@freebsd.org In-Reply-To: <19970106231249.23462.qmail@suburbia.net> from "proff@suburbia.net" at Jan 7, 97 10:12:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from proff@suburbia.net, sie said: > > > Does anybody have a configuration for packet filtering through a FreeBSD > > router to run a cleanwall? Basically to keep all addresses of a specific > > IP set (say a class C) on the right sides. I.e. only set addresses of > > that set leave the network and don't allow any addresses of that set onto > > the network? I'm mulling through the docs now, but figured to look here > > for any possible pointers, as this seems like it would be a common enough > > operation.. > > > what you want is something like: > > # ipfw add pass all from 10.1.2.1 to any in via ed0 > # ipfw add pass all from to 10.1.2.1 out via ed0 > # ipfw add deny all from 10.1.2.0/24 to any in via ed0 > # ipfw add deny all from any to 10.1.2.0/24 any out via ed0 > > Note that the current ipfw is a little painful, because you can't > distinguish packets to be forwarded and packets to be accepted/sent > to/from the host. Which if used are probably going to be more complex (more rules) and less comprehensive (unless you include all of the above). You should be protecting the host as well as the network from the host. > If you are running my ipfw patches, you can (mostly) get avoid this > by using: ... Jullian, you really should seaparate this functionality out of ipfw. For the most part, it has no relevance to the orgiinal context of ipfw. Maybe you should write ipfws (IP firewall sockets) or similar ? (Makes good sense to me ... :-) Darren From owner-freebsd-security Tue Jan 7 14:12:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA14769 for security-outgoing; Tue, 7 Jan 1997 14:12:54 -0800 (PST) Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA14763 for ; Tue, 7 Jan 1997 14:12:48 -0800 (PST) Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.8.2/8.6.4) with ESMTP id AAA16490; Wed, 8 Jan 1997 00:10:34 +0200 (EET) Received: (hsu@localhost) by katiska.clinet.fi (8.8.4/8.6.4) id AAA13560; Wed, 8 Jan 1997 00:10:32 +0200 (EET) Date: Wed, 8 Jan 1997 00:10:32 +0200 (EET) Message-Id: <199701072210.AAA13560@katiska.clinet.fi> From: Heikki Suonsivu To: Darren Reed Cc: proff@suburbia.net, brandon@cold.org, security@FreeBSD.ORG Subject: Re: FreeBSD as a cleanwall In-Reply-To: <199701070514.VAA28796@freefall.freebsd.org> References: <19970106231249.23462.qmail@suburbia.net> <199701070514.VAA28796@freefall.freebsd.org> Organization: Clinet Ltd, Espoo, Finland Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Darren Reed writes: ... > Jullian, you really should seaparate this functionality out of ipfw. > > For the most part, it has no relevance to the orgiinal context of ipfw. > Maybe you should write ipfws (IP firewall sockets) or similar ? (Makes > good sense to me ... :-) Before ipfw cooks coffee, maybe it might be worthwhile to look at combining functionality of bpf and ipfw, instead of duplicating everything possible with bpf into ipfw and vice versa. In general it would be better to have one interface for matching packets which could then be used for anything (not just firewalling, but bandwidth management, snooping data like bpf now does, accounting, etc). I assume this would reduce amount of code in kernel as ipfw matching code could be replaced with calls to bpf? Is there anything which ipfw does but bpf does not, other than better performance ? How much more bpf consumes cpu than ipfw, per packet filtered, per rule ? > Darren -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi mobile +358-40-5519679 work +358-9-43542270 fax -4555276 From owner-freebsd-security Tue Jan 7 15:04:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA18865 for security-outgoing; Tue, 7 Jan 1997 15:04:53 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA18847 for ; Tue, 7 Jan 1997 15:04:47 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id PAA10754 for ; Tue, 7 Jan 1997 15:05:34 -0800 (PST) Received: (qmail 6677 invoked by uid 110); 7 Jan 1997 23:04:06 -0000 Message-ID: <19970107230406.6676.qmail@suburbia.net> Subject: Re: FreeBSD as a cleanwall In-Reply-To: <199701072210.AAA13560@katiska.clinet.fi> from Heikki Suonsivu at "Jan 8, 97 00:10:32 am" To: hsu@clinet.fi (Heikki Suonsivu) Date: Wed, 8 Jan 1997 10:04:06 +1100 (EST) Cc: hackers@freebsd.org, 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 > Is there anything which ipfw does but bpf does not, other than better > performance ? > > How much more bpf consumes cpu than ipfw, per packet filtered, per rule ? > > -- > Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi > mobile +358-40-5519679 work +358-9-43542270 fax -4555276 > The two are not really compariable. If I was going to write a packet filtering system from scratch, I'd take most of Darren's code and add: query optimisation and grammer from libpcap fast masking from RMON my socket credential code Bpf primarily exists to cut down kernel<->user space talk, and I don't think it is useful elsewhere, except as a slow portable low-level substrate. Some RMON (one?) system(s) have support for bpf code, but except for ip/tcp options and quantitative decisions, fast masks work very well. Cheers, Julian From owner-freebsd-security Tue Jan 7 19:03:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA08430 for security-outgoing; Tue, 7 Jan 1997 19:03:47 -0800 (PST) Received: from fools.ecpnet.com (moke@fools.ecpnet.com [204.246.64.101]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA08418 for ; Tue, 7 Jan 1997 19:03:39 -0800 (PST) Received: from localhost (moke@localhost) by fools.ecpnet.com (8.8.4/8.8.4) with SMTP id VAA01095 for ; Tue, 7 Jan 1997 21:01:32 -0600 (CST) Date: Tue, 7 Jan 1997 21:01:32 -0600 (CST) From: Jimbo Bahooli To: freebsd-security@freebsd.org Subject: sendmail running non-root SUCCESS! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well here goes how I have sendmail running flawlessly as user daemon. It requires netcat (/usr/ports/net/netcat). 1. Setup a group called mailer in /etc/group. 2. chown root.mailer /var/spool/mqueue. 3. chmod 775 /var/spool/mqueue. 4. chown daemon.mailer /usr/sbin/sendmail. 5. chmod 6555 /usr/sbin/sendmail. 6. edit /etc/sendmail.cf to bind to a port above the 1024 line. example: O DaemonPortOptions=Port=2025 7. edit /etc/inetd.conf to redirect to port 2025 using netcat. example: w/ tcpd smtp stream tcp nowait nobody /usr/libexec/tcpd /usr/local/bin/recvmail -w 3 127.0.0.1 2025 w/o smtp stream tcp nowait nobody /usr/local/bin/recvmail /usr/local/bin/recvmail -w 3 127.0.0.1 2025 *(lines above have probably been wrapped, should be on one line) **(recvmail is symlink to /usr/local/bin/nc, makes logging via tcpd clearer) Other notes, i believe all .forward and related files need to be readable by the user daemon. I also recommend using tcp_wrappers for logging because in /var/log/maillog the relay will show up as localhost because of the redirection. Any comments? -moke@fools.ecpnet.com From owner-freebsd-security Tue Jan 7 19:18:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA09143 for security-outgoing; Tue, 7 Jan 1997 19:18:12 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA09127; Tue, 7 Jan 1997 19:18:07 -0800 (PST) Message-Id: <199701080318.TAA09127@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA024833424; Wed, 8 Jan 1997 14:17:04 +1100 From: Darren Reed Subject: Re: FreeBSD as a cleanwall To: proff@suburbia.net Date: Wed, 8 Jan 1997 14:17:04 +1100 (EDT) Cc: hsu@clinet.fi, hackers@FreeBSD.org, security@FreeBSD.org In-Reply-To: <19970107230406.6676.qmail@suburbia.net> from "proff@suburbia.net" at Jan 8, 97 10:04:06 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In some mail from proff@suburbia.net, sie said: [..] > fast masking from RMON > my socket credential code > > Bpf primarily exists to cut down kernel<->user space talk, and I > don't think it is useful elsewhere, except as a slow portable > low-level substrate. Some RMON (one?) system(s) have support for > bpf code, but except for ip/tcp options and quantitative decisions, > fast masks work very well. What's "fast masking" ? Darren From owner-freebsd-security Tue Jan 7 19:29:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA09604 for security-outgoing; Tue, 7 Jan 1997 19:29:22 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA09596 for ; Tue, 7 Jan 1997 19:29:19 -0800 (PST) Message-Id: <199701080329.TAA09596@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA027814097; Wed, 8 Jan 1997 14:28:17 +1100 From: Darren Reed Subject: Re: FreeBSD as a cleanwall To: hsu@clinet.fi (Heikki Suonsivu) Date: Wed, 8 Jan 1997 14:28:17 +1100 (EDT) Cc: avalon@coombs.anu.edu.au, proff@suburbia.net, brandon@cold.org, security@FreeBSD.ORG In-Reply-To: <199701072210.AAA13560@katiska.clinet.fi> from "Heikki Suonsivu" at Jan 8, 97 00:10:32 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Heikki Suonsivu, sie said: > > Before ipfw cooks coffee, maybe it might be worthwhile to look at combining > functionality of bpf and ipfw, instead of duplicating everything possible > with bpf into ipfw and vice versa. In general it would be better to have > one interface for matching packets which could then be used for anything > (not just firewalling, but bandwidth management, snooping data like bpf now > does, accounting, etc). I assume this would reduce amount of code in > kernel as ipfw matching code could be replaced with calls to bpf? > > Is there anything which ipfw does but bpf does not, other than better > performance ? > > How much more bpf consumes cpu than ipfw, per packet filtered, per rule ? I've looked at doing this in the past and some time in the future, want to make using BPF an option with IP Filter. What BPF provides is the means to create complex filters (and that's about it) in the kernel - primarily for performance boosts with things like tcpdump. BPF is slightly more expensive (performace wise), but better in terms of flexibility. (There have been rumours about a BPF which compiles to machine code, rather than BPF object code, which would negate that arguement but they seem to be still rumours). Things like ipfw/IP Filter deal with not just the packet matching, but dealing with the results of matches, etc. From owner-freebsd-security Tue Jan 7 19:31:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA09752 for security-outgoing; Tue, 7 Jan 1997 19:31:06 -0800 (PST) Received: from whorfin.sjca.edu (vo0amsCArqFn6BPjlHx4n3ZVdQtI3+Wk@whorfin.sjca.edu [199.89.180.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA09739 for ; Tue, 7 Jan 1997 19:31:03 -0800 (PST) Received: from continuity.sjca.edu (slip-f.sjca.edu [199.89.180.254]) by whorfin.sjca.edu (8.8.3/8.8.3) with ESMTP id WAA29294 for ; Tue, 7 Jan 1997 22:30:59 -0500 (EST) From: Matt Braithwaite Received: (mab@localhost) by continuity.sjca.edu (8.7.5/8.6.12) id WAA02781; Tue, 7 Jan 1997 22:31:17 -0500 (EST) Date: Tue, 7 Jan 1997 22:31:17 -0500 (EST) Message-Id: <199701080331.WAA02781@continuity.sjca.edu> Reply-To: m-braithwaite@sjca.edu X-Organization: The Ancient Illuminated Seers of Bavaria X-Url: my homepage To: freebsd-security@freebsd.org Subject: Obvious fix for tempfile race conditions? Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- This seems pretty obvious to me, so maybe I have something wrong, but: As I understand it, there is a class of security holes that derives from the ability of a random user to create a symlink in /tmp to some file, such that a root or SUID root program will follow the link and either damage or in some cases alter the file to produce a security hole. If I've got that much of it right, why not simply add a mount option to disable symlinks on a given filesystem? (Not saying the implementation is simple, just the idea. :-) ) /tmp is normally its own filesystem, so this doesn't seem to have any major disadvantages. And it doesn't require all those programs out there that do sloppy things with temp files to be rewritten. Of course there might be programs that depend on the ability to make symlinks in /tmp, but I've sure never seen any. Maybe for these programs there could be something like HTTPd's SymLinksIfOwnerMatch option... Any comments? - -- Matt Braithwaite #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL http:// $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa www.sjca.edu/ 2/d0 Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA21339 for security-outgoing; Wed, 8 Jan 1997 00:40:47 -0800 (PST) Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA21334 for ; Wed, 8 Jan 1997 00:40:45 -0800 (PST) Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id JAA15332; Wed, 8 Jan 1997 09:39:24 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma015243; Wed Jan 8 09:38:47 1997 Received: from bsd.lss.cp.philips.com (bsd.lss.cp.philips.com [130.144.199.33]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-961216) with SMTP id JAA06314; Wed, 8 Jan 1997 09:38:46 +0100 Received: by bsd.lss.cp.philips.com (8.8.3/1.63) id JAA06611; Wed, 8 Jan 1997 09:38:45 +0100 (MET) From: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) Message-Id: <199701080838.JAA06611@bsd.lss.cp.philips.com> Subject: Re: sendmail running non-root SUCCESS! To: moke@fools.ecpnet.com (Jimbo Bahooli) Date: Wed, 8 Jan 1997 09:38:45 +0100 (MET) Cc: freebsd-security@freebsd.org In-Reply-To: from Jimbo Bahooli at "Jan 7, 97 09:01:32 pm" X-Mailer: ELM [version 2.4ME+ PL22 (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 > Other notes, i believe all .forward and related files need to be readable > by the user daemon. I also recommend using tcp_wrappers for logging > because in /var/log/maillog the relay will show up as localhost because of > the redirection. > > Any comments? Yes. A program in a .forward will need to be executed under uid user. How is sendmail going to do that if it is not suid root? -Guido From owner-freebsd-security Wed Jan 8 01:50:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA23957 for security-outgoing; Wed, 8 Jan 1997 01:50:08 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA23949 for ; Wed, 8 Jan 1997 01:50:06 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id BAA20064 for ; Wed, 8 Jan 1997 01:50:58 -0800 (PST) Received: (qmail 383 invoked by uid 110); 8 Jan 1997 09:49:42 -0000 Message-ID: <19970108094942.382.qmail@suburbia.net> Subject: Re: sendmail running non-root SUCCESS! In-Reply-To: <199701080838.JAA06611@bsd.lss.cp.philips.com> from Guido van Rooij at "Jan 8, 97 09:38:45 am" To: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) Date: Wed, 8 Jan 1997 20:49:42 +1100 (EST) Cc: 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 > > Other notes, i believe all .forward and related files need to be readable > > by the user daemon. I also recommend using tcp_wrappers for logging > > because in /var/log/maillog the relay will show up as localhost because of > > the redirection. > > > > Any comments? > > Yes. A program in a .forward will need to be executed under uid user. How > is sendmail going to do that if it is not suid root? > > -Guido > qmail qmail qmail http://www.qmail.org -Julian From owner-freebsd-security Wed Jan 8 03:27:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA28500 for security-outgoing; Wed, 8 Jan 1997 03:27:00 -0800 (PST) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA28486 for ; Wed, 8 Jan 1997 03:26:50 -0800 (PST) Received: from sidhe.hsc.fr (pb@sidhe.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.4/8.8.4/itesec-1.9) with ESMTP id MAA07881; Wed, 8 Jan 1997 12:26:07 +0100 (MET) Received: (from pb@localhost) by sidhe.hsc.fr (8.8.Alpha.4/sidhe-new-1.7) id MAA01278; Wed, 8 Jan 1997 12:26:07 +0100 (MET) Message-ID: Date: Wed, 8 Jan 1997 12:26:06 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: proff@suburbia.net Cc: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij), security@FreeBSD.ORG Subject: Re: sendmail running non-root SUCCESS! References: <199701080838.JAA06611@bsd.lss.cp.philips.com> <19970108094942.382.qmail@suburbia.net> X-Mailer: Mutt 0.50 Mime-Version: 1.0 In-Reply-To: <19970108094942.382.qmail@suburbia.net>; from proff@suburbia.net on Jan 8, 1997 20:49:42 +1100 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to proff@suburbia.net: > > Yes. A program in a .forward will need to be executed under uid user. How > > is sendmail going to do that if it is not suid root? > > > qmail qmail qmail suboptimal uucp handling, suboptimal uucp handling, suboptimal uucp handling. Please please please, could we avoid a "qmail vs sendmail" flame war this time? This is a waste of time, plain and simple. -- Pierre.Beyssac@hsc.fr From owner-freebsd-security Wed Jan 8 13:14:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA29728 for security-outgoing; Wed, 8 Jan 1997 13:14:57 -0800 (PST) Received: from service.esys.ca (root@service.esys.ca [141.118.1.124]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA29721 for ; Wed, 8 Jan 1997 13:14:53 -0800 (PST) Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0vi5NK-000UljC; Wed, 8 Jan 97 14:17 MST Received: from cezanne.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0vi5P8-000RWwC; Wed, 8 Jan 97 14:19 MST From: Lyndon Nerenberg To: Jimbo Bahooli cc: freebsd-security@freebsd.org Subject: Re: sendmail running non-root SUCCESS! In-Reply-To: Message-ID: Date: Wed, 8 Jan 1997 14:19:21 -0700 (MST) Priority: NORMAL X-Mailer: Simeon for Hpux Motif Version 4.1 X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 7 Jan 1997 21:01:32 -0600 (CST) Jimbo Bahooli wrote: > Other notes, i believe all .forward and related files need to be readable > by the user daemon. I also recommend using tcp_wrappers for logging > because in /var/log/maillog the relay will show up as localhost because of > the redirection. > > Any comments? If one were to deprecate ~/.forward in favour of /var/db/forward/$USER, and write a forward(1) command to allow user manipulation of the files in the new location then the above restriction would go away. (Use the crontab(1) command as a model.) --lyndon Disco music makes it possible to have disco entertainment centers. Disco entertainment centers make it possible for mellow, laid-back, boring kinds of people to meet each other and reproduce. --Frank Zappa From owner-freebsd-security Thu Jan 9 01:05:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA16930 for security-outgoing; Thu, 9 Jan 1997 01:05:27 -0800 (PST) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA16924 for ; Thu, 9 Jan 1997 01:05:21 -0800 (PST) Received: (from uucp@localhost) by perki0.connect.com.au id UAA10407 (8.7.6h/IDA-1.6); Thu, 9 Jan 1997 20:01:24 +1100 (EST) >Received: from localhost.nemeton.com.au (localhost.nemeton.com.au [127.0.0.1]) by nemeton.com.au (8.8.4/8.8.4) with SMTP id TAA01064; Thu, 9 Jan 1997 19:44:18 +1100 (EST) Message-Id: <199701090844.TAA01064@nemeton.com.au> To: Lyndon Nerenberg cc: Jimbo Bahooli , freebsd-security@freebsd.org Subject: Re: sendmail running non-root SUCCESS! In-reply-to: Date: Thu, 09 Jan 1997 19:44:18 +1100 From: Giles Lean Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 8 Jan 1997 14:19:21 -0700 (MST) Lyndon Nerenberg wrote: > If one were to deprecate ~/.forward in favour of /var/db/forward/$USER, > and write a forward(1) command to allow user manipulation of the > files Unfortunately, wrong. The .forward files contain references to programs that have to be run as the user, not as daemon or sendmail or any other user. Mailing to programs is evil, but it is how you get things like procmail and vacation to work. Giles From owner-freebsd-security Thu Jan 9 02:46:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id CAA22156 for security-outgoing; Thu, 9 Jan 1997 02:46:09 -0800 (PST) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA22150 for ; Thu, 9 Jan 1997 02:46:03 -0800 (PST) Received: from sidhe.hsc.fr (pb@sidhe.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.4/8.8.4/itesec-1.9) with ESMTP id LAA03748; Thu, 9 Jan 1997 11:44:25 +0100 (MET) Received: (from pb@localhost) by sidhe.hsc.fr (8.8.Alpha.4/sidhe-new-1.7) id LAA04937; Thu, 9 Jan 1997 11:44:25 +0100 (MET) Message-ID: Date: Thu, 9 Jan 1997 11:44:24 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: giles@nemeton.com.au (Giles Lean) Cc: lyndon@esys.ca (Lyndon Nerenberg), moke@fools.ecpnet.com (Jimbo Bahooli), freebsd-security@FreeBSD.ORG Subject: Re: sendmail running non-root SUCCESS! References: <199701090844.TAA01064@nemeton.com.au> X-Mailer: Mutt 0.50 Mime-Version: 1.0 In-Reply-To: <199701090844.TAA01064@nemeton.com.au>; from Giles Lean on Jan 9, 1997 19:44:18 +1100 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Giles Lean: > Unfortunately, wrong. The .forward files contain references to > programs that have to be run as the user, not as daemon or sendmail or > any other user. > > Mailing to programs is evil, but it is how you get things like > procmail and vacation to work. Yes, but it's one of the reasons why sendmail needs to be setuid. IMHO, it might be a good idea to develop an external "prog" mailer. It would handle all the setuid stuff required for mailing to programs. Regarding the .forward stuff, I'm not sure sendmail really needs to be setuid to handle that. -- Pierre.Beyssac@hsc.fr From owner-freebsd-security Thu Jan 9 05:53:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA00143 for security-outgoing; Thu, 9 Jan 1997 05:53:41 -0800 (PST) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id FAA00138 for ; Thu, 9 Jan 1997 05:53:37 -0800 (PST) Received: (adam@localhost) by homeport.org (8.6.9/8.6.9) id IAA23487; Thu, 9 Jan 1997 08:47:03 -0500 From: Adam Shostack Message-Id: <199701091347.IAA23487@homeport.org> Subject: Re: sendmail running non-root SUCCESS! In-Reply-To: from Pierre Beyssac at "Jan 9, 97 11:44:24 am" To: Pierre.Beyssac@hsc.fr (Pierre Beyssac) Date: Thu, 9 Jan 1997 08:47:03 -0500 (EST) Cc: giles@nemeton.com.au, lyndon@esys.ca, moke@fools.ecpnet.com, freebsd-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 Pierre Beyssac wrote: | According to Giles Lean: | > Unfortunately, wrong. The .forward files contain references to | > programs that have to be run as the user, not as daemon or sendmail or | > any other user. | > | > Mailing to programs is evil, but it is how you get things like | > procmail and vacation to work. | | Yes, but it's one of the reasons why sendmail needs to be setuid. | | IMHO, it might be a good idea to develop an external "prog" mailer. | It would handle all the setuid stuff required for mailing to programs. | | Regarding the .forward stuff, I'm not sure sendmail really needs to be | setuid to handle that. You mean something like procmail which can be setuid and does mail delivery? Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume From owner-freebsd-security Thu Jan 9 06:36:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA01824 for security-outgoing; Thu, 9 Jan 1997 06:36:52 -0800 (PST) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA01815 for ; Thu, 9 Jan 1997 06:36:46 -0800 (PST) Received: from sidhe.hsc.fr (pb@sidhe.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.4/8.8.4/itesec-1.9) with ESMTP id PAA07752; Thu, 9 Jan 1997 15:35:14 +0100 (MET) Received: (from pb@localhost) by sidhe.hsc.fr (8.8.Alpha.4/sidhe-new-1.7) id PAA06011; Thu, 9 Jan 1997 15:35:13 +0100 (MET) Message-ID: Date: Thu, 9 Jan 1997 15:35:12 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: adam@homeport.org (Adam Shostack) Cc: Pierre.Beyssac@hsc.fr (Pierre Beyssac), giles@nemeton.com.au, lyndon@esys.ca, moke@fools.ecpnet.com, freebsd-security@FreeBSD.ORG Subject: Re: sendmail running non-root SUCCESS! References: <199701091347.IAA23487@homeport.org> X-Mailer: Mutt 0.50 Mime-Version: 1.0 In-Reply-To: <199701091347.IAA23487@homeport.org>; from Adam Shostack on Jan 9, 1997 08:47:03 -0500 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Adam Shostack: > Pierre Beyssac wrote: > | IMHO, it might be a good idea to develop an external "prog" mailer. > | It would handle all the setuid stuff required for mailing to programs. > | > | Regarding the .forward stuff, I'm not sure sendmail really needs to be > | setuid to handle that. > > You mean something like procmail which can be setuid and does mail > delivery? Not exactly (though I don't know procmail well enough: maybe it can do that too). Rather, something sendmail would call by giving it a program name and a user id to run it as. For example, supposing a ~user/.forward is \user, "| /home/user/bin/myownstuff" sendmail could process the .forward as usual, but it would call the external prog mailer to ask it to run "/home/user/bin/myownstuff" as "user" and pipe the mail to it. Obviously it has to be more complicated than that or it would be a trivial new hole in the system (we can't rely on just checking that sendmail is calling us, that would not make us immune to attacks on sendmail itself). A solution might be to use a .db database as someone suggested, as an authenticated reference owned by root or mail, accessed by sendmail and the prog mailer. A similar idea is configurable permissions for the prog mailer, in this case sendmail doesn't need to know of care about these, it just gets an error if it tries to ask unauthorized things. I don't know how easy it would be to make this secure, it's just an idea. My feeling is that it should be possible to define something more modular than sendmail, with only very few parts setuid inside. -- Pierre.Beyssac@hsc.fr From owner-freebsd-security Thu Jan 9 07:35:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA04681 for security-outgoing; Thu, 9 Jan 1997 07:35:29 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA04667 for ; Thu, 9 Jan 1997 07:35:24 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.3/8.8.3) with UUCP id QAA25341; Thu, 9 Jan 1997 16:34:01 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id QAA01875; Thu, 9 Jan 1997 16:35:13 +0100 (MET) Message-Id: <3.0.32.19970109163513.009da930@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 09 Jan 1997 16:35:14 +0100 To: Pierre.Beyssac@hsc.fr (Pierre Beyssac) From: Eivind Eklund Subject: Re: sendmail running non-root SUCCESS! Cc: security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 03:35 PM 1/9/97 +0100, Pierre Beyssac wrote: >Rather, something sendmail would call by giving it a program name >and a user id to run it as. > >For example, supposing a ~user/.forward is > >\user, "| /home/user/bin/myownstuff" > >sendmail could process the .forward as usual, but it would >call the external prog mailer to ask it to run "/home/user/bin/myownstuff" >as "user" and pipe the mail to it. > >Obviously it has to be more complicated than that or it would >be a trivial new hole in the system (we can't rely on just checking >that sendmail is calling us, that would not make us immune to attacks >on sendmail itself). There is a trivial solution. Just make 'progmail' parse .forward too (could be compiled from the same source), and just take a user-id (and mail on stdin). No holes that I can see. Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/ From owner-freebsd-security Thu Jan 9 09:27:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA11319 for security-outgoing; Thu, 9 Jan 1997 09:27:35 -0800 (PST) Received: from service.esys.ca (root@service.esys.ca [141.118.1.124]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA11314 for ; Thu, 9 Jan 1997 09:27:33 -0800 (PST) Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0viOI0-000UoQC; Thu, 9 Jan 97 10:29 MST Received: from cezanne.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0viOJq-000RWwC; Thu, 9 Jan 97 10:31 MST From: Lyndon Nerenberg To: Giles Lean cc: Jimbo Bahooli , freebsd-security@freebsd.org Subject: Re: sendmail running non-root SUCCESS! In-Reply-To: <199701090844.TAA01064@nemeton.com.au> Message-ID: Date: Thu, 9 Jan 1997 10:31:09 -0700 (MST) Priority: NORMAL X-Mailer: Simeon for Hpux Motif Version 4.1 X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 09 Jan 1997 19:44:18 +1100 Giles Lean wrote: > > On Wed, 8 Jan 1997 14:19:21 -0700 (MST) Lyndon Nerenberg wrote: > > > If one were to deprecate ~/.forward in favour of /var/db/forward/$USER, > > and write a forward(1) command to allow user manipulation of the > > files > > Unfortunately, wrong. The .forward files contain references to > programs that have to be run as the user, not as daemon or sendmail or > any other user. Which can be handled by having "program" alias messages (should the site choose to allow them) dumped into a seperate queue that is run by a root process whose sole purpose is to execute programs on the users behalf. This is the only part of the traditional sendmail chain that *requires* it (sendmail) to run as root. Splitting that functionality out into a seperate, tiny, single-purpose program makes a lot more sense from a security perspective. --lyndon From owner-freebsd-security Thu Jan 9 11:07:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA15966 for security-outgoing; Thu, 9 Jan 1997 11:07:54 -0800 (PST) Received: from spitfire.ecsel.psu.edu (qmailr@spitfire.ecsel.psu.edu [146.186.218.51]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA15961 for ; Thu, 9 Jan 1997 11:07:51 -0800 (PST) Received: (qmail 12308 invoked by uid 1000); 9 Jan 1997 19:08:47 -0000 Message-ID: <19970109190847.12307.qmail@spitfire.ecsel.psu.edu> To: Lyndon Nerenberg cc: Jimbo Bahooli , freebsd-security@FreeBSD.ORG Subject: Re: sendmail running non-root SUCCESS! In-reply-to: Your message of "Thu, 09 Jan 1997 10:31:09 MST." Date: Thu, 09 Jan 1997 14:08:47 -0500 From: Dan Cross Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Which can be handled by having "program" alias messages (should the > site choose to allow them) dumped into a seperate queue that is run by > a root process whose sole purpose is to execute programs on the users > behalf. This is the only part of the traditional sendmail chain that > *requires* it (sendmail) to run as root. Splitting that functionality > out into a seperate, tiny, single-purpose program makes a lot more > sense from a security perspective. Which is what qmail already does. (Along with many other things that sendmail doesn't do, or doesn't do as well). Perhaps I'm being naive here, but what's the pressure to stick with sendmail? Why not move to a more reliable and efficient MTA, like Qmail? - Dan C. From owner-freebsd-security Thu Jan 9 11:19:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA16698 for security-outgoing; Thu, 9 Jan 1997 11:19:42 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA16675 for ; Thu, 9 Jan 1997 11:19:36 -0800 (PST) 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 UAA07892 for ; Thu, 9 Jan 1997 20:19:29 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id UAA13529 for freebsd-security@FreeBSD.ORG; Thu, 9 Jan 1997 20:19:20 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id UAA23761; Thu, 9 Jan 1997 20:04:12 +0100 (CET) Message-ID: Date: Thu, 9 Jan 1997 20:04:12 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-security@freebsd.org Subject: Re: sendmail running non-root SUCCESS! References: <199701091347.IAA23487@homeport.org> X-Mailer: Mutt 0.55.15 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2837 In-Reply-To: ; from Pierre Beyssac on Jan 9, 1997 15:35:12 +0100 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Pierre Beyssac: > Not exactly (though I don't know procmail well enough: maybe it > can do that too). Look on your own machine Pierre, that's the way I set it up when it was mine :-) The way to do it is to use FEATURE(local_procmail). > sendmail could process the .forward as usual, but it would > call the external prog mailer to ask it to run "/home/user/bin/myownstuff" > as "user" and pipe the mail to it. It is very easy to implement (winthin sendmail). Now, where is the patch for the run-as-user program ? :-) > I don't know how easy it would be to make this secure, it's just an > idea. My feeling is that it should be possible to define something > more modular than sendmail, with only very few parts setuid inside. That's Qmail for you. Qmail would have been fine for most use in place of sendmail if it supported some more sendmail-compatible features like DSN, ESMTP, proper UUCP support and a simplier configuration system (I don't like the .qmail-foo-bar system). Even making the one mail/one recipient feature optional would be nice but Bernstein is too stubborn. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #33: Sat Dec 21 12:57:17 CET 1996 From owner-freebsd-security Thu Jan 9 15:19:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA27450 for security-outgoing; Thu, 9 Jan 1997 15:19:25 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA27441 for ; Thu, 9 Jan 1997 15:19:20 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id JAA28530; Fri, 10 Jan 1997 09:48:41 +1030 (CST) From: Michael Smith Message-Id: <199701092318.JAA28530@genesis.atrad.adelaide.edu.au> Subject: Re: sendmail running non-root SUCCESS In-Reply-To: <19970109190847.12307.qmail@spitfire.ecsel.psu.edu> from Dan Cross at "Jan 9, 97 02:08:47 pm" To: tenser@spitfire.ecsel.psu.edu (Dan Cross) Date: Fri, 10 Jan 1997 09:48:39 +1030 (CST) Cc: lyndon@esys.ca, moke@fools.ecpnet.com, freebsd-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 Dan Cross stands accused of saying: > > Perhaps I'm being naive here, but what's the pressure to stick with > sendmail? Why not move to a more reliable and efficient MTA, like > Qmail? Please don't drag this one out _again_. Go off and read the -security mail archive if you want the text of the discussion. BTW, Peter, where's that handbook entry you were going to write on Qmail? > - Dan C. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Thu Jan 9 17:06:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA03962 for security-outgoing; Thu, 9 Jan 1997 17:06:32 -0800 (PST) Received: from selkirk.csrv.nidc.edu (selkirk.csrv.nidc.edu [192.133.128.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA03954 for ; Thu, 9 Jan 1997 17:06:27 -0800 (PST) Received: by selkirk.csrv.nidc.edu (1.38.193.5/16.2) id AA20470; Thu, 9 Jan 1997 17:07:21 -0800 Date: Thu, 9 Jan 1997 17:07:21 -0800 (PST) From: Mark Nottage To: security@freefall.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 unsubscribe markn@selkirk.csrv.nidc.edu security-digest From owner-freebsd-security Thu Jan 9 17:58:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA06027 for security-outgoing; Thu, 9 Jan 1997 17:58:03 -0800 (PST) Received: from cwsys.cwent.com (0@cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA06020 for ; Thu, 9 Jan 1997 17:57:57 -0800 (PST) Received: (from smap@localhost) by cwsys.cwent.com (8.8.4/8.6.10) id RAA00592; Thu, 9 Jan 1997 17:57:53 -0800 (PST) Message-Id: <199701100157.RAA00592@cwsys.cwent.com> X-Authentication-Warning: cwsys.cwent.com: smap set sender to using -f Received: from localhost(127.0.0.1) by cwsys.cwent.com via smap (V1.3) id sma000589; Thu Jan 9 17:57:52 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: Xmh To: freebsd-security@freebsd.org cc: cschuber@uumail.gov.bc.ca Subject: Re: sendmail running non-root SUCCESS! Date: Thu, 09 Jan 1997 17:57:52 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After the announcement of the latest Sendmail exposure earlier today, I've tested this out and it is quite doable, though my approach was a little different. Instead of having netcat listen to port 25 I used a copy of smap from the old TIS FWTK (prior to the current licensing restrictions). Sendmail's permissions were set to 4510 with ownersip of root/sendmail. /usr/bin/mail's permissions became setgid sendmail. The results are that noone can connect to port 25 and talk directly to sendmail. Local users cannot directly execute sendmail. Only specified MUA's can execute sendmail. I see two exposures with this approach. First is that if someone manages to break an MUA with setgid sendmail permissions and get a setgid sendmail shell, one can use that to attempt an attack against sendmail itself. Though not perfect, any hacker would need to jump through one additional hoop prior to gaining root. The second exposure is that smap chroots to /var/spool/smap. A hacker could break smap and place a setuid-root shell in that directory, then login using a local account and use the just-created setuid-root shell. Alternatively one could use Qmail, however, I haven't managed to get it to work with MH's slocal command. As far as I'm concerned that's a severe restriction. Any thoughts? Regards, Phone: (250)387-8437 Cy Schubert OV/VM: BCSC02(CSCHUBER) UNIX Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Thu Jan 9 18:02:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA06246 for security-outgoing; Thu, 9 Jan 1997 18:02:37 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA06237 for ; Thu, 9 Jan 1997 18:02:33 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id SAA28004 for ; Thu, 9 Jan 1997 18:03:12 -0800 (PST) Received: (qmail 27034 invoked by uid 110); 10 Jan 1997 02:01:53 -0000 Message-ID: <19970110020153.27033.qmail@suburbia.net> Subject: Re: sendmail running non-root SUCCESS! In-Reply-To: from Pierre Beyssac at "Jan 9, 97 03:35:12 pm" To: Pierre.Beyssac@hsc.fr (Pierre Beyssac) Date: Fri, 10 Jan 1997 13:01:53 +1100 (EST) Cc: adam@homeport.org, Pierre.Beyssac@hsc.fr, giles@nemeton.com.au, lyndon@esys.ca, moke@fools.ecpnet.com, freebsd-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 > sendmail could process the .forward as usual, but it would > call the external prog mailer to ask it to run "/home/user/bin/myownstuff" > as "user" and pipe the mail to it. > > Obviously it has to be more complicated than that or it would > be a trivial new hole in the system (we can't rely on just checking > that sendmail is calling us, that would not make us immune to attacks > on sendmail itself). > > A solution might be to use a .db database as someone suggested, > as an authenticated reference owned by root or mail, accessed > by sendmail and the prog mailer. > > -- > Pierre.Beyssac@hsc.fr > Bork. Instead of spending hours whipping and splinting a dying nag into going an extra furlong, why not just put a little more shine on the young filly called 'qmail'? I'm serious. If qmail doesn't handle what you want (optimal-uucp-handling) then extend it. Because of qmail's well-thought-out modularity and multiple division of powers, this task is not hard and has virtually zero chance of introducing security holes. Cheers, Julian. From owner-freebsd-security Thu Jan 9 18:26:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA07654 for security-outgoing; Thu, 9 Jan 1997 18:26:45 -0800 (PST) Received: from spitfire.ecsel.psu.edu (qmailr@spitfire.ecsel.psu.edu [146.186.218.51]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id SAA07648 for ; Thu, 9 Jan 1997 18:26:41 -0800 (PST) Received: (qmail 13642 invoked by uid 1000); 10 Jan 1997 02:27:50 -0000 Message-ID: <19970110022750.13641.qmail@spitfire.ecsel.psu.edu> To: Michael Smith cc: lyndon@esys.ca, moke@fools.ecpnet.com, freebsd-security@freebsd.org Subject: Re: sendmail running non-root SUCCESS In-reply-to: Your message of "Fri, 10 Jan 1997 09:48:39 +1030." <199701092318.JAA28530@genesis.atrad.adelaide.edu.au> Date: Thu, 09 Jan 1997 21:27:49 -0500 From: Dan Cross Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Perhaps I'm being naive here, but what's the pressure to stick with > > sendmail? Why not move to a more reliable and efficient MTA, like > > Qmail? > > Please don't drag this one out _again_. Go off and read the -security > mail archive if you want the text of the discussion. > > BTW, Peter, where's that handbook entry you were going to write on > Qmail? I did, and unless I didn't search deeply enough, the questions raised still seemed relatively unanswered. It doesn't really make a difference; wether or not one uses qmail or foomail is immaterial. But I'd think that it would make more sense to investigate another mailer before going off and reinventing large chunks of sendmail. Or, we could all go off and get copies of PMDF for FreeBSD. :-) :-) :-) - Dan C. From owner-freebsd-security Thu Jan 9 19:01:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA09635 for security-outgoing; Thu, 9 Jan 1997 19:01:08 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA09629 for ; Thu, 9 Jan 1997 19:01:05 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id TAA28811 for ; Thu, 9 Jan 1997 19:02:05 -0800 (PST) Received: (qmail 28618 invoked by uid 110); 10 Jan 1997 03:00:54 -0000 Message-ID: <19970110030053.28617.qmail@suburbia.net> Subject: Re: sendmail running non-root SUCCESS! In-Reply-To: <199701100157.RAA00592@cwsys.cwent.com> from Cy Schubert at "Jan 9, 97 05:57:52 pm" To: cschuber@uumail.gov.bc.ca Date: Fri, 10 Jan 1997 14:00:53 +1100 (EST) Cc: 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 > Alternatively one could use Qmail, however, I haven't managed to get it to > work with MH's slocal command. As far as I'm concerned that's a severe > restriction. > > Any thoughts? Did you try: echo '| preline /usr/local/lib/mh/slocal' >~/.qmail ? Cheers, Julian. From owner-freebsd-security Thu Jan 9 21:13:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA17711 for security-outgoing; Thu, 9 Jan 1997 21:13:29 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA17687 for ; Thu, 9 Jan 1997 21:13:18 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0viZGn-0006Qz-00; Thu, 9 Jan 1997 22:12:45 -0700 To: m-braithwaite@sjca.edu Subject: Re: Obvious fix for tempfile race conditions? Cc: freebsd-security@freebsd.org In-reply-to: Your message of "Tue, 07 Jan 1997 22:31:17 EST." <199701080331.WAA02781@continuity.sjca.edu> References: <199701080331.WAA02781@continuity.sjca.edu> Date: Thu, 09 Jan 1997 22:12:44 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199701080331.WAA02781@continuity.sjca.edu> Matt Braithwaite writes: : If I've got that much of it right, why not simply add a mount option : to disable symlinks on a given filesystem? Because it isn't needed? It is possible to safely remove file in /tmp or other hostile grounds by using fchdir and comparing before and after inode# and device# using stat and fstat. Check out the netbsd current list for a "saferm" that was posted there. Warner From owner-freebsd-security Thu Jan 9 21:26:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA18727 for security-outgoing; Thu, 9 Jan 1997 21:26:15 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA18720 for ; Thu, 9 Jan 1997 21:26:06 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0viZRh-0006S1-00; Thu, 9 Jan 1997 22:24:01 -0700 To: Dan Cross Subject: Re: sendmail running non-root SUCCESS! Cc: Lyndon Nerenberg , Jimbo Bahooli , freebsd-security@freebsd.org In-reply-to: Your message of "Thu, 09 Jan 1997 14:08:47 EST." <19970109190847.12307.qmail@spitfire.ecsel.psu.edu> References: <19970109190847.12307.qmail@spitfire.ecsel.psu.edu> Date: Thu, 09 Jan 1997 22:24:01 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <19970109190847.12307.qmail@spitfire.ecsel.psu.edu> Dan Cross writes: : Perhaps I'm being naive here, but what's the pressure to stick with : sendmail? Why not move to a more reliable and efficient MTA, like : Qmail? Short answer: Because qmail has an insufficient track record to replace a known workhorse like sendmail with in the base system. There are issue with configuration and such with qmail, and the upgrade path for current users. However, there is work underway to allow alternative mailer agents to be used, to allow more testing and experience with qmail, exim or any of the other replacements. Heck, you really should look into exim. There's even a FreeBSD port of it that is quite good. Makes virtual domains a breeze (as does qmail). Qmail isn't the end all be all of mailers either, but we've had that flame war here, and it tends to be counter productive. Warner From owner-freebsd-security Thu Jan 9 22:08:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA20952 for security-outgoing; Thu, 9 Jan 1997 22:08:26 -0800 (PST) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA20947 for ; Thu, 9 Jan 1997 22:08:23 -0800 (PST) Received: from localhost (steve@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) with SMTP id WAA02779; Thu, 9 Jan 1997 22:06:56 -0800 X-Authentication-Warning: bitbucket.edmweb.com: steve owned process doing -bs Date: Thu, 9 Jan 1997 22:06:54 -0800 (PST) From: Steve Reid To: Warner Losh cc: freebsd-security@freebsd.org Subject: Re: Obvious fix for tempfile race conditions? 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 > : If I've got that much of it right, why not simply add a mount option > : to disable symlinks on a given filesystem? > Because it isn't needed? It is possible to safely remove file in /tmp > or other hostile grounds by using fchdir and comparing before and > after inode# and device# using stat and fstat. Just because it _can_ be done safely doesn't mean that it _is_ being done safely. Consider the problem with /etc/security in 2.1.x: the script redirected the output of several commands onto a temporary file in /tmp, but made no checks on that file before writing to it. Any user could predict the filename and create a symlink, causing /etc/security to write to any file on the system. An obvious problem, and one would expect a script named "security" to pay attention to such issues. I'd bet there are other, less obvious problems in other programs. Disabling symlinks in /tmp would greatly reduce a cracker's options. From owner-freebsd-security Thu Jan 9 22:20:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA21503 for security-outgoing; Thu, 9 Jan 1997 22:20:36 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA21461 for ; Thu, 9 Jan 1997 22:20:06 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0viaIK-0006bf-00; Thu, 9 Jan 1997 23:18:24 -0700 To: Steve Reid Subject: Re: Obvious fix for tempfile race conditions? Cc: freebsd-security@freebsd.org In-reply-to: Your message of "Thu, 09 Jan 1997 22:06:54 PST." References: Date: Thu, 09 Jan 1997 23:18:24 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Steve Reid writes: : Just because it _can_ be done safely doesn't mean that it _is_ being : done safely. But it *IS* being done safely on OpenBSD. I see no reason why it can't be so on FreeBSD. The example you cited was just security ignorance on the part of the /etc/security writer. For example, I have /tmp not on my root, but on my /usr, so /tmp itself is a symlink. This proposed change would work only for systems that had /tmp being its own partion. Other systems would still be volunerable because we can't disable symlinks on / w/o breaking a whole lot of things (remote dumping, and termcap come to mind). In addition, it is nice to have things like tftpboot not on /, but pointing off somewhere else. : I'd bet there are other, less obvious problems in other programs. You are right. I have some changes in my queue to fix that however. : Disabling symlinks in /tmp would greatly reduce a cracker's options. Not really. There are so many holes in FreeBSD right now, I doubt it would slow them down much. Holes I'm working on closing, BTW. Here "so many" mean "at least one known that gives you root." It's a nice idea to have the kernel somehow magically solve the problems of security, but often times there is no substitute for good coding habits. Paraphrasing Brooks, There are no silver bullets in security. Warner From owner-freebsd-security Thu Jan 9 22:59:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA23718 for security-outgoing; Thu, 9 Jan 1997 22:59:34 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA23709 for ; Thu, 9 Jan 1997 22:59:31 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id XAA02479 for ; Thu, 9 Jan 1997 23:00:31 -0800 (PST) Received: (qmail 10485 invoked by uid 110); 10 Jan 1997 06:59:21 -0000 Message-ID: <19970110065921.10484.qmail@suburbia.net> Subject: Re: Obvious fix for tempfile race conditions? In-Reply-To: from Steve Reid at "Jan 9, 97 10:06:54 pm" To: steve@edmweb.com (Steve Reid) Date: Fri, 10 Jan 1997 17:59:21 +1100 (EST) Cc: 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 > I'd bet there are other, less obvious problems in other programs. > > Disabling symlinks in /tmp would greatly reduce a cracker's options. > > This is the wrong philosophical approach. Instead of bludgenoning the file-system, make it work for you. Create per-user temp directories. awk From owner-freebsd-security Fri Jan 10 01:19:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA01815 for security-outgoing; Fri, 10 Jan 1997 01:19:28 -0800 (PST) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA01810 for ; Fri, 10 Jan 1997 01:19:24 -0800 (PST) Received: from sidhe.hsc.fr (pb@sidhe.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.4/8.8.4/itesec-1.9) with ESMTP id KAA21384; Fri, 10 Jan 1997 10:19:20 +0100 (MET) Received: (from pb@localhost) by sidhe.hsc.fr (8.8.Alpha.4/sidhe-new-1.7) id KAA08316; Fri, 10 Jan 1997 10:19:19 +0100 (MET) Message-ID: Date: Fri, 10 Jan 1997 10:19:18 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: roberto@keltia.freenix.fr (Ollivier Robert) Cc: freebsd-security@freebsd.org Subject: Re: sendmail running non-root SUCCESS! References: <199701091347.IAA23487@homeport.org> X-Mailer: Mutt 0.50 Mime-Version: 1.0 In-Reply-To: ; from Ollivier Robert on Jan 9, 1997 20:04:12 +0100 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Ollivier Robert: > According to Pierre Beyssac: > > Not exactly (though I don't know procmail well enough: maybe it > > can do that too). > > Look on your own machine Pierre, that's the way I set it up when it was > mine :-) The way to do it is to use FEATURE(local_procmail). Maybe I was unclear, but I was not considering the 'local' mailer, since as far as I know it doesn't require sendmail to be setuid. I was talking about the 'prog' mailer and as far as I know and unless I missed something, procmail can't handle that. > > sendmail could process the .forward as usual, but it would > > call the external prog mailer to ask it to run "/home/user/bin/myownstuff" > > as "user" and pipe the mail to it. > > It is very easy to implement (winthin sendmail). Now, where is the patch > for the run-as-user program ? :-) Patch? It would take a little more than a patch, I'm affraid ;-)! The run-as-user program would have to be setuid, with some kind of access checking more complicated than just checking that sendmail is calling it (or we're almost back to square one with sendmail holes). > > I don't know how easy it would be to make this secure, it's just an > > idea. My feeling is that it should be possible to define something > > more modular than sendmail, with only very few parts setuid inside. > > That's Qmail for you. Uh, okay, when Qmail will be configuration-compatible with sendmail, we can talk about it. In the meanwhile, why not try to fix sendmail by improving its implementation somewhat? There certainly are other options than dropping sendmail alltogether on the premise that it's broken. If it's broken, it should be fixed. -- Pierre.Beyssac@hsc.fr From owner-freebsd-security Fri Jan 10 09:31:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA22286 for security-outgoing; Fri, 10 Jan 1997 09:31:02 -0800 (PST) Received: from spitfire.ecsel.psu.edu (qmailr@spitfire.ecsel.psu.edu [146.186.218.51]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA22281 for ; Fri, 10 Jan 1997 09:30:59 -0800 (PST) Received: (qmail 1420 invoked by uid 1000); 10 Jan 1997 17:30:59 -0000 Message-ID: <19970110173059.1419.qmail@spitfire.ecsel.psu.edu> To: Warner Losh cc: Lyndon Nerenberg , Jimbo Bahooli , freebsd-security@freebsd.org Subject: Re: sendmail running non-root SUCCESS! In-reply-to: Your message of "Thu, 09 Jan 1997 22:24:01 MST." Date: Fri, 10 Jan 1997 12:30:59 -0500 From: Dan Cross Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Because qmail has an insufficient track record to replace a > known workhorse like sendmail with in the base system. True, few mailers have the track record of a new security bug being found in them once a month or so, one of which being one of the four ways in which the Internet worm propogated itself. :-) :-) :-) > There are > issue with configuration and such with qmail, and the upgrade path for > current users. However, there is work underway to allow alternative > mailer agents to be used, to allow more testing and experience with > qmail, exim or any of the other replacements. Great! Like I said, what mailer is used doesn't really matter, but it's clear that sendmail is losing the security versus features battle. If Eric can make things secure, then great, stick with sendmail. If not, then it's irresponsible to stick with sendmail, and alternatives should be investigated. > Heck, you really should look into exim. There's even a FreeBSD port > of it that is quite good. Makes virtual domains a breeze (as does > qmail). Thanks, I will. Btw- I'm surprised to see that qmail isn't in the ports collection. I have a port for it, and if people are interested, I'll clean it up and upload it to freefall and do the send-pr thang... > Qmail isn't the end all be all of mailers either, but we've had that > flame war here, and it tends to be counter productive. All flame wars are counter productive. As I've said several times now (yesh, you guys are really sensative to this qmail thing, huh? :-), whatever mailer one chooses is irrelevant. As long as that mailer does what is required of it, is relatively efficient, and is secure, then go with it. I just picked qmail as one suggestion out of many possibilities. Sendmail would be fine if it was more secure, but unfortunately Eric seems to be more hip on adding neat features and improving cf file syntax than scouring code for potential security bugs (I can't say that I blame him. :-) The point is that there are alternate mailers out there and it's worthwhile to investigate them. Few sites really need the power and complexity of sendmail, yet most admins are going to run it because a) it comes with the system, b) it's common and thus easy to find support for, c) other alteratives are unknown or not well supported, d) it does what most folks want. These sites could probably get away with replacing sendmail with another mailer which does what they need of it, but is more secure. - Dan C. From owner-freebsd-security Fri Jan 10 12:06:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA29238 for security-outgoing; Fri, 10 Jan 1997 12:06:02 -0800 (PST) Received: from super-g.inch.com (super-g.com [204.178.32.161]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA29233 for ; Fri, 10 Jan 1997 12:05:58 -0800 (PST) Received: from localhost (spork@localhost) by super-g.inch.com (8.8.4/8.6.9) with SMTP id PAA11370; Fri, 10 Jan 1997 15:18:01 -0500 (EST) Date: Fri, 10 Jan 1997 15:18:00 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: Warner Losh cc: Steve Reid , freebsd-security@freebsd.org Subject: Re: Obvious fix for tempfile race conditions? 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 Thu, 9 Jan 1997, Warner Losh wrote: > But it *IS* being done safely on OpenBSD. I see no reason why it > can't be so on FreeBSD. I agree; it's nice that FBSD is tighter than Linux (our Linux webservers are secure in that access to them is carefully controlled, but I still feel it's pretty slutty). > You are right. I have some changes in my queue to fix that however. Good!! > Not really. There are so many holes in FreeBSD right now, I doubt it > would slow them down much. Holes I'm working on closing, BTW. Here > "so many" mean "at least one known that gives you root." > > It's a nice idea to have the kernel somehow magically solve the > problems of security, but often times there is no substitute for good > coding habits. Paraphrasing Brooks, There are no silver bullets in > security. So, is there anything that someone like me can do (I'm more tied up in the administration, and my programming skills are pretty weak) to look around and see what's been done on OpenBSD and compile a list of "must fix" items?? I'd like to help on this front. Is there anything I can do? Charles From owner-freebsd-security Fri Jan 10 15:09:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA08462 for security-outgoing; Fri, 10 Jan 1997 15:09:22 -0800 (PST) Received: from maslow.cia-g.com (root@maslow.cia-g.com [206.206.162.5]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA08455 for ; Fri, 10 Jan 1997 15:09:20 -0800 (PST) Received: from maslow.cia-g.com (lithium@maslow.cia-g.com [206.206.162.5]) by maslow.cia-g.com (8.8.4/8.7.3) with SMTP id QAA27599; Fri, 10 Jan 1997 16:08:55 -0700 (MST) Date: Fri, 10 Jan 1997 16:08:55 -0700 (MST) From: Stephen Fisher To: Warner Losh cc: Steve Reid , freebsd-security@freebsd.org Subject: Re: Obvious fix for tempfile race conditions? 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 Thu, 9 Jan 1997, Warner Losh wrote: > In message Steve Reid writes: > : Just because it _can_ be done safely doesn't mean that it _is_ being > : done safely. > > But it *IS* being done safely on OpenBSD. I see no reason why it > can't be so on FreeBSD. The example you cited was just security > ignorance on the part of the /etc/security writer. If OpenBSD is so much better why doesn't anyone else get word of OpenBSD's fixes? > Not really. There are so many holes in FreeBSD right now, I doubt it > would slow them down much. Holes I'm working on closing, BTW. Here > "so many" mean "at least one known that gives you root." Anything helps. - Steve - Systems Manager - Community Internet Access, Inc. - Gallup and Grants, New Mexico From owner-freebsd-security Fri Jan 10 15:44:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA09715 for security-outgoing; Fri, 10 Jan 1997 15:44:42 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA09710 for ; Fri, 10 Jan 1997 15:44:37 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0viqc4-0000is-00; Fri, 10 Jan 1997 16:43:52 -0700 To: Stephen Fisher Subject: Re: Obvious fix for tempfile race conditions? Cc: Steve Reid , freebsd-security@freebsd.org In-reply-to: Your message of "Fri, 10 Jan 1997 16:08:55 MST." References: Date: Fri, 10 Jan 1997 16:43:51 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Stephen Fisher writes: : If OpenBSD is so much better why doesn't anyone else get word of OpenBSD's : fixes? Might I draw to your attention the lpr/lpd fixes, the dump fixes and the restore fixes that have already gone into the tree, the telnetd fixes, etc. Things are happening here, but they must be done carefully to avoid introducing unintended new holes, or (more likely) bugs due to the minor variation in source bases. : > Not really. There are so many holes in FreeBSD right now, I doubt it : > would slow them down much. Holes I'm working on closing, BTW. Here : > "so many" mean "at least one known that gives you root." : : Anything helps. Not if the cure is worse than the disease. Warner From owner-freebsd-security Fri Jan 10 16:42:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA13786 for security-outgoing; Fri, 10 Jan 1997 16:42:01 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA13765 for ; Fri, 10 Jan 1997 16:41:55 -0800 (PST) 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 BAA10650 for ; Sat, 11 Jan 1997 01:41:43 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id BAA08827 for freebsd-security@freebsd.org; Sat, 11 Jan 1997 01:41:26 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id BAA04193; Sat, 11 Jan 1997 01:34:50 +0100 (CET) Message-ID: Date: Sat, 11 Jan 1997 01:34:50 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-security@freebsd.org Subject: Re: sendmail running non-root SUCCESS! References: <19970110173059.1419.qmail@spitfire.ecsel.psu.edu> X-Mailer: Mutt 0.55.15 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2837 In-Reply-To: <19970110173059.1419.qmail@spitfire.ecsel.psu.edu>; from Dan Cross on Jan 10, 1997 12:30:59 -0500 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Dan Cross: > would be fine if it was more secure, but unfortunately Eric seems > to be more hip on adding neat features and improving cf file syntax > than scouring code for potential security bugs (I can't say that I > blame him. :-) As a sendmail alpha-tester, I can't agree with this. It may be the impression outsiders get but it is definitely wrong. > probably get away with replacing sendmail with another mailer which > does what they need of it, but is more secure. Anyone can use any mailer they want, the real discussion has never been to choose between one or the other but what should be standard (i.e. in /usr/src). -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #33: Sat Dec 21 12:57:17 CET 1996