From owner-freebsd-security Sun Sep 12 4:39:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1EE8014F6E; Sun, 12 Sep 1999 04:39:04 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA13690; Sun, 12 Sep 1999 13:39:02 +0200 (CEST) (envelope-from des) To: Ben Smithurst Cc: "Jeremy L. Ramirez" , dev-null@ns1.digicomsystems.net, freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info References: <4.2.0.58.19990911151659.00aa8d60@ns1.digicomsystems.net> <19990912012524.B41509@lithium.scientia.demon.co.uk> From: Dag-Erling Smorgrav Date: 12 Sep 1999 13:39:01 +0200 In-Reply-To: Ben Smithurst's message of "Sun, 12 Sep 1999 01:25:24 +0100" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ben Smithurst writes: > An even better way is to disable telnet completely, and use ssh like you > should. Note that people can still use nmap or something to guess at > your OS. # ipfw add 1 deny tcp from any to any in tcpflags syn,fin No they can't. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 7:10:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from saturn.psn.net (saturn.psn.net [207.211.58.15]) by hub.freebsd.org (Postfix) with ESMTP id E5F3D14F77 for ; Sun, 12 Sep 1999 07:10:29 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from shadow.blackdawn.com (5042-243.008.popsite.net [209.224.140.243]) by saturn.psn.net (8.9.3/8.9.3) with ESMTP id HAA22281; Sun, 12 Sep 1999 07:16:18 -0700 (MST) Received: (from will@localhost) by shadow.blackdawn.com (8.9.3/8.9.3) id KAA94412; Sun, 12 Sep 1999 10:10:25 -0400 (EDT) (envelope-from will) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199909120407.VAA30134@gndrsh.dnsmgr.net> Date: Sun, 12 Sep 1999 10:10:25 -0400 (EDT) Reply-To: Will Andrews From: Will Andrews To: (Anil Jangity) Subject: Re: ipfw question Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12-Sep-99 Rodney W. Grimes wrote: >> I am using FreeBSD2.2.8 Stable with IPFW enalbed with logging. FreeBSD 3.3-RC (current -STABLE) has updated ipfw somewhat. >> Also does anyone know if IP Filters (or ipfw) let you limit logging >> depending on the rate at which the rule is applied? See /sys/i386/conf/LINT regarding options IPFIREWALL_VERBOSE options "IPFIREWALL_VERBOSITY_LIMIT=10" or something similar. The drawback to these features is that the limit doesn't behave the way I think it should (although as a result, I don't use VERBOSITY_LIMIT) - instead of just counting repeating packets, it kills the rule the packets are matched against after the rule reaches the limit specified. -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 8:20:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from saturn.psn.net (saturn.psn.net [207.211.58.15]) by hub.freebsd.org (Postfix) with ESMTP id 7D14A14D70; Sun, 12 Sep 1999 08:20:14 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from shadow.blackdawn.com (5042-243.008.popsite.net [209.224.140.243]) by saturn.psn.net (8.9.3/8.9.3) with ESMTP id IAA21150; Sun, 12 Sep 1999 08:25:53 -0700 (MST) Received: (from will@localhost) by shadow.blackdawn.com (8.9.3/8.9.3) id LAA96143; Sun, 12 Sep 1999 11:19:59 -0400 (EDT) (envelope-from will) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19990912012524.B41509@lithium.scientia.demon.co.uk> Date: Sun, 12 Sep 1999 11:19:58 -0400 (EDT) Reply-To: Will Andrews From: Will Andrews To: Ben Smithurst Subject: Re: How to prevent motd including os info Cc: freebsd-security@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, dev-null@ns1.digicomsystems.net, "Jeremy L. Ramirez" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12-Sep-99 Ben Smithurst wrote: > Jeremy L. Ramirez wrote: > >> telnet stream tcp nowait root /usr/libexec/telnetd telnetd -h >> >> what you are doing is adding the -h at the end of the line which prevents >> a user from seeing the OS before even logging in. > > An even better way is to disable telnet completely, and use ssh like you > should. Note that people can still use nmap or something to guess at > your OS. > > -- > Ben Smithurst | PGP: 0x99392F7D > ben@scientia.demon.co.uk | key available from keyservers and > | ben+pgp@scientia.demon.co.uk > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 8:34:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id B8E3214F49; Sun, 12 Sep 1999 08:34:19 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA21204; Sun, 12 Sep 1999 09:34:09 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA18584; Sun, 12 Sep 1999 09:34:08 -0600 Date: Sun, 12 Sep 1999 09:34:08 -0600 Message-Id: <199909121534.JAA18584@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dag-Erling Smorgrav Cc: Ben Smithurst , "Jeremy L. Ramirez" , dev-null@ns1.digicomsystems.net, freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info In-Reply-To: References: <4.2.0.58.19990911151659.00aa8d60@ns1.digicomsystems.net> <19990912012524.B41509@lithium.scientia.demon.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > An even better way is to disable telnet completely, and use ssh like you > > should. Note that people can still use nmap or something to guess at > > your OS. > > # ipfw add 1 deny tcp from any to any in tcpflags syn,fin > > No they can't. Except if you do this the box is unable to provide *ANY* external sevices, including email and/or DNS service. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 8:52:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from saturn.psn.net (saturn.psn.net [207.211.58.15]) by hub.freebsd.org (Postfix) with ESMTP id 3129814CA5; Sun, 12 Sep 1999 08:52:22 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from shadow.blackdawn.com (5042-243.008.popsite.net [209.224.140.243]) by saturn.psn.net (8.9.3/8.9.3) with ESMTP id IAA25556; Sun, 12 Sep 1999 08:57:46 -0700 (MST) Received: (from will@localhost) by shadow.blackdawn.com (8.9.3/8.9.3) id LAA99262; Sun, 12 Sep 1999 11:51:13 -0400 (EDT) (envelope-from will) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 12 Sep 1999 11:51:13 -0400 (EDT) Reply-To: Will Andrews From: Will Andrews To: Will Andrews Subject: Re: How to prevent motd including os info Cc: "Jeremy L. Ramirez" , dev-null@ns1.digicomsystems.net, freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG, Ben Smithurst Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ack, err, sorry.. On 12-Sep-99 Will Andrews wrote: > > On 12-Sep-99 Ben Smithurst wrote: >> Jeremy L. Ramirez wrote: >> >>> telnet stream tcp nowait root /usr/libexec/telnetd telnetd -h >>> >>> what you are doing is adding the -h at the end of the line which prevents >>> a user from seeing the OS before even logging in. >> >> An even better way is to disable telnet completely, and use ssh like you >> should. Note that people can still use nmap or something to guess at >> your OS. I'm still amazed that some people still use telnet to any extent. ssh+RSA Authentication forever.. -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 9: 4:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from saturn.psn.net (saturn.psn.net [207.211.58.15]) by hub.freebsd.org (Postfix) with ESMTP id CDE8314EE4 for ; Sun, 12 Sep 1999 09:04:25 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from shadow.blackdawn.com (5042-243.008.popsite.net [209.224.140.243]) by saturn.psn.net (8.9.3/8.9.3) with ESMTP id JAA27529; Sun, 12 Sep 1999 09:10:15 -0700 (MST) Received: (from will@localhost) by shadow.blackdawn.com (8.9.3/8.9.3) id MAA00160; Sun, 12 Sep 1999 12:04:18 -0400 (EDT) (envelope-from will) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199909121534.JAA18584@mt.sri.com> Date: Sun, 12 Sep 1999 12:04:18 -0400 (EDT) Reply-To: Will Andrews From: Will Andrews To: Nate Williams Subject: Re: How to prevent motd including os info Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12-Sep-99 Nate Williams wrote: > Except if you do this the box is unable to provide *ANY* external > sevices, including email and/or DNS service. :( Umm.. seems to work fine here. DNS, email, web, etc. -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 9: 6:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id BD48014EE4; Sun, 12 Sep 1999 09:06:34 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA14371; Sun, 12 Sep 1999 18:06:29 +0200 (CEST) (envelope-from des) To: nate@mt.sri.com (Nate Williams) Cc: Dag-Erling Smorgrav , Ben Smithurst , "Jeremy L. Ramirez" , dev-null@ns1.digicomsystems.net, freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info References: <4.2.0.58.19990911151659.00aa8d60@ns1.digicomsystems.net> <19990912012524.B41509@lithium.scientia.demon.co.uk> <199909121534.JAA18584@mt.sri.com> From: Dag-Erling Smorgrav Date: 12 Sep 1999 18:06:28 +0200 In-Reply-To: Nate Williams's message of "Sun, 12 Sep 1999 09:34:08 -0600" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams writes: > > # ipfw add 1 deny tcp from any to any in tcpflags syn,fin > Except if you do this the box is unable to provide *ANY* external > sevices, including email and/or DNS service. :( Not true. I've had two moderately busy IRC servers (one of them averages 700 clients, the other twice that) running with this ipfw rule for two or three months without a hitch. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 9:39: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from srv4-bnu.bnu.zaz.com.br (srv4-bnu.bnu.nutecnet.com.br [200.247.224.5]) by hub.freebsd.org (Postfix) with ESMTP id 2BB7B154E2 for ; Sun, 12 Sep 1999 09:38:41 -0700 (PDT) (envelope-from fatboy@linuxbr.com.br) Received: from jackson.zaz.com.br (ip-248-49-35.joi.zaz.com.br [200.248.49.35]) by srv4-bnu.bnu.zaz.com.br (8.8.5/SCA-6.6) with SMTP id NAA08075 for ; Sun, 12 Sep 1999 13:38:18 -0300 (BRA) Message-ID: <001301befd3d$10ef4060$c800000a@jackson.zaz.com.br> From: "Jackson Donadel" To: Subject: BIG OFF-TOPIC READ IF YOU WANT - IS FOR SKALIR Date: Sun, 12 Sep 1999 13:37:09 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01BEFD23.E9BCCDA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0010_01BEFD23.E9BCCDA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Skalir you live? Please answer my email Jackson ------=_NextPart_000_0010_01BEFD23.E9BCCDA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Skalir you live?
Please answer my email
 
Jackson
------=_NextPart_000_0010_01BEFD23.E9BCCDA0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 9:47:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 3AE9E1542E; Sun, 12 Sep 1999 09:47:26 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA14574; Sun, 12 Sep 1999 18:47:24 +0200 (CEST) (envelope-from des) To: Dag-Erling Smorgrav Cc: nate@mt.sri.com (Nate Williams), Ben Smithurst , "Jeremy L. Ramirez" , dev-null@ns1.digicomsystems.net, freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info References: <4.2.0.58.19990911151659.00aa8d60@ns1.digicomsystems.net> <19990912012524.B41509@lithium.scientia.demon.co.uk> <199909121534.JAA18584@mt.sri.com> From: Dag-Erling Smorgrav Date: 12 Sep 1999 18:47:23 +0200 In-Reply-To: Dag-Erling Smorgrav's message of "12 Sep 1999 18:06:28 +0200" Message-ID: Lines: 176 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dag-Erling Smorgrav writes: > Nate Williams writes: > > > # ipfw add 1 deny tcp from any to any in tcpflags syn,fin > > Except if you do this the box is unable to provide *ANY* external > > sevices, including email and/or DNS service. :( > Not true. I've had two moderately busy IRC servers (one of them > averages 700 clients, the other twice that) running with this ipfw > rule for two or three months without a hitch. Speaking of which - if you will allow me this tangent - I will never cease to be amazed by how much some people who ought to know better *think* they know about TCP/IP security and attack patterns, and how quick they are to handwave problems pointed out to them (or patches submitted for review) with some vague comments about "yes, in theory it could be a problem, but you'll never see this in real life", until I explain that my analyses and calculations are not based on fancy thought experiments but on hard, real-life, all-in-a-day's-work data. To return to the subject matter, I have patches which (provided you build your kernel with the appropriate options) add a sysctl switch for dropping SYN+FIN packets in tcp_input() instead of having ipfw or ipfilter do it. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no Index: etc/rc.network =================================================================== RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.59 diff -u -r1.59 rc.network --- rc.network 1999/09/01 08:57:01 1.59 +++ rc.network 1999/09/07 17:30:13 @@ -229,6 +229,16 @@ sysctl -w net.inet.tcp.always_keepalive=1 >/dev/null fi + if [ "X$tcp_restrict_rst" = X"YES" ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 >/dev/null + fi + + if [ "X$tcp_drop_synfin" = X"YES" ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 >/dev/null + fi + if [ "${ipxgateway_enable}" = "YES" ]; then echo -n ' IPX gateway=YES' sysctl -w net.ipx.ipx.ipxforwarding=1 >/dev/null Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.32 diff -u -r1.32 rc.conf --- rc.conf 1999/09/06 20:22:40 1.32 +++ rc.conf 1999/09/07 17:30:40 @@ -48,6 +48,9 @@ tcp_extensions="NO" # Set to YES to turn on RFC1323 extensions. log_in_vain="NO" # YES to log connects to ports w/o listeners. tcp_keepalive="YES" # Enable stale TCP connection timeout (or NO). +tcp_restrict_rst="NO" # Set to YES to restrict emission of RST +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) icmp_drop_redirect="NO" # Set to YES to ignore ICMP REDIRECT packets icmp_log_redirect="NO" # Set to YES to log ICMP REDIRECT packets network_interfaces="auto" # List of network interfaces (or "auto"). Index: sys/conf/options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.152 diff -u -r1.152 options --- options 1999/09/08 22:01:31 1.152 +++ options 1999/09/09 09:16:45 @@ -228,6 +228,8 @@ SLIP_IFF_OPTS opt_slip.h TCP_COMPAT_42 opt_compat.h TCPDEBUG +TCP_RESTRICT_RST opt_tcp_input.h +TCP_DROP_SYNFIN opt_tcp_input.h # ATM (HARP version) ATM_CORE opt_atm.h Index: sys/i386/conf/LINT =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.641 diff -u -r1.641 LINT --- LINT 1999/09/08 22:03:46 1.641 +++ LINT 1999/09/09 09:17:00 @@ -469,6 +469,20 @@ options IPSTEALTH #support for stealth forwarding options TCPDEBUG +# The following options add sysctl variables for controlling how certain +# TCP packets are handled. +# +# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. +# This is useful on systems which are exposed to SYN floods (e.g. IRC servers) +# or any system which one does not want to be easily portscannable. +# +# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This +# prevents nmap et al. from identifying the TCP/IP stack, but breaks support +# for RFC1644 extensions and is not recommended for web servers. +# +options TCP_RESTRICT_RST #restrict emission of TCP RST +options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN + # ICMP_BANDLIM enables icmp error response bandwidth limiting. You # typically want this option as it will help protect the machine from # D.O.S. packet attacks. Index: sys/netinet/tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.93 diff -u -r1.93 tcp_input.c --- tcp_input.c 1999/08/30 21:17:06 1.93 +++ tcp_input.c 1999/09/07 17:37:50 @@ -36,6 +36,7 @@ #include "opt_ipfw.h" /* for ipfw_fwd */ #include "opt_tcpdebug.h" +#include "opt_tcp_input.h" #include #include @@ -93,6 +94,18 @@ &tcp_delack_enabled, 0, "Delay ACK to try and piggyback it onto a data packet"); +#ifdef TCP_RESTRICT_RST +static int restrict_rst = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, restrict_rst, CTLFLAG_RW, + &restrict_rst, 0, "Restrict RST emission"); +#endif + +#ifdef TCP_DROP_SYNFIN +static int drop_synfin = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, drop_synfin, CTLFLAG_RW, + &drop_synfin, 0, "Drop TCP packets with FIN+ACK set"); +#endif + struct inpcbhead tcb; struct inpcbinfo tcbinfo; @@ -340,6 +353,18 @@ } tiflags = ti->ti_flags; +#ifdef TCP_DROP_SYNFIN + /* + * If the drop_synfin option is enabled, drop all packets with + * both the SYN and FIN bits set. This prevents e.g. nmap from + * identifying the TCP/IP stack. + * + * This is incompatible with RFC1644 extensions (T/TCP). + */ + if (drop_synfin && (tiflags & (TH_SYN|TH_FIN)) == (TH_SYN|TH_FIN)) + goto drop; +#endif + /* * Convert TCP protocol specific fields to host format. */ @@ -1849,6 +1874,10 @@ return; dropwithreset: +#ifdef TCP_RESTRICT_RST + if (restrict_rst) + goto drop; +#endif /* * Generate a RST, dropping incoming segment. * Make ACK acceptable to originator of segment. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 9:52:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from justice.zips.net (justice.zips.net [207.234.219.219]) by hub.freebsd.org (Postfix) with ESMTP id 80CF31540B; Sun, 12 Sep 1999 09:52:31 -0700 (PDT) (envelope-from zips@zips.net) Received: from localhost (zips@localhost) by justice.zips.net (8.9.3/8.9.3) with ESMTP id MAA21512; Sun, 12 Sep 1999 12:56:39 -0400 (EDT) (envelope-from zips@zips.net) Date: Sun, 12 Sep 1999 12:56:39 -0400 (EDT) From: Hector Colmenares To: Will Andrews Cc: Ben Smithurst , freebsd-security@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, dev-null@ns1.digicomsystems.net, "Jeremy L. Ramirez" Subject: Re: How to prevent motd including os info In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you dont want people to know what OS are you running when they telnet into your box just change to this the info in /etc/gettytab default:\ :cb:ce:ck:lc:fd#1000:im=\r\n\%h\r\nAccess Restricted\ r\n\r\nFor info, email admin@%h\r\nToday is %d\r\n\r\n ;-) cheers !! On Sun, 12 Sep 1999, Will Andrews wrote: > > On 12-Sep-99 Ben Smithurst wrote: > > Jeremy L. Ramirez wrote: > > > >> telnet stream tcp nowait root /usr/libexec/telnetd telnetd -h > >> > >> what you are doing is adding the -h at the end of the line which prevents > >> a user from seeing the OS before even logging in. > > > > An even better way is to disable telnet completely, and use ssh like you > > should. Note that people can still use nmap or something to guess at > > your OS. > > > > -- > > Ben Smithurst | PGP: 0x99392F7D > > ben@scientia.demon.co.uk | key available from keyservers and > > | ben+pgp@scientia.demon.co.uk > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 10:19:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 3073914CCC for ; Sun, 12 Sep 1999 10:17:55 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id TAA14850; Sun, 12 Sep 1999 19:16:40 +0200 (CEST) (envelope-from des) To: Will Andrews Cc: (Anil Jangity) , freebsd-security@FreeBSD.ORG Subject: Re: ipfw question References: From: Dag-Erling Smorgrav Date: 12 Sep 1999 19:16:39 +0200 In-Reply-To: Will Andrews's message of "Sun, 12 Sep 1999 10:10:25 -0400 (EDT)" Message-ID: Lines: 17 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Will Andrews writes: > [...] The drawback to these features is that the limit doesn't > behave the way I think it should (although as a result, I don't use > VERBOSITY_LIMIT) - instead of just counting repeating packets, it kills the > rule the packets are matched against after the rule reaches the limit specified. It would be more accurate (and less misleading) to say "silence" instead of "kill". It does not remove nor disable the rule, it just stops logging packets that match that particular rule until you reset the counters. In 4.0, you can reset the log counters independently of the match counters ('ipfw resetlog' instead of 'ipfw zero'), which allows you to restart logging even when running at high securelevels (all ipfw commands except resetlog are disabled at securelevel >= 3). DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 10:20:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from hawaii.conterra.com (hawaii.conterra.com [209.12.164.32]) by hub.freebsd.org (Postfix) with ESMTP id B236715547; Sun, 12 Sep 1999 10:20:36 -0700 (PDT) (envelope-from myself@conterra.com) Received: from dmaddox.conterra.com (root@dmaddox.conterra.com [209.12.169.48]) by hawaii.conterra.com (8.9.3/8.9.3) with ESMTP id NAA10678; Sun, 12 Sep 1999 13:13:53 -0400 (EDT) Received: (from myself@localhost) by dmaddox.conterra.com (8.9.3/8.9.1) id NAA31849; Sun, 12 Sep 1999 13:13:44 -0400 (EDT) (envelope-from myself) Date: Sun, 12 Sep 1999 13:13:44 -0400 From: "Donald J . Maddox" To: Hector Colmenares Cc: Will Andrews , Ben Smithurst , freebsd-security@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, dev-null@ns1.digicomsystems.net, "Jeremy L. Ramirez" Subject: Re: How to prevent motd including os info Message-ID: <19990912131344.B31706@dmaddox.conterra.com> Reply-To: dmaddox@conterra.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there a way to suppress the copyright info? This is pretty much a dead giveaway (At least that it's *BSD), huh? See lines 14-15 below: $ telnet dmaddox.conterra.com Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. dmaddox.conterra.com Access Restricted Today is Sun Sep 12 13:09:57 EDT 1999 login: myself Password: Last login: Sun Sep 12 13:07:17 from localhost Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. Welcome to BogoDOS! You have mail. $ On Sun, Sep 12, 1999 at 12:56:39PM -0400, Hector Colmenares wrote: > > > If you dont want people to know what OS are you running > when they telnet into your box just change to this the info in > /etc/gettytab > > default:\ > :cb:ce:ck:lc:fd#1000:im=\r\n\%h\r\nAccess Restricted\ > r\n\r\nFor info, email admin@%h\r\nToday is %d\r\n\r\n > > > ;-) > > cheers !! > > On Sun, 12 Sep 1999, Will Andrews wrote: > > > > > On 12-Sep-99 Ben Smithurst wrote: > > > Jeremy L. Ramirez wrote: > > > > > >> telnet stream tcp nowait root /usr/libexec/telnetd telnetd -h > > >> > > >> what you are doing is adding the -h at the end of the line which prevents > > >> a user from seeing the OS before even logging in. > > > > > > An even better way is to disable telnet completely, and use ssh like you > > > should. Note that people can still use nmap or something to guess at > > > your OS. > > > > > > -- > > > Ben Smithurst | PGP: 0x99392F7D > > > ben@scientia.demon.co.uk | key available from keyservers and > > > | ben+pgp@scientia.demon.co.uk > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 11: 1:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id B304D1540B; Sun, 12 Sep 1999 11:01:36 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA31199; Sun, 12 Sep 1999 10:49:37 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909121749.KAA31199@gndrsh.dnsmgr.net> Subject: Re: How to prevent motd including os info In-Reply-To: from Dag-Erling Smorgrav at "Sep 12, 1999 06:47:23 pm" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Sun, 12 Sep 1999 10:49:37 -0700 (PDT) Cc: nate@mt.sri.com (Nate Williams), ben@scientia.demon.co.uk (Ben Smithurst), jramirez@digicomsystems.net (Jeremy L. Ramirez), dev-null@ns1.digicomsystems.net, freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ... > > To return to the subject matter, I have patches which (provided you > build your kernel with the appropriate options) add a sysctl switch > for dropping SYN+FIN packets in tcp_input() instead of having ipfw or > ipfilter do it. So when can we see this commited.... the only thing I would like changed is actually a general format of output change in /etc/rc.network, if you have a few of the ``tcp_*'' knobs set the line length gets a bit long, could be change the ``echo -n'''s to ``echo \t'' and loose the trailing ``echo '.'''. > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no > > Index: etc/rc.network > =================================================================== > RCS file: /home/ncvs/src/etc/rc.network,v Applied to my tree :-)... -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 11:45:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8B4BE14C10; Sun, 12 Sep 1999 11:45:50 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id UAA15125; Sun, 12 Sep 1999 20:45:44 +0200 (CEST) (envelope-from des) To: "Rodney W. Grimes" Cc: hackers@freebsd.org Subject: Re: How to prevent motd including os info References: <199909121749.KAA31199@gndrsh.dnsmgr.net> From: Dag-Erling Smorgrav Date: 12 Sep 1999 20:45:43 +0200 In-Reply-To: "Rodney W. Grimes"'s message of "Sun, 12 Sep 1999 10:49:37 -0700 (PDT)" Message-ID: Lines: 42 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [moving to -hackers] "Rodney W. Grimes" writes: > So when can we see this commited.... Already done (-CURRENT only). I've had requests (notably from Yan Koum) to backport it to -STABLE, but I won't do it so close to a release. > the only thing I would like > changed is actually a general format of output change in /etc/rc.network, > if you have a few of the ``tcp_*'' knobs set the line length gets > a bit long, could be change the ``echo -n'''s to ``echo \t'' and loose > the trailing ``echo '.'''. I don't consider that much of a problem, except in cases where individual scripts / options produce output which breaks the line (this is mostly a problem with ports). I wouldn't mind the changes you suggest, but I don't care enough to actually go ahead and do it. One thing I'd like very much, though, would be to have the output of fsck -p logged somehow - but since we don't have anything mounted rw when fsck runs, it's a bit hard to log to disk. You could of course do something like this: fsck_output="$(/sbin/fsck -p)" /sbin/mount -at nonfs echo "${fsck_output}" >/var/run/fsck.boot but then you wouldn't be able to see the output while it runs. The only solution I can think of is the following: fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)" /sbin/mount -at nonfs echo "${fsck_output}" >/var/run/fsck.boot but I don't expect people to be happy about moving tee(1) from /usr/bin to /bin. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 12:45:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 5C6A9153D6; Sun, 12 Sep 1999 12:44:38 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from lithium.scientia.demon.co.uk ([192.168.0.3] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.032 #1) id 11QBt3-000FmH-00; Sun, 12 Sep 1999 16:49:53 +0100 Received: (from ben) by lithium.scientia.demon.co.uk (Exim 3.032 #1) id 11QBt2-000BQo-00; Sun, 12 Sep 1999 16:49:52 +0100 Date: Sun, 12 Sep 1999 16:49:52 +0100 From: Ben Smithurst To: Dag-Erling Smorgrav Cc: freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info Message-ID: <19990912164952.A43885@lithium.scientia.demon.co.uk> References: <4.2.0.58.19990911151659.00aa8d60@ns1.digicomsystems.net> <19990912012524.B41509@lithium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dag-Erling Smorgrav wrote: > Ben Smithurst writes: > >> Note that people can still use nmap or something to guess at your OS. > > # ipfw add 1 deny tcp from any to any in tcpflags syn,fin > > No they can't. Thanks, I didn't know about that. I'll try to remember it though. -- Ben Smithurst | PGP: 0x99392F7D ben@scientia.demon.co.uk | key available from keyservers and | ben+pgp@scientia.demon.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 13:21:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id A7D1814CBE; Sun, 12 Sep 1999 13:20:56 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id PAA13724; Sun, 12 Sep 1999 15:20:52 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from dial-176.tnt1.rac.cyberlynk.net(209.224.182.176) by peak.mountin.net via smap (V1.3) id sma013721; Sun Sep 12 15:20:23 1999 Message-Id: <3.0.3.32.19990912151948.01d36380@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 12 Sep 1999 15:19:48 -0500 To: patmac@demon.net, freebsd-questions@FreeBSD.ORG From: "Jeffrey J. Mountin" Subject: Re: How to prevent motd including os info Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <199909111127.MAA00229@gti.noc.demon.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:27 PM 9/11/99 +0100, Patrick MacKeown wrote: [leaving -questions, not subscribed] >Hi > >Please would somebody tell me how to prevent motd including the OS version >and the kernel name. On my 3.2 box editing the lines out of /etc/motd just >leads to them being replaced Before this thread gets any more ridiculous... Are you allowing users to telnet or ssh in in the first place? Or if you allow ftp, the version is a clue. If so, then what's to stop them from doing a 'uname' among other things. Security through obscurity should be the subject here, at least until you mention that you *are* not allowing logins. Otherwise.... As for the question, make sure that you don't have 'update_motd="YES"' in /etc/rc.conf (or horror of horrors if do this in /etc/defaults/rc.conf). Edit the file as you like and don't clobber it when you update /etc/ after a build. FWIW, only first 2 lines after left in motd. The rest is just noise for when others login. Don't give a rat's @$$ if they know what the system is, since I'm allowing them on it anyways. And for those that can't login. Adding '-h' to telnet in inetd is a good idea, editing the outputs of the daemons listening to other ports is even better, but even then it is still possible to guess. Then again as well, one can just try an exploit, so you spent a lot of time for nothing. my .02 Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 18:10:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 476E514CA3; Sun, 12 Sep 1999 18:10:49 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id VAA27314; Sun, 12 Sep 1999 21:10:47 -0400 (EDT) (envelope-from wollman) Date: Sun, 12 Sep 1999 21:10:47 -0400 (EDT) From: Garrett Wollman Message-Id: <199909130110.VAA27314@khavrinen.lcs.mit.edu> To: Dag-Erling Smorgrav Cc: nate@mt.sri.com (Nate Williams), Ben Smithurst , "Jeremy L. Ramirez" , dev-null@ns1.digicomsystems.net, freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info In-Reply-To: References: <4.2.0.58.19990911151659.00aa8d60@ns1.digicomsystems.net> <19990912012524.B41509@lithium.scientia.demon.co.uk> <199909121534.JAA18584@mt.sri.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN > + # NOTE: this breaks rfc1644 extensions (T/TCP) No, it breaks TCP, period, regardless of RFC 1644. Christmas-tree segments are perfectly valid in TCP (i.e., SYN URG PSH FIN). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 19:23:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 4608014C7F; Sun, 12 Sep 1999 19:23:17 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id TAA31984; Sun, 12 Sep 1999 19:22:29 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909130222.TAA31984@gndrsh.dnsmgr.net> Subject: Re: How to prevent motd including os info In-Reply-To: <199909130110.VAA27314@khavrinen.lcs.mit.edu> from Garrett Wollman at "Sep 12, 1999 09:10:47 pm" To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Sun, 12 Sep 1999 19:22:28 -0700 (PDT) Cc: des@flood.ping.uio.no (Dag-Erling Smorgrav), nate@mt.sri.com (Nate Williams), ben@scientia.demon.co.uk (Ben Smithurst), jramirez@digicomsystems.net (Jeremy L. Ramirez), dev-null@ns1.digicomsystems.net, freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > < said: > > > +tcp_drop_synfin="NO" # Set to YES to drop TCP packets with SYN+FIN > > + # NOTE: this breaks rfc1644 extensions (T/TCP) > > No, it breaks TCP, period, regardless of RFC 1644. Christmas-tree > segments are perfectly valid in TCP (i.e., SYN URG PSH FIN). Okay, are SYN * ^URG * ^PSH * FIN packets, another words packets with just the SYN and FIN bits set, but not the others used anyplace other than in T/TCP aka rfc1644? -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 12 20:21:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 92774154E9; Sun, 12 Sep 1999 20:21:21 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id XAA30870; Sun, 12 Sep 1999 23:19:14 -0400 (EDT) Date: Sun, 12 Sep 1999 23:19:13 -0400 (EDT) From: Bosko Milekic To: Stas Kisel Cc: avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) In-Reply-To: <199909091447.SAA24055@sonet.crimea.ua> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-750191660-937192753=:18795" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-750191660-937192753=:18795 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello (again), On Thu, 9 Sep 1999, Stas Kisel wrote: !>> From avalon@cheops.anu.edu.au Thu Sep 9 16:17:27 1999 !> !>> > Probably it is not self-evident why we HAVE to drop this connection. !>> !>> So what if someone manages to crash a program due to a DOS attack ? !>> An easy one that comes to mind is syslogd. It's often stuck in disk-wait !>> and can easily be targetted with a large number of packets. !> !>1. If ever syslog used (or will use) TCP, it should drop the connection !>which is logging data too quickly. !>OS shouldn't kill process, only drop connection. So no crash. !>More examples? !> !>2. udp_drain() may either drop all packets or intellectually select !>"offending" socket and try to avoid deletion of "right" packets and !>simplifying spoofing. RFC allows 1st way, but 2-nd can improve OS. !> !>3. Another idea. Apart from the *_drain() method. Probably I ever will !>try to implement it somedays (quite low probability, though). !>Set TCP window in a packets according to really available kernel !>memory. Available memory should be distributed non-uniformly !>between maximum number of sockets. So 1-st socket has window= !>=64k-still_not_read_data, and 1024-th has window=MIN_WINDOW- !>-still_not_read_data. !>MIN_WINDOW should be determined for max efficiency. About 2k. !>Distribution can not be linear - it isapproximately like min(NORM*1/x,64k). !>Exactly it can be determined via functional equation. Something like !>\integral_0^maxsockets{dist(x)dx}=kernel_memory and several !>conditions. (sorry for my poor TeX). !> !>In a case of attack new sockets will be created with a very small !>window - about 2k. !> !>Please blame me as much as possible - probably I have missed some significant !>detail. !>Probably all this math suxx and the best is a "stair" function - !>somebody already works on lowering TCP window, if I didn't mistaken. !> !> !>-- !>Stas Kisel. UNIX, security, C, TCP/IP, Web. UNIX - the best adventure game !>http://www.tekmetrics.com/transcript.shtml?pid=20053 http://www.crimea.edu !>+380(652)510222,230238 ; stas@crimea.edu stas@sonet.crimea.ua ; 2:460/54.4 !> These are all interesting ideas. However, when I initially posted regarding this, I was disappointed in seeing that we simply handle MGET()s, MGETHDR()s, and MCLALLOC()s by storing a null _even_ if we are M_WAIT. What basically ended up happening (and, the last time I checked, it's like this even in --CURRENT), is m_retry() -- or m_retryhdr() (this is in the case of no mbufs beings available) would simply panic(). I have produced patches (see attached -- they are seperated into two different patches, mbuf.patch which patches kern/uipc_mbuf.c and mbuf2.patch which patches sys/mbuf.h) that will basically tsleep() in the case of an M_WAIT and mbuf or mbuf cluster shortage. I wanted something that would make sure that we will get a non-NULL result when we called with M_WAIT. Obviously, this isn't the definite solution to the DoS problem that seemed to have become the main idea of discussion in this thread. However, I've kept that in mind, and I am now starting work (when time permits) on some code which will enable us to warn the network protocol module code that we're out of mbufs (or mbuf clusters) when the situation occurs. This way, if we can't get anything even with m_reclaim (which would be called from m_retry if we are M_WAIT), we could have the protocols figure out what to drop. I'm also aware of the possiblity of some people not liking the fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). Thus, I am open to modifying the diffs to add a counter and have the tsleep expire every once in a while so that finally, when the counter would expire, we would return a deffinate null _even_ if we are M_WAIT, but this can only be implemented if we make sure that ALL the MGET and company callers check for this (which would be annoying to do). Cheers, Bosko Milekic. --0-750191660-937192753=:18795 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mbuf.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mbuf.patch" LS0tIC91c3Ivc3JjL3N5cy9rZXJuLm9sZC91aXBjX21idWYuYwlXZWQgU2Vw ICA4IDIwOjQ1OjUwIDE5OTkNCisrKyAvdXNyL3NyYy9zeXMva2Vybi91aXBj X21idWYuYwlTdW4gU2VwIDEyIDIyOjQ0OjIzIDE5OTkNCkBAIC02MCw2ICs2 MCw4IEBADQogaW50CW1heF9oZHI7DQogaW50CW1heF9kYXRhbGVuOw0KIA0K K3N0YXRpYyBpbnQgbV9tYmFsbG9jX3dpZCA9IDAsIG1fY2xhbGxvY193aWQg PSAwOw0KKw0KIFNZU0NUTF9JTlQoX2tlcm5faXBjLCBLSVBDX01BWF9MSU5L SERSLCBtYXhfbGlua2hkciwgQ1RMRkxBR19SVywNCiAJICAgJm1heF9saW5r aGRyLCAwLCAiIik7DQogU1lTQ1RMX0lOVChfa2Vybl9pcGMsIEtJUENfTUFY X1BST1RPSERSLCBtYXhfcHJvdG9oZHIsIENUTEZMQUdfUlcsDQpAQCAtMTUz LDYgKzE1NSw1NyBAQA0KIAlyZXR1cm4gKDEpOw0KIH0NCiANCisvKg0KKyAq IEZ1bmN0aW9uIHVzZWQgZm9yIHdhaXRpbmcgb24gc29tZSBtYnVmIHRvIGJl IGZyZWVkIGFuZCwgdXBvbiB3YWtldXAsDQorICogdG8gZ28gZ2V0IHRoYXQg bWJ1ZiBhbmQgdXNlIGl0Lg0KKyAqLw0KK3N0cnVjdCBtYnVmICoNCittX21i YWxsb2Nfd2FpdChjYWxsZXIsIHR5cGUpDQorCWludCBjYWxsZXI7DQorCWlu dCB0eXBlOw0KK3sNCisJc3RydWN0IG1idWYgKnA7DQorDQorUmV0cnlGZXRj aDoNCisJLyogU2xlZXAgaGVyZSB1bnRpbCBzb21ldGhpbmcncyBhdmFpbGFi bGUuICovDQorCW1fbWJhbGxvY193aWQrKzsNCisJdHNsZWVwKCZtX21iYWxs b2Nfd2lkLCBQVk0sICJtYmFsbGMiLCAwKTsNCisJDQorCS8qDQorCSAqIE5v dyB0aGF0IHdlICh0aGluaykgdGhhdCB3ZSd2ZSBnb3Qgc29tZXRoaW5nLCB3 ZSB3aWxsIHJlZG8gYW4NCisJICogTUdFVCwgYnV0IGF2b2lkIGdldHRpbmcg aW50byBhbm90aGVyIGluc3RhbmNlIG9mIG1fbWJhbGxvY193YWl0KCkNCisJ ICogV2UgZG8gdGhpcyBieSBkZWZpbmluZyB0aGlzIGZ1bmN0aW9uIGFzIG51 bGwuDQorCSAqLw0KKyNkZWZpbmUgbV9tYmFsbG9jX3dhaXQoY2FsbGVyLHR5 cGUpIChzdHJ1Y3QgbWJ1ZiAqKTAgDQorCWlmIChjYWxsZXIgPT0gTUdFVF9D KSB7DQorCQlNR0VUKHAsTV9XQUlULHR5cGUpOw0KKwl9IGVsc2Ugew0KKwkJ TUdFVEhEUihwLE1fV0FJVCx0eXBlKTsNCisJfQ0KKyN1bmRlZiBtX21iYWxs b2Nfd2FpdA0KKyANCisJLyoNCisJICogSWYgd2UgZmFpbCB5ZXQgYWdhaW4s IGdvIGJhY2sgdG8gc2xlZXBpbmcuDQorCSAqIFhYWCBQZXJoYXBzIHdlIHNo b3VsZCBpbXBsZW1lbnQgYSBsaW1pdCBzb21ld2hlcmUgaGVyZS4gDQorCSAq Lw0KKwlpZiAocCA9PSBOVUxMKQ0KKwkJZ290byBSZXRyeUZldGNoOw0KKw0K KwlyZXR1cm4gKHApOw0KK30NCisNCisvKg0KKyAqIEZ1bmN0aW9uIHVzZWQg dG8gd2FrZXVwIHNsZWVwZXJzIHdhaXRpbmcgZm9yIG1idWZzLi4uDQorICov DQordm9pZA0KK21fbWJhbGxvY193YWtldXAodm9pZCkNCit7DQorCWlmICht X21iYWxsb2Nfd2lkKSB7DQorCQltX21iYWxsb2Nfd2lkID0gMDsNCisJCXdh a2V1cCgmbV9tYmFsbG9jX3dpZCk7DQorCX0NCit9DQorDQogI2lmIE1DTEJZ VEVTID4gUEFHRV9TSVpFDQogc3RhdGljIGludCBpX3dhbnRfbXlfbWNsOw0K IA0KQEAgLTI0Miw2ICsyOTUsNTMgQEANCiB9DQogDQogLyoNCisgKiBUaGlz IGZ1bmN0aW9uIHdpbGwgYmUgdXNlZCB0byBzbGVlcCBhbmQgd2FpdCB1bnRp bCB3ZSBoYXZlIGEgZnJlZQ0KKyAqIG1idWYgY2x1c3Rlci4gVGhpcyBpcyBm b3IgY2FsbGVycyB3aXRoIE1fV0FJVCB3aG8nZCBsaWtlIHRvIGF2b2lkDQor ICogcmV0dXJuaW5nIE5VTEwgYW5kIHRha2UgdGhlIGhlYXQsIHdhaXRpbmcg KHdoaWNoIGlzIGxvZ2ljYWxseSB3aGF0DQorICogc2hvdWxkIGhhcHBlbiBh bnl3YXkgd2l0aCBhbiBNX1dBSVQpLg0KKyAqLw0KK2NhZGRyX3QNCittX2Ns YWxsb2Nfd2FpdCh2b2lkKQ0KK3sNCisJY2FkZHJfdCBwOw0KKw0KK1JldHJ5 Q2x1c3Q6DQorCS8qIFNsZWVwIGhlcmUgdW50aWwgc29tZXRoaW5nJ3MgYXZh aWxhYmxlLiAqLw0KKwltX2NsYWxsb2Nfd2lkKys7DQorCXRzbGVlcCgmbV9j bGFsbG9jX3dpZCwgUFZNLCAibWNsYWxjIiwgMCk7DQorDQorCS8qDQorCSAq IE5vdyB0aGF0IHdlICh0aGluaykgdGhhdCB3ZSd2ZSBnb3Qgc29tZXRoaW5n LCB3ZSB3aWxsIHJlZG8gYW5kDQorCSAqIE1HRVQsIGJ1dCBhdm9pZCBnZXR0 aW5nIGludG8gYW5vdGhlciBpbnN0YW5jZSBvZiBtX2NsYWxsb2Nfd2FpdCgp DQorCSAqIFdlIGRvIHRoaXMgYnkgZGVmaW5pbmcgdGhpcyBmdW5jdGlvbiBh cyBudWxsLg0KKwkgKi8NCisjZGVmaW5lIG1fY2xhbGxvY193YWl0KCkgKGNh ZGRyX3QpMA0KKwlNQ0xBTExPQyhwLE1fV0FJVCk7DQorI3VuZGVmIG1fY2xh bGxvY193YWl0DQorDQorCS8qDQorCSAqIElmIHdlIGZhaWwgeWV0IGFnYWlu LCBnbyBiYWNrIHRvIHNsZWVwaW5nLg0KKwkgKiBYWFggUGVyaGFwcyB3ZSBz aG91bGQgaW1wbGVtZW50IGEgbGltaXQgc29tZXdoZXJlIGhlcmUuDQorCSAq Lw0KKwlpZiAocCA9PSBOVUxMKQ0KKwkJZ290byBSZXRyeUNsdXN0Ow0KKw0K KwlyZXR1cm4gKHApOw0KK30NCisNCisvKg0KKyAqIEZ1bmN0aW9uIHVzZWQg dG8gd2FrZXVwIHNsZWVwZXJzIHdhaXRpbmcgZm9yIG1idWYgY2x1c3RlcnMu Li4NCisgKi8NCit2b2lkDQorbV9jbGFsbG9jX3dha2V1cCh2b2lkKQ0KK3sN CisJaWYgKG1fY2xhbGxvY193aWQpIHsNCisJCW1fY2xhbGxvY193aWQgPSAw Ow0KKwkJd2FrZXVwKCZtX2NsYWxsb2Nfd2lkKTsNCisJfQ0KK30NCisNCisv Kg0KICAqIFdoZW4gTUdFVCBmYWlscywgYXNrIHByb3RvY29scyB0byBmcmVl IHNwYWNlIHdoZW4gc2hvcnQgb2YgbWVtb3J5LA0KICAqIHRoZW4gcmUtYXR0 ZW1wdCB0byBhbGxvY2F0ZSBhbiBtYnVmLg0KICAqLw0KQEAgLTI2MSwxMiAr MzYxLDkgQEANCiAjdW5kZWYgbV9yZXRyeQ0KIAlpZiAobSAhPSBOVUxMKSB7 DQogCQltYnN0YXQubV93YWl0Kys7DQotCX0gZWxzZSB7DQotCQlpZiAoaSA9 PSBNX0RPTlRXQUlUKQ0KLQkJCW1ic3RhdC5tX2Ryb3BzKys7DQotCQllbHNl DQotCQkJcGFuaWMoIk91dCBvZiBtYnVmIGNsdXN0ZXJzIik7DQotCX0NCisJ fSBlbHNlIA0KKwkJbWJzdGF0Lm1fZHJvcHMrKzsNCisNCiAJcmV0dXJuICht KTsNCiB9DQogDQpAQCAtMjg5LDEyICszODYsOSBAQA0KICN1bmRlZiBtX3Jl dHJ5aGRyDQogCWlmIChtICE9IE5VTEwpIHsNCiAJCW1ic3RhdC5tX3dhaXQr KzsNCi0JfSBlbHNlIHsNCi0JCWlmIChpID09IE1fRE9OVFdBSVQpDQotCQkJ bWJzdGF0Lm1fZHJvcHMrKzsNCi0JCWVsc2UNCi0JCQlwYW5pYygiT3V0IG9m IG1idWYgY2x1c3RlcnMiKTsNCi0JfQ0KKwl9IGVsc2UgDQorCQltYnN0YXQu bV9kcm9wcysrOw0KKw0KIAlyZXR1cm4gKG0pOw0KIH0NCiANCg== --0-750191660-937192753=:18795 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mbuf2.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mbuf2.patch" LS0tIC91c3Ivc3JjL3N5cy9zeXMub2xkL21idWYuaAkJU2F0IFNlcCAxMSAx OToxMDo0NCAxOTk5DQorKysgL3Vzci9zcmMvc3lzL3N5cy9tYnVmLmgJCVN1 biBTZXAgMTIgMjI6NDQ6NDQgMTk5OQ0KQEAgLTE1Myw2ICsxNTMsMTMgQEAN CiAjZGVmaW5lCU1fRE9OVFdBSVQJMQ0KICNkZWZpbmUJTV9XQUlUCQkwDQog DQorLyogDQorICogRmxhZ3MgdG8gcGFzcyB0byB0aGUgKl93YWl0IGZ1bmN0 aW9ucyAod2hlbiB3ZSBoYXZlIHRvIHdhaXQgZm9yIGFuDQorICogbWJ1ZiB0 byBiZSBmcmVlZCkuDQorICovDQorI2RlZmluZSBNR0VUX0MJCTENCisjZGVm aW5lIE1HRVRIRFJfQwkyDQorDQogLyogRnJlZWxpc3RzOg0KICAqDQogICog Tm9ybWFsIG1idWYgY2x1c3RlcnMgYXJlIG5vcm1hbGx5IHRyZWF0ZWQgYXMg Y2hhcmFjdGVyIGFycmF5cw0KQEAgLTIwMyw3ICsyMTAsOCBAQA0KIAkJc3Bs eChfbXMpOyBcDQogCX0gZWxzZSB7IFwNCiAJCXNwbHgoX21zKTsgXA0KLQkJ KG0pID0gbV9yZXRyeSgoaG93KSwgKHR5cGUpKTsgXA0KKwkJaWYgKCgobSk9 bV9yZXRyeSgoaG93KSwgKHR5cGUpKSk9PU5VTEwgJiYgKGhvdyk9PU1fV0FJ VCkgXA0KKwkJCShtKSA9IG1fbWJhbGxvY193YWl0KE1HRVRfQywodHlwZSkp OyBcDQogCX0gXA0KIH0NCiANCkBAIC0yMjMsNyArMjMxLDggQEANCiAJCXNw bHgoX21zKTsgXA0KIAl9IGVsc2UgeyBcDQogCQlzcGx4KF9tcyk7IFwNCi0J CShtKSA9IG1fcmV0cnloZHIoKGhvdyksICh0eXBlKSk7IFwNCisJCWlmICgo KG0pPW1fcmV0cnloZHIoKGhvdyksKHR5cGUpKSk9PU5VTEwgJiYgKGhvdyk9 PU1fV0FJVCkgXA0KKwkJCShtKSA9IG1fbWJhbGxvY193YWl0KE1HRVRIRFJf QywodHlwZSkpOyBcDQogCX0gXA0KIH0NCiANCkBAIC0yMzUsMTYgKzI0NCwy MCBAQA0KICAqIE1DTEZSRUUgcmVsZWFzZXMgYSByZWZlcmVuY2UgdG8gYSBj bHVzdGVyIGFsbG9jYXRlZCBieSBNQ0xBTExPQywNCiAgKiBmcmVlaW5nIHRo ZSBjbHVzdGVyIGlmIHRoZSByZWZlcmVuY2UgY291bnQgaGFzIHJlYWNoZWQg MC4NCiAgKi8NCi0jZGVmaW5lCU1DTEFMTE9DKHAsIGhvdykgXA0KLQlNQlVG TE9DSyggXA0KLQkgIGlmIChtY2xmcmVlID09IDApIFwNCisjZGVmaW5lCU1D TEFMTE9DKHAsIGhvdykgeyBcDQorCWludCBfbXMgPSBzcGxpbXAoKTsgXA0K KwlpZiAobWNsZnJlZSA9PSAwKSBcDQogCQkodm9pZCltX2NsYWxsb2MoMSwg KGhvdykpOyBcDQotCSAgaWYgKCgocCkgPSAoY2FkZHJfdCltY2xmcmVlKSAh PSAwKSB7IFwNCisJaWYgKCgocCkgPSAoY2FkZHJfdCltY2xmcmVlKSAhPSAw KSB7IFwNCiAJCSsrbWNscmVmY250W210b2NsKHApXTsgXA0KIAkJbWJzdGF0 Lm1fY2xmcmVlLS07IFwNCiAJCW1jbGZyZWUgPSAoKHVuaW9uIG1jbHVzdGVy ICopKHApKS0+bWNsX25leHQ7IFwNCi0JICB9IFwNCi0JKQ0KKwkJc3BseChf bXMpOyBcDQorIAl9IGVsc2UgaWYgKChob3cpID09IE1fV0FJVCkgeyBcDQor CQlzcGx4KF9tcyk7IFwNCisJCShwKSA9IG1fY2xhbGxvY193YWl0KCk7IFwN CisJfSBcDQorfQ0KIA0KICNkZWZpbmUJTUNMR0VUKG0sIGhvdykgXA0KIAl7 IE1DTEFMTE9DKChtKS0+bV9leHQuZXh0X2J1ZiwgKGhvdykpOyBcDQpAQCAt MjYzLDYgKzI3Niw3IEBADQogCQkoKHVuaW9uIG1jbHVzdGVyICopKHApKS0+ bWNsX25leHQgPSBtY2xmcmVlOyBcDQogCQltY2xmcmVlID0gKHVuaW9uIG1j bHVzdGVyICopKHApOyBcDQogCQltYnN0YXQubV9jbGZyZWUrKzsgXA0KKwkJ KHZvaWQpbV9jbGFsbG9jX3dha2V1cCgpOyBcDQogCSAgfSBcDQogCSkNCiAN CkBAIC0yODQsNiArMjk4LDcgQEANCiAJCQkJKCh1bmlvbiBtY2x1c3RlciAq KShwKSktPm1jbF9uZXh0ID0gbWNsZnJlZTsgXA0KIAkJCQltY2xmcmVlID0g KHVuaW9uIG1jbHVzdGVyICopKHApOyBcDQogCQkJCW1ic3RhdC5tX2NsZnJl ZSsrOyBcDQorCQkJCSh2b2lkKW1fY2xhbGxvY193YWtldXAoKTsgXA0KIAkJ CX0gXA0KIAkJfSBcDQogCSAgfSBcDQpAQCAtMjkyLDYgKzMwNyw3IEBADQog CSAgbWJzdGF0Lm1fbXR5cGVzW01UX0ZSRUVdKys7IFwNCiAJICAobSktPm1f bmV4dCA9IG1tYmZyZWU7IFwNCiAJICBtbWJmcmVlID0gKG0pOyBcDQorCSAg KHZvaWQpbV9tYmFsbG9jX3dha2V1cCgpOyBcDQogCSkNCiANCiAvKg0KQEAg LTQwOCwxNiArNDI0LDIwIEBADQogc3RydWN0CW1idWYgKm1fZ2V0aGRyIF9f UCgoaW50LCBpbnQpKTsNCiBzdHJ1Y3QJbWJ1ZiAqbV9wcmVwZW5kIF9fUCgo c3RydWN0IG1idWYgKixpbnQsaW50KSk7DQogc3RydWN0CW1idWYgKm1fcHVs bHVwIF9fUCgoc3RydWN0IG1idWYgKiwgaW50KSk7DQorc3RydWN0CW1idWYg Km1fbWJhbGxvY193YWl0IF9fUCgoaW50LGludCkpOw0KIHN0cnVjdAltYnVm ICptX3JldHJ5IF9fUCgoaW50LCBpbnQpKTsNCiBzdHJ1Y3QJbWJ1ZiAqbV9y ZXRyeWhkciBfX1AoKGludCwgaW50KSk7DQogc3RydWN0CW1idWYgKm1fc3Bs aXQgX19QKChzdHJ1Y3QgbWJ1ZiAqLGludCxpbnQpKTsNCiB2b2lkCW1fYWRq IF9fUCgoc3RydWN0IG1idWYgKiwgaW50KSk7DQogdm9pZAltX2NhdCBfX1Ao KHN0cnVjdCBtYnVmICosc3RydWN0IG1idWYgKikpOw0KK3ZvaWQJbV9tYmFs bG9jX3dha2V1cCBfX1AoKHZvaWQpKTsNCit2b2lkCW1fY2xhbGxvY193YWtl dXAgX19QKCh2b2lkKSk7DQogaW50CW1fbWJhbGxvYyBfX1AoKGludCwgaW50 KSk7DQogaW50CW1fY2xhbGxvYyBfX1AoKGludCwgaW50KSk7DQogdm9pZAlt X2NvcHliYWNrIF9fUCgoc3RydWN0IG1idWYgKiwgaW50LCBpbnQsIGNhZGRy X3QpKTsNCiB2b2lkCW1fY29weWRhdGEgX19QKChzdHJ1Y3QgbWJ1ZiAqLGlu dCxpbnQsY2FkZHJfdCkpOw0KIHZvaWQJbV9mcmVlbSBfX1AoKHN0cnVjdCBt YnVmICopKTsNCitjYWRkcl90CW1fY2xhbGxvY193YWl0IF9fUCgodm9pZCkp Ow0KICNlbmRpZiAvKiBLRVJORUwgKi8NCiANCiAjZW5kaWYgLyogIV9TWVNf TUJVRl9IXyAqLw0K --0-750191660-937192753=:18795-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 13 0:38:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail-gw6.pacbell.net (mail-gw6.pacbell.net [206.13.28.41]) by hub.freebsd.org (Postfix) with ESMTP id 5A86D14FD6 for ; Mon, 13 Sep 1999 00:38:47 -0700 (PDT) (envelope-from madscientist@thegrid.net) Received: from remus (adsl-63-193-246-169.dsl.snfc21.pacbell.net [63.193.246.169]) by mail-gw6.pacbell.net (8.9.3/8.9.3) with SMTP id AAA27850 for ; Mon, 13 Sep 1999 00:38:46 -0700 (PDT) Message-Id: <4.1.19990913003757.0096b660@mail.thegrid.net> X-Sender: i289861@mail.thegrid.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 13 Sep 1999 00:38:35 -0700 To: freebsd-security@freebsd.org From: The Mad Scientist Subject: Re: How to prevent motd including os info Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If someone can get a shell on your machine, it should be trivial to determine (at the very least) that the machine is running a bsd OS. (existance of /usr/ucb, flags to ps, etc) You'd need to take care of uname, dmesg, and so on. It's better to spend your time fixing real security holes. -Dean At 01:13 PM 9/12/99 -0400, you wrote: >Is there a way to suppress the copyright info? This is pretty much >a dead giveaway (At least that it's *BSD), huh? See lines 14-15 below: > >$ telnet dmaddox.conterra.com >Trying 127.0.0.1... >Connected to localhost. >Escape character is '^]'. > >dmaddox.conterra.com >Access Restricted > >Today is Sun Sep 12 13:09:57 EDT 1999 > >login: myself >Password: >Last login: Sun Sep 12 13:07:17 from localhost >Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 > The Regents of the University of California. All rights reserved. > >Welcome to BogoDOS! >You have mail. >$ > > >On Sun, Sep 12, 1999 at 12:56:39PM -0400, Hector Colmenares wrote: >> >> >> If you dont want people to know what OS are you running >> when they telnet into your box just change to this the info in >> /etc/gettytab >> >> default:\ >> :cb:ce:ck:lc:fd#1000:im=\r\n\%h\r\nAccess Restricted\ >> r\n\r\nFor info, email admin@%h\r\nToday is %d\r\n\r\n >> >> >> ;-) >> >> cheers !! >> >> On Sun, 12 Sep 1999, Will Andrews wrote: >> >> > >> > On 12-Sep-99 Ben Smithurst wrote: >> > > Jeremy L. Ramirez wrote: >> > > >> > >> telnet stream tcp nowait root /usr/libexec/telnetd >telnetd -h >> > >> >> > >> what you are doing is adding the -h at the end of the line which >prevents >> > >> a user from seeing the OS before even logging in. >> > > >> > > An even better way is to disable telnet completely, and use ssh like you >> > > should. Note that people can still use nmap or something to guess at >> > > your OS. >> > > >> > > -- >> > > Ben Smithurst | PGP: 0x99392F7D >> > > ben@scientia.demon.co.uk | key available from keyservers and >> > > | ben+pgp@scientia.demon.co.uk >> > > >> > > >> > > To Unsubscribe: send mail to majordomo@FreeBSD.org >> > > with "unsubscribe freebsd-security" in the body of the message >> > >> > >> > To Unsubscribe: send mail to majordomo@FreeBSD.org >> > with "unsubscribe freebsd-questions" in the body of the message >> > >> >> >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-questions" in the body of the message >> > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 13 11:42:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id F338A14FD5; Mon, 13 Sep 1999 11:42:23 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA31048; Mon, 13 Sep 1999 14:40:53 -0400 (EDT) (envelope-from wollman) Date: Mon, 13 Sep 1999 14:40:53 -0400 (EDT) From: Garrett Wollman Message-Id: <199909131840.OAA31048@khavrinen.lcs.mit.edu> To: Bosko Milekic Cc: Stas Kisel , avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) In-Reply-To: References: <199909091447.SAA24055@sonet.crimea.ua> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > Send mail to mime@docserver.cac.washington.edu for more info. It would be preferable if text were sent as text, since MIME-encoded patches require more effort to read. > I'm also aware of the possiblity of some people not liking the > fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). I don't have any problem with sleeping forever -- but I am concerned about the possibility of deadlock, especially when client-NFS is involved. If the problem just moves around and has harder-to-recover symptoms, the change isn't helping. The 4.3BSD code had two different behaviors: - For clusters, if M_WAIT was specified and there was no space left in mb_map, it panicked. However, m_clalloc was never called with M_WAIT, so that panic was effectively dead code. - For mbufs, if M_WAIT was specified and there were no mbufs available, it would sleep at PZERO - 1 (which was interruptible). In 4.3, the code was able to deal with cluster allocation failing. We have a somewhat different situation now, because many network interface devices have less-flexible DMA mechanisms which don't allow packet reception into non-contiguous buffers, so we need to have at least a certain number of clusters available for this purpose. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 13 12:13:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1EE73155AD for ; Mon, 13 Sep 1999 12:13:12 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA31264; Mon, 13 Sep 1999 15:12:58 -0400 (EDT) (envelope-from wollman) Date: Mon, 13 Sep 1999 15:12:58 -0400 (EDT) From: Garrett Wollman Message-Id: <199909131912.PAA31264@khavrinen.lcs.mit.edu> To: "Rodney W. Grimes" Cc: freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info In-Reply-To: <199909130222.TAA31984@gndrsh.dnsmgr.net> References: <199909130110.VAA27314@khavrinen.lcs.mit.edu> <199909130222.TAA31984@gndrsh.dnsmgr.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Cc's massively snipped.] < said: > Okay, are SYN * ^URG * ^PSH * FIN packets, another words packets with > just the SYN and FIN bits set, but not the others used anyplace other > than in T/TCP aka rfc1644? The finger client used to do this, before it was pointed out to me that the finger specification does not allow it. fetch also tries to do it (or at least tried; I haven't paid attention to the changes in fetch recently). I don't think the TCP in -current will generate such segments, although it will process them correctly. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 13 14:35:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from hawaii.conterra.com (hawaii.conterra.com [209.12.164.32]) by hub.freebsd.org (Postfix) with ESMTP id 4A82414C0C for ; Mon, 13 Sep 1999 14:35:34 -0700 (PDT) (envelope-from myself@conterra.com) Received: from dmaddox.conterra.com (root@dmaddox.conterra.com [209.12.169.48]) by hawaii.conterra.com (8.9.3/8.9.3) with ESMTP id RAA02315; Mon, 13 Sep 1999 17:35:28 -0400 (EDT) Received: (from myself@localhost) by dmaddox.conterra.com (8.9.3/8.9.1) id RAA01489; Mon, 13 Sep 1999 17:35:32 -0400 (EDT) (envelope-from myself) Date: Mon, 13 Sep 1999 17:35:32 -0400 From: "Donald J . Maddox" To: The Mad Scientist Cc: freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info Message-ID: <19990913173532.A842@dmaddox.conterra.com> Reply-To: dmaddox@conterra.com References: <4.1.19990913003757.0096b660@mail.thegrid.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <4.1.19990913003757.0096b660@mail.thegrid.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bzzzt! The correct answer is in /etc/login.conf, of course. You assume a lot. How do you know I don't have the user in a jail that doesn't even remotely resemble a *BSD system (even though it actually is within one)? On Mon, Sep 13, 1999 at 12:38:35AM -0700, The Mad Scientist wrote: > If someone can get a shell on your machine, it should be trivial to > determine (at the very least) that the machine is running a bsd OS. > (existance of /usr/ucb, flags to ps, etc) You'd need to take care of > uname, dmesg, and so on. It's better to spend your time fixing real > security holes. > -Dean > At 01:13 PM 9/12/99 -0400, you wrote: > >Is there a way to suppress the copyright info? This is pretty much > >a dead giveaway (At least that it's *BSD), huh? See lines 14-15 below: > > > >$ telnet dmaddox.conterra.com > >Trying 127.0.0.1... > >Connected to localhost. > >Escape character is '^]'. > > > >dmaddox.conterra.com > >Access Restricted > > > >Today is Sun Sep 12 13:09:57 EDT 1999 > > > >login: myself > >Password: > >Last login: Sun Sep 12 13:07:17 from localhost > >Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > > >Welcome to BogoDOS! > >You have mail. > >$ > > > > > >On Sun, Sep 12, 1999 at 12:56:39PM -0400, Hector Colmenares wrote: > >> > >> > >> If you dont want people to know what OS are you running > >> when they telnet into your box just change to this the info in > >> /etc/gettytab > >> > >> default:\ > >> :cb:ce:ck:lc:fd#1000:im=\r\n\%h\r\nAccess Restricted\ > >> r\n\r\nFor info, email admin@%h\r\nToday is %d\r\n\r\n > >> > >> > >> ;-) > >> > >> cheers !! > >> > >> On Sun, 12 Sep 1999, Will Andrews wrote: > >> > >> > > >> > On 12-Sep-99 Ben Smithurst wrote: > >> > > Jeremy L. Ramirez wrote: > >> > > > >> > >> telnet stream tcp nowait root /usr/libexec/telnetd > >telnetd -h > >> > >> > >> > >> what you are doing is adding the -h at the end of the line which > >prevents > >> > >> a user from seeing the OS before even logging in. > >> > > > >> > > An even better way is to disable telnet completely, and use ssh like > you > >> > > should. Note that people can still use nmap or something to guess at > >> > > your OS. > >> > > > >> > > -- > >> > > Ben Smithurst | PGP: 0x99392F7D > >> > > ben@scientia.demon.co.uk | key available from keyservers and > >> > > | ben+pgp@scientia.demon.co.uk > >> > > > >> > > > >> > > To Unsubscribe: send mail to majordomo@FreeBSD.org > >> > > with "unsubscribe freebsd-security" in the body of the message > >> > > >> > > >> > To Unsubscribe: send mail to majordomo@FreeBSD.org > >> > with "unsubscribe freebsd-questions" in the body of the message > >> > > >> > >> > >> > >> To Unsubscribe: send mail to majordomo@FreeBSD.org > >> with "unsubscribe freebsd-questions" in the body of the message > >> > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-security" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 13 17: 3: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 5246C14F45; Mon, 13 Sep 1999 17:02:55 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id UAA04903; Mon, 13 Sep 1999 20:02:52 -0400 (EDT) Date: Mon, 13 Sep 1999 20:02:50 -0400 (EDT) From: Bosko Milekic To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) In-Reply-To: <199909130336.UAA20252@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org !> I think that what needs to be done is to split the problem in two. First, !> allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT !> is used, it simply means 'try harder, sleeping a bit if necessary'. This !> requires ensuring that all the networking code deal with the failure !> case - a time consuming but straightforward task. If a failure occurs, !> one simply drops the packet, not the connection or anything else drastic. !> just the packet. Yes, these is mainly the part I've been working on recently. The sleeping and what not (as I'm sure you've seen from the patches if you looked at them) has already been completed. Adding a counter that will expire and return a pre-defined error is trivial, in this case. The only real issue here (if we can call it that) is get _all_ the networking code to recognize this. Anyone want to help? :-) !> !> The second problem that needs to be addressed is resource exhaustion. !> For example, allocating thousands of connections and socket-opting their !> buffers as large as possible, or programs such as syslog accepting new !> connections ad-infinitum. This is a harder problem to fix properly, !> but a lot of the various issues such as those with syslog can be dealt !> with in userland rather then the kernel. !> !> -Matt !> I agree. The issue here is somewhat related (if I understand your explanation correctly) to [local] processes attempting to grab a lot of socket buffer space. I was a little less concerned with this issue since, as I previously mentionned, Brian Feldman is working on limiting socket buffer space. Nonetheless, if we do not consider limiting, here's what I believe will need to be done: As explained above, when we run out of mbufs and/or mbuf clusters (and some are needed), if we are M_WAIT (when processes socket opt their buffers as large as possible, the call is usually with M_WAIT), we will end up tsleep()ing for certain periods of time, until our counter expires and we return our pre-defined error (as mentionned above). When we do return this error, however, the caller (for instance, we can consider sosend() the caller -- which, if I remember correctly, is one of the callers to MGET() when we setsockopt a large buffer and consequently write() to this socket), will also have to know how to properly deal with this error (e.g.: kill the process?). Killing the process may seem somewhat sadistic to some ( :-) ), but remember that if we do get to the point where 'normal' local processes eat up so much buffer space that we run out, we should probably be increasing NMBCLUSTERS and/or maxusers anyway. As for script weenies, I hope that Brian (and whomever else may be working on it) gets that sockbuf limiting code done, because, to be quite honest, I don't think that script kids having to comprimise more than one account just so they can DoS a box will be much of an issue (if worse comes to worse, we can limit per gid -as opposed to per uid). With exhaustion attacks such as these, we're better off just limiting. Regards, Bosko Milekic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 13 17:19:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id E582214CAA for ; Mon, 13 Sep 1999 17:19:21 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id TAA20696; Mon, 13 Sep 1999 19:19:18 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from dial-31.tnt1.rac.cyberlynk.net(209.224.182.31) by peak.mountin.net via smap (V1.3) id sma020691; Mon Sep 13 19:19:06 1999 Message-Id: <3.0.3.32.19990913191825.00ad66f0@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 13 Sep 1999 19:18:25 -0500 To: dmaddox@conterra.com From: "Jeffrey J. Mountin" Subject: Re: How to prevent motd including os info Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <19990913173532.A842@dmaddox.conterra.com> References: <4.1.19990913003757.0096b660@mail.thegrid.net> <4.1.19990913003757.0096b660@mail.thegrid.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 05:35 PM 9/13/99 -0400, Donald J . Maddox wrote: >Bzzzt! The correct answer is in /etc/login.conf, of course. > >You assume a lot. How do you know I don't have the user in a jail >that doesn't even remotely resemble a *BSD system (even though it >actually is within one)? Ding! Ding! Ding! Give the man a prize... For a colossal waste time. Don't care to get into what would be required to remove all traces of FreeBSD in all files and good luck doing so. Scramble away and lock me up... Won't help much if 'strings' is around and if it isn't... Still no problem. 8-) Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 13 17:19:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 566A515251; Mon, 13 Sep 1999 17:19:46 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id UAA12720; Mon, 13 Sep 1999 20:19:44 -0400 (EDT) Date: Mon, 13 Sep 1999 20:19:44 -0400 (EDT) From: Bosko Milekic To: Garrett Wollman Cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) In-Reply-To: <199909131840.OAA31048@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 13 Sep 1999, Garrett Wollman wrote: !>< said: !> !>> This message is in MIME format. The first part should be readable text, !>> while the remaining parts are likely unreadable without MIME-aware tools. !>> Send mail to mime@docserver.cac.washington.edu for more info. !> !>It would be preferable if text were sent as text, since MIME-encoded !>patches require more effort to read. !> I deffinately agree. This is obviously my mistake, and I was somewhat in a rush, very lagged (modem, eurgh), using pine, and made several [dumb] typos in the 'Attatchement' field. !>> I'm also aware of the possiblity of some people not liking the !>> fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). !> !> !>I don't have any problem with sleeping forever -- but I am concerned !>about the possibility of deadlock, especially when client-NFS is !>involved. If the problem just moves around and has harder-to-recover !>symptoms, the change isn't helping. Well, the main purpose of the code is to basically sleep until something is freed after we've already exhausted the mb_map arena (as I'm sure you've seen if you were able to grab the attachements). This is really a-la-limite stuff. In other words, if 'normal' local programs are having trouble because of mb_map exhaustion, then maxusers && nmbclusters would have to be augmented. !> !>The 4.3BSD code had two different behaviors: !> !> - For clusters, if M_WAIT was specified and there was no space !>left in mb_map, it panicked. However, m_clalloc was never called with !>M_WAIT, so that panic was effectively dead code. Hmmm. If m_clalloc was never called with M_WAIT, then all the code calling m_clalloc deffinately checked its return value. It probably had specific ways to deal with m_clalloc returning failures, too? !> !> - For mbufs, if M_WAIT was specified and there were no mbufs !>available, it would sleep at PZERO - 1 (which was interruptible). !> !>In 4.3, the code was able to deal with cluster allocation failing. We !>have a somewhat different situation now, because many network !>interface devices have less-flexible DMA mechanisms which don't allow !>packet reception into non-contiguous buffers, so we need to have at !>least a certain number of clusters available for this purpose. Exactly. This is the next challenge. As for things being interruptable, as I mentionned to a reply to Matt Dillon just a few seconds ago, getting the tsleep to occasionally expire is trivial. As you say above, it's dealing with the failure that is the issue. !> !>-GAWollman !> !>-- !>Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same !>wollman@lcs.mit.edu | O Siem / The fires of freedom !>Opinions not those of| Dance in the burning flame !>MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick !> Cheers, Bosko Milekic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 13 18: 5:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from hawaii.conterra.com (hawaii.conterra.com [209.12.164.32]) by hub.freebsd.org (Postfix) with ESMTP id D2E9E155AD for ; Mon, 13 Sep 1999 18:05:13 -0700 (PDT) (envelope-from myself@conterra.com) Received: from dmaddox.conterra.com (root@dmaddox.conterra.com [209.12.169.48]) by hawaii.conterra.com (8.9.3/8.9.3) with ESMTP id VAA11426; Mon, 13 Sep 1999 21:05:11 -0400 (EDT) Received: (from myself@localhost) by dmaddox.conterra.com (8.9.3/8.9.1) id VAA03447; Mon, 13 Sep 1999 21:05:13 -0400 (EDT) (envelope-from myself) Date: Mon, 13 Sep 1999 21:05:13 -0400 From: "Donald J . Maddox" To: "Jeffrey J. Mountin" Cc: dmaddox@conterra.com, freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info Message-ID: <19990913210513.A3167@dmaddox.conterra.com> Reply-To: dmaddox@conterra.com References: <4.1.19990913003757.0096b660@mail.thegrid.net> <4.1.19990913003757.0096b660@mail.thegrid.net> <19990913173532.A842@dmaddox.conterra.com> <3.0.3.32.19990913191825.00ad66f0@207.227.119.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <3.0.3.32.19990913191825.00ad66f0@207.227.119.2> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Sep 13, 1999 at 07:18:25PM -0500, Jeffrey J. Mountin wrote: > At 05:35 PM 9/13/99 -0400, Donald J . Maddox wrote: > >Bzzzt! The correct answer is in /etc/login.conf, of course. > > > >You assume a lot. How do you know I don't have the user in a jail > >that doesn't even remotely resemble a *BSD system (even though it > >actually is within one)? > > Ding! Ding! Ding! Give the man a prize... > > For a colossal waste time. Don't care to get into what would be required > to remove all traces of FreeBSD in all files and good luck doing so. > > > Scramble away and lock me up... > > Won't help much if 'strings' is around and if it isn't... > > Still no problem. 8-) Sigh. This point is not worth all this discussion, but _again_... There may not be ANYTHING *BSD in the jail environment, let alone 'strings'. Again, assumptions. The point of my original question was just to find out how NOT to make the OS flavor readily apparent. That there are good reasons for doing so is not a point I am going to debate. We've all seen the 'security through obscurity' debates rehashed on these lists MANY times. Let's not do it again. > > > Jeff Mountin - jeff@mountin.net > Systems/Network Administrator > FreeBSD - the power to serve > '86 Yamaha MaxiumX (not FBSD powered) > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 14 0:52:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from sonet.crimea.ua (OTC-sl3-FLY.CRIS.NET [212.110.136.71]) by hub.freebsd.org (Postfix) with ESMTP id 980F614F91; Tue, 14 Sep 1999 00:52:02 -0700 (PDT) (envelope-from stas@sonet.crimea.ua) Received: (from stas@localhost) by sonet.crimea.ua (8.8.8/8.8.8) id KAA08988; Tue, 14 Sep 1999 10:50:43 +0400 (MSD) (envelope-from stas) Date: Tue, 14 Sep 1999 10:50:43 +0400 (MSD) From: Stas Kisel Message-Id: <199909140650.KAA08988@sonet.crimea.ua> To: bmilekic@dsuper.net, wollman@khavrinen.lcs.mit.edu Subject: Re: mbuf shortage situations (followup) Cc: avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG, stas@sonet.crimea.ua In-Reply-To: <199909131840.OAA31048@khavrinen.lcs.mit.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From wollman@khavrinen.lcs.mit.edu Mon Sep 13 22:39:37 1999 > > I'm also aware of the possiblity of some people not liking the > > fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). > > I don't have any problem with sleeping forever -- but I am concerned > about the possibility of deadlock, especially when client-NFS is > involved. If the problem just moves around and has harder-to-recover > symptoms, the change isn't helping. IMHO merely sleeping can't help if we deal with a DoS. Instead of sleeping, kernel should find out where all kernel memory is wasted and free some memory (and, probably, remove/log reason). And, partially, this mechanism is already implemented in ip_drain() and tp_drain(). -- Stas Kisel. UNIX, security, C, TCP/IP, Web. UNIX - the best adventure game http://www.tekmetrics.com/transcript.shtml?pid=20053 http://www.crimea.edu +380(652)510222,230238 ; stas@crimea.edu stas@sonet.crimea.ua ; 2:460/54.4 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 14 1:30:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id ACC6C151FF for ; Tue, 14 Sep 1999 01:30:38 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id DAA22842; Tue, 14 Sep 1999 03:30:37 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from dial-66.tnt1.rac.cyberlynk.net(209.224.182.66) by peak.mountin.net via smap (V1.3) id sma022838; Tue Sep 14 03:30:30 1999 Message-Id: <3.0.3.32.19990914032951.00843540@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 14 Sep 1999 03:29:51 -0500 To: dmaddox@conterra.com From: "Jeffrey J. Mountin" Subject: Re: How to prevent motd including os info Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <19990913210513.A3167@dmaddox.conterra.com> References: <3.0.3.32.19990913191825.00ad66f0@207.227.119.2> <4.1.19990913003757.0096b660@mail.thegrid.net> <4.1.19990913003757.0096b660@mail.thegrid.net> <19990913173532.A842@dmaddox.conterra.com> <3.0.3.32.19990913191825.00ad66f0@207.227.119.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:05 PM 9/13/99 -0400, Donald J . Maddox wrote: >Sigh. This point is not worth all this discussion, but _again_... Which point? Or are you referring to the STO policy. >There may not be ANYTHING *BSD in the jail environment, let alone >'strings'. Again, assumptions. Import or export for analysis. >The point of my original question was just to find out how NOT to >make the OS flavor readily apparent. That there are good reasons >for doing so is not a point I am going to debate. We've all seen >the 'security through obscurity' debates rehashed on these lists >MANY times. Let's not do it again. I only mentioned STO once and agree on leaving *that* horse dead. Still doesn't mean partisanship to either side of the arguement. Many good ideas. Since you left a few holes in your "suggestion," it seemed worth taking a couple shots at immediate holes that come to mind. Based on assumptions, truely, but your suggestion doesn't have much substance either. Didn't care to defend your idea either or add sugestions based on what I percieve you to be doing. All too easy to "cripple" a shell account to uselessness and I've never seen any discussion on the list about such a method to "secure" a system. Could suggest that if a jail is unbreakable, then why... That would be STO, IMO, but is not my point. Fact is there are many good methods of securing a system. Doing so piecemeal may not be worth much at all. The original direction of this thead was such that it was worth pointing out STO wouldn't work with so many ways to figure out what OS/version you are on. Unless you show how to plug them all *then* continuing this discussion is pointless. As it turns out the originater only didn't want to see the MOTD, which show that it didn't really belong here in the first place and shifted the context of the question. Care to breath some life into your idea? I'll admit curiousity. May not agree with the basis of the idea, but should it be sound and have merit, then surely others on the list may be interested. Otherwise I'll keep my rifle ready, but don't take it personally (not that I think you are). 8-) cheers! Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 14 1:52:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from nets5.rz.rwth-aachen.de (nets5.rz.RWTH-Aachen.DE [137.226.144.13]) by hub.freebsd.org (Postfix) with ESMTP id C0D4A1567A for ; Tue, 14 Sep 1999 01:52:29 -0700 (PDT) (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by nets5.rz.rwth-aachen.de (8.9.1a/8.9.1/7) with ESMTP id KAA18935 for ; Tue, 14 Sep 1999 10:52:28 +0200 (MET DST) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by campino.informatik.rwth-aachen.de (8.9.1a/8.9.1/3) with ESMTP id KAA24979 for ; Tue, 14 Sep 1999 10:52:27 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.9.2/8.6.9) id KAA40269 for freebsd-security@freebsd.org; Tue, 14 Sep 1999 10:52:31 +0200 (CEST) Date: Tue, 14 Sep 1999 10:52:31 +0200 (CEST) From: Christoph Kukulies Message-Id: <199909140852.KAA40269@gil.physik.rwth-aachen.de> To: freebsd-security@freebsd.org Subject: udp ports (scan?) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was observing packet loss in our local network and while first blaming general network overload I found that the packet loss concentrates on a FreeBSD (3.2) machine while pinging at other hosts in the same network doesn't show the packet loss. During further examining this I started tcpdump on another machine with tcpdump host htobecontrld and ip proto ICMP and running it over one day or so I caught some icmp packets htobecontrld is the host I was examining ournameserver was obviously the source of some requests sent to my host-to-be-controlled which answered with the 'port unreachable' messages. Now I'm wondering what kind of program running on the nameserver (which is not under my direct control) could cause these requests to be launched? tcpdump: listening on de0 13:53:51.256654 htobecontrld > ournameserver: icmp: htobecontrld udp port 3151 unreachable 14:04:26.928073 htobecontrld > ournameserver: icmp: htobecontrld udp port 3190 unreachable 14:07:50.840184 htobecontrld > ournameserver: icmp: htobecontrld udp port 3199 unreachable 14:11:15.185485 htobecontrld > ournameserver: icmp: htobecontrld udp port 3202 unreachable 14:21:37.183022 htobecontrld > ournameserver: icmp: htobecontrld udp port 3221 unreachable 14:21:47.414354 htobecontrld > ournameserver: icmp: htobecontrld udp port 3227 unreachable 14:33:02.343351 htobecontrld > ournameserver: icmp: htobecontrld udp port 3273 unreachable 14:34:02.851694 htobecontrld > ournameserver: icmp: htobecontrld udp port 3282 unreachable 14:36:45.415034 htobecontrld > ournameserver: icmp: htobecontrld udp port 3293 unreachable 15:13:09.697960 htobecontrld > ournameserver: icmp: htobecontrld udp port 3385 unreachable 15:13:09.697960 htobecontrld > ournameserver: icmp: htobecontrld udp port 3385 unreachable 15:20:09.660322 htobecontrld > ournameserver: icmp: htobecontrld udp port 3412 unreachable 15:31:05.104729 htobecontrld > ournameserver: icmp: htobecontrld udp port 3442 unreachable 15:36:29.514619 htobecontrld > ournameserver: icmp: htobecontrld udp port 3462 unreachable 15:41:01.920259 htobecontrld > ournameserver: icmp: htobecontrld udp port 3476 unreachable 15:41:15.251266 htobecontrld > ournameserver: icmp: htobecontrld udp port 3477 unreachable 15:45:08.414133 htobecontrld > ournameserver: icmp: htobecontrld udp port 3515 unreachable 15:45:29.257732 htobecontrld > ournameserver: icmp: htobecontrld udp port 3529 unreachable 15:49:52.837334 htobecontrld > ournameserver: icmp: htobecontrld udp port 3580 unreachable 16:18:31.819020 htobecontrld > ournameserver: icmp: htobecontrld udp port 3737 unreachable 16:32:39.182636 htobecontrld > ournameserver: icmp: htobecontrld udp port 3774 unreachable 16:32:50.888815 htobecontrld > ournameserver: icmp: htobecontrld udp port 3775 unreachable 16:41:31.150820 htobecontrld > ournameserver: icmp: htobecontrld udp port 3832 unreachable 16:58:50.989253 htobecontrld > ournameserver: icmp: htobecontrld udp port 3917 unreachable 16:58:54.683655 htobecontrld > ournameserver: icmp: htobecontrld udp port 3918 unreachable 16:59:18.852931 htobecontrld > ournameserver: icmp: htobecontrld udp port 3926 unreachable 17:04:28.053373 htobecontrld > ournameserver: icmp: htobecontrld udp port 3968 unreachable 17:05:20.889957 htobecontrld > ournameserver: icmp: htobecontrld udp port 3991 unreachable 17:05:25.538210 htobecontrld > ournameserver: icmp: htobecontrld udp port 3987 unreachable 17:05:29.836622 htobecontrld > ournameserver: icmp: htobecontrld udp port 3996 unreachable 17:17:36.700988 htobecontrld > ournameserver: icmp: htobecontrld udp port 4102 unreachable 17:17:36.740919 htobecontrld > ournameserver: icmp: htobecontrld udp port 4103 unreachable 17:31:44.809722 htobecontrld > ournameserver: icmp: htobecontrld udp port 4167 unreachable 17:32:38.966678 htobecontrld > ournameserver: icmp: htobecontrld udp port 4178 unreachable 17:39:54.678230 htobecontrld > ournameserver: icmp: htobecontrld udp port 4196 unreachable 17:59:49.360598 htobecontrld > ournameserver: icmp: htobecontrld udp port 4337 unreachable 18:10:06.141498 htobecontrld > ournameserver: icmp: htobecontrld udp port 4393 unreachable 18:10:14.018915 htobecontrld > ournameserver: icmp: htobecontrld udp port 4397 unreachable 18:22:38.244695 htobecontrld > ournameserver: icmp: htobecontrld udp port 4475 unreachable 18:28:14.111106 htobecontrld > ournameserver: icmp: htobecontrld udp port 4519 unreachable 18:36:13.179419 htobecontrld > ournameserver: icmp: htobecontrld udp port 4596 unreachable 18:37:22.693492 htobecontrld > ournameserver: icmp: htobecontrld udp port 4604 unreachable 18:54:54.669616 htobecontrld > ournameserver: icmp: htobecontrld udp port 4691 unreachable 18:54:57.236363 htobecontrld > ournameserver: icmp: htobecontrld udp port 4694 unreachable 18:55:03.128219 htobecontrld > ournameserver: icmp: htobecontrld udp port 4705 unreachable 19:00:34.078595 htobecontrld > ournameserver: icmp: htobecontrld udp port 4716 unreachable 19:05:12.453255 htobecontrld > ournameserver: imp: htobecontrld udp port 4728 unreachable 19:16:35.928587 htobecontrld > ournameserver: icmp: htobecontrld udp port 4800 unreachable 19:43:39.675290 htobecontrld > ournameserver: icmp: htobecontrld udp port 4874 unreachable 20:28:06.247516 htobecontrld > ournameserver: icmp: htobecontrld udp port 1065 unreachable 20:41:18.205457 htobecontrld > ournameserver: icmp: htobecontrld udp port 1281 unreachable 20:45:42.047075 htobecontrld > ournameserver: icmp: htobecontrld udp port 1325 unreachable 20:49:29.804008 htobecontrld > ournameserver: icmp: htobecontrld udp port 1344 unreachable 20:59:06.544939 htobecontrld > ournameserver: icmp: htobecontrld udp port cadsi-lm unreachable 21:03:36.939149 htobecontrld > ournameserver: icmp: htobecontrld udp port symplex unreachable 21:11:16.690970 htobecontrld > ournameserver: icmp: htobecontrld udp port 1583 unreachable 21:37:14.350186 htobecontrld > ournameserver: icmp: htobecontrld udp port 1716 unreachable 21:38:03.652302 htobecontrld > ournameserver: icmp: htobecontrld udp port 1741 unreachable 21:46:10.942866 htobecontrld > ournameserver: icmp: htobecontrld udp port 1817 unreachable 22:05:50.686555 htobecontrld > ournameserver: icmp: htobecontrld udp port raid-cd unreachable 22:16:33.673137 htobecontrld > ournameserver: icmp: htobecontrld udp port 2071 unreachable 22:21:43.078998 htobecontrld > ournameserver: icmp: htobecontrld udp port 2100 unreachable 22:28:55.425618 htobecontrld > ournameserver: icmp: htobecontrld udp port 2139 unreachable 22:31:33.480595 htobecontrld > ournameserver: icmp: htobecontrld udp port 2160 unreachable 23:02:55.916526 htobecontrld > ournameserver: icmp: htobecontrld udp port 2394 unreachable 23:18:58.826335 htobecontrld > ournameserver: icmp: htobecontrld udp port 2482 unreachable 23:31:48.014578 htobecontrld > ournameserver: icmp: htobecontrld udp port 2519 unreachable 23:31:52.421756 htobecontrld > ournameserver: icmp: htobecontrld udp port 2527 unreachable 23:59:28.936152 htobecontrld > ournameserver: icmp: htobecontrld udp port 2603 unreachable 23:59:31.216532 htobecontrld > ournameserver: icmp: htobecontrld udp port 2601 unreachable 00:58:26.300246 htobecontrld > ournameserver: icmp: htobecontrld udp port 2777 unreachable 04:51:24.263385 htobecontrld > ournameserver: icmp: htobecontrld udp port 3580 unreachable 06:41:34.873900 htobecontrld > ournameserver: icmp: htobecontrld udp port 3811 unreachable 06:42:22.889204 htobecontrld > ournameserver: icmp: htobecontrld udp port 3810 unreachable 07:11:18.000575 htobecontrld > ournameserver: icmp: htobecontrld udp port 3882 unreachable 07:11:23.115720 htobecontrld > ournameserver: icmp: htobecontrld udp port 3883 unreachable 07:12:46.306956 htobecontrld > ournameserver: icmp: htobecontrld udp port 3885 unreachable 08:56:33.120855 htobecontrld > ournameserver: icmp: htobecontrld udp port 4070 unreachable 09:14:47.545636 htobecontrld > openview.rz.RWTH-Aachen.DE: icmp: htobecontrld udp port snmp unreachable 09:14:47.572354 htobecontrld > openview.rz.RWTH-Aachen.DE: icmp: htobecontrld udp port snmp unreachable 09:15:52.561994 htobecontrld > ournameserver: icmp: htobecontrld udp port 4102 unreachable 09:20:32.254100 htobecontrld > ournameserver: icmp: htobecontrld udp port nuts_dem unreachable 09:20:37.859208 htobecontrld > ournameserver: icmp: htobecontrld udp port nuts_bootp unreachable 09:20:47.399799 htobecontrld > ournameserver: icmp: htobecontrld udp port 4134 unreachable -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 14 2:12:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1CE80156E2 for ; Tue, 14 Sep 1999 02:12:40 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA21380; Tue, 14 Sep 1999 11:12:20 +0200 (CEST) (envelope-from des) To: Christoph Kukulies Cc: freebsd-security@FreeBSD.ORG Subject: Re: udp ports (scan?) References: <199909140852.KAA40269@gil.physik.rwth-aachen.de> From: Dag-Erling Smorgrav Date: 14 Sep 1999 11:12:19 +0200 In-Reply-To: Christoph Kukulies's message of "Tue, 14 Sep 1999 10:52:31 +0200 (CEST)" Message-ID: Lines: 11 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Christoph Kukulies writes: > 13:53:51.256654 htobecontrld > ournameserver: icmp: htobecontrld udp port 3151 unreachable > 14:04:26.928073 htobecontrld > ournameserver: icmp: htobecontrld udp port 3190 unreachable These are completely normal. htobecontrld initiated a DNS lookup, ournameserver was a little slow answering, htobecontrld gave up, when the answer finally arrived the UDP socket was closed. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 14 2:38:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from mx2.imaginet.fr (artemis.imaginet.fr [195.68.75.24]) by hub.freebsd.org (Postfix) with ESMTP id D38F414D5A for ; Tue, 14 Sep 1999 02:38:02 -0700 (PDT) (envelope-from michael.hallgren@fisystem.fr) Received: from corpo01.imaginet.fr (corpo01.imaginet.fr [195.68.75.105]) by mx2.imaginet.fr (8.9.3/8.8.8) with ESMTP id LAA18876; Tue, 14 Sep 1999 11:37:34 +0200 (MET DST) Received: from roam (janus.fisystem.fr [195.68.32.60]) by corpo01.imaginet.fr (8.8.8/8.8.8) with SMTP id LAA25673; Tue, 14 Sep 1999 11:37:15 +0200 (MET DST) Message-ID: <00e501befe94$9ec3ce80$b8014b0a@fisystem.fr> From: "Michael Hallgren" To: "Christoph Kukulies" , References: <199909140852.KAA40269@gil.physik.rwth-aachen.de> Subject: Re: udp ports (scan?) Date: Tue, 14 Sep 1999 11:36:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org no portscan; merely normal name lookup request-answer cheers mh > > I was observing packet loss in our local network and > while first blaming general network overload I found that > the packet loss concentrates on a FreeBSD (3.2) machine > while pinging at other hosts in the same network > doesn't show the packet loss. During further examining > this I started tcpdump on another machine with > > tcpdump host htobecontrld and ip proto ICMP > > and running it over one day or so I caught some icmp packets > > htobecontrld is the host I was examining > ournameserver was obviously the source of some requests sent to > my host-to-be-controlled which answered with the 'port unreachable' > messages. > > Now I'm wondering what kind of program running on the nameserver > (which is not under my direct control) could cause these requests > to be launched? > > > tcpdump: listening on de0 > 13:53:51.256654 htobecontrld > ournameserver: icmp: htobecontrld udp port 3151 unreachable > 14:04:26.928073 htobecontrld > ournameserver: icmp: htobecontrld udp port 3190 unreachable > 14:07:50.840184 htobecontrld > ournameserver: icmp: htobecontrld udp port 3199 unreachable > 14:11:15.185485 htobecontrld > ournameserver: icmp: htobecontrld udp port 3202 unreachable > 14:21:37.183022 htobecontrld > ournameserver: icmp: htobecontrld udp port 3221 unreachable > 14:21:47.414354 htobecontrld > ournameserver: icmp: htobecontrld udp port 3227 unreachable > 14:33:02.343351 htobecontrld > ournameserver: icmp: htobecontrld udp port 3273 unreachable > 14:34:02.851694 htobecontrld > ournameserver: icmp: htobecontrld udp port 3282 unreachable > 14:36:45.415034 htobecontrld > ournameserver: icmp: htobecontrld udp port 3293 unreachable > 15:13:09.697960 htobecontrld > ournameserver: icmp: htobecontrld udp port 3385 unreachable > 15:13:09.697960 htobecontrld > ournameserver: icmp: htobecontrld udp port 3385 unreachable > 15:20:09.660322 htobecontrld > ournameserver: icmp: htobecontrld udp port 3412 unreachable > 15:31:05.104729 htobecontrld > ournameserver: icmp: htobecontrld udp port 3442 unreachable > 15:36:29.514619 htobecontrld > ournameserver: icmp: htobecontrld udp port 3462 unreachable > 15:41:01.920259 htobecontrld > ournameserver: icmp: htobecontrld udp port 3476 unreachable > 15:41:15.251266 htobecontrld > ournameserver: icmp: htobecontrld udp port 3477 unreachable > 15:45:08.414133 htobecontrld > ournameserver: icmp: htobecontrld udp port 3515 unreachable > 15:45:29.257732 htobecontrld > ournameserver: icmp: htobecontrld udp port 3529 unreachable > 15:49:52.837334 htobecontrld > ournameserver: icmp: htobecontrld udp port 3580 unreachable > 16:18:31.819020 htobecontrld > ournameserver: icmp: htobecontrld udp port 3737 unreachable > 16:32:39.182636 htobecontrld > ournameserver: icmp: htobecontrld udp port 3774 unreachable > 16:32:50.888815 htobecontrld > ournameserver: icmp: htobecontrld udp port 3775 unreachable > 16:41:31.150820 htobecontrld > ournameserver: icmp: htobecontrld udp port 3832 unreachable > 16:58:50.989253 htobecontrld > ournameserver: icmp: htobecontrld udp port 3917 unreachable > 16:58:54.683655 htobecontrld > ournameserver: icmp: htobecontrld udp port 3918 unreachable > 16:59:18.852931 htobecontrld > ournameserver: icmp: htobecontrld udp port 3926 unreachable > 17:04:28.053373 htobecontrld > ournameserver: icmp: htobecontrld udp port 3968 unreachable > 17:05:20.889957 htobecontrld > ournameserver: icmp: htobecontrld udp port 3991 unreachable > 17:05:25.538210 htobecontrld > ournameserver: icmp: htobecontrld udp port 3987 unreachable > 17:05:29.836622 htobecontrld > ournameserver: icmp: htobecontrld udp port 3996 unreachable > 17:17:36.700988 htobecontrld > ournameserver: icmp: htobecontrld udp port 4102 unreachable > 17:17:36.740919 htobecontrld > ournameserver: icmp: htobecontrld udp port 4103 unreachable > 17:31:44.809722 htobecontrld > ournameserver: icmp: htobecontrld udp port 4167 unreachable > 17:32:38.966678 htobecontrld > ournameserver: icmp: htobecontrld udp port 4178 unreachable > 17:39:54.678230 htobecontrld > ournameserver: icmp: htobecontrld udp port 4196 unreachable > 17:59:49.360598 htobecontrld > ournameserver: icmp: htobecontrld udp port 4337 unreachable > 18:10:06.141498 htobecontrld > ournameserver: icmp: htobecontrld udp port 4393 unreachable > 18:10:14.018915 htobecontrld > ournameserver: icmp: htobecontrld udp port 4397 unreachable > 18:22:38.244695 htobecontrld > ournameserver: icmp: htobecontrld udp port 4475 unreachable > 18:28:14.111106 htobecontrld > ournameserver: icmp: htobecontrld udp port 4519 unreachable > 18:36:13.179419 htobecontrld > ournameserver: icmp: htobecontrld udp port 4596 unreachable > 18:37:22.693492 htobecontrld > ournameserver: icmp: htobecontrld udp port 4604 unreachable > 18:54:54.669616 htobecontrld > ournameserver: icmp: htobecontrld udp port 4691 unreachable > 18:54:57.236363 htobecontrld > ournameserver: icmp: htobecontrld udp port 4694 unreachable > 18:55:03.128219 htobecontrld > ournameserver: icmp: htobecontrld udp port 4705 unreachable > 19:00:34.078595 htobecontrld > ournameserver: icmp: htobecontrld udp port 4716 unreachable > 19:05:12.453255 htobecontrld > ournameserver: imp: htobecontrld udp port 4728 unreachable > 19:16:35.928587 htobecontrld > ournameserver: icmp: htobecontrld udp port 4800 unreachable > 19:43:39.675290 htobecontrld > ournameserver: icmp: htobecontrld udp port 4874 unreachable > 20:28:06.247516 htobecontrld > ournameserver: icmp: htobecontrld udp port 1065 unreachable > 20:41:18.205457 htobecontrld > ournameserver: icmp: htobecontrld udp port 1281 unreachable > 20:45:42.047075 htobecontrld > ournameserver: icmp: htobecontrld udp port 1325 unreachable > 20:49:29.804008 htobecontrld > ournameserver: icmp: htobecontrld udp port 1344 unreachable > 20:59:06.544939 htobecontrld > ournameserver: icmp: htobecontrld udp port cadsi-lm unreachable > 21:03:36.939149 htobecontrld > ournameserver: icmp: htobecontrld udp port symplex unreachable > 21:11:16.690970 htobecontrld > ournameserver: icmp: htobecontrld udp port 1583 unreachable > 21:37:14.350186 htobecontrld > ournameserver: icmp: htobecontrld udp port 1716 unreachable > 21:38:03.652302 htobecontrld > ournameserver: icmp: htobecontrld udp port 1741 unreachable > 21:46:10.942866 htobecontrld > ournameserver: icmp: htobecontrld udp port 1817 unreachable > 22:05:50.686555 htobecontrld > ournameserver: icmp: htobecontrld udp port raid-cd unreachable > 22:16:33.673137 htobecontrld > ournameserver: icmp: htobecontrld udp port 2071 unreachable > 22:21:43.078998 htobecontrld > ournameserver: icmp: htobecontrld udp port 2100 unreachable > 22:28:55.425618 htobecontrld > ournameserver: icmp: htobecontrld udp port 2139 unreachable > 22:31:33.480595 htobecontrld > ournameserver: icmp: htobecontrld udp port 2160 unreachable > 23:02:55.916526 htobecontrld > ournameserver: icmp: htobecontrld udp port 2394 unreachable > 23:18:58.826335 htobecontrld > ournameserver: icmp: htobecontrld udp port 2482 unreachable > 23:31:48.014578 htobecontrld > ournameserver: icmp: htobecontrld udp port 2519 unreachable > 23:31:52.421756 htobecontrld > ournameserver: icmp: htobecontrld udp port 2527 unreachable > 23:59:28.936152 htobecontrld > ournameserver: icmp: htobecontrld udp port 2603 unreachable > 23:59:31.216532 htobecontrld > ournameserver: icmp: htobecontrld udp port 2601 unreachable > 00:58:26.300246 htobecontrld > ournameserver: icmp: htobecontrld udp port 2777 unreachable > 04:51:24.263385 htobecontrld > ournameserver: icmp: htobecontrld udp port 3580 unreachable > 06:41:34.873900 htobecontrld > ournameserver: icmp: htobecontrld udp port 3811 unreachable > 06:42:22.889204 htobecontrld > ournameserver: icmp: htobecontrld udp port 3810 unreachable > 07:11:18.000575 htobecontrld > ournameserver: icmp: htobecontrld udp port 3882 unreachable > 07:11:23.115720 htobecontrld > ournameserver: icmp: htobecontrld udp port 3883 unreachable > 07:12:46.306956 htobecontrld > ournameserver: icmp: htobecontrld udp port 3885 unreachable > 08:56:33.120855 htobecontrld > ournameserver: icmp: htobecontrld udp port 4070 unreachable > 09:14:47.545636 htobecontrld > openview.rz.RWTH-Aachen.DE: icmp: htobecontrld udp port snmp unreachable > 09:14:47.572354 htobecontrld > openview.rz.RWTH-Aachen.DE: icmp: htobecontrld udp port snmp unreachable > 09:15:52.561994 htobecontrld > ournameserver: icmp: htobecontrld udp port 4102 unreachable > 09:20:32.254100 htobecontrld > ournameserver: icmp: htobecontrld udp port nuts_dem unreachable > 09:20:37.859208 htobecontrld > ournameserver: icmp: htobecontrld udp port nuts_bootp unreachable > 09:20:47.399799 htobecontrld > ournameserver: icmp: htobecontrld udp port 4134 unreachable > > > -- > Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 14 2:42:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from mx2.imaginet.fr (artemis.imaginet.fr [195.68.75.24]) by hub.freebsd.org (Postfix) with ESMTP id A66B514D5A for ; Tue, 14 Sep 1999 02:42:04 -0700 (PDT) (envelope-from michael.hallgren@fisystem.fr) Received: from corpo01.imaginet.fr (corpo01.imaginet.fr [195.68.75.105]) by mx2.imaginet.fr (8.9.3/8.8.8) with ESMTP id LAA19127; Tue, 14 Sep 1999 11:41:36 +0200 (MET DST) Received: from roam (janus.fisystem.fr [195.68.32.60]) by corpo01.imaginet.fr (8.8.8/8.8.8) with SMTP id LAA26353; Tue, 14 Sep 1999 11:41:17 +0200 (MET DST) Message-ID: <010a01befe95$2e8c9560$b8014b0a@fisystem.fr> From: "Michael Hallgren" To: "Michael Hallgren" , "Christoph Kukulies" , References: <199909140852.KAA40269@gil.physik.rwth-aachen.de> <00e501befe94$9ec3ce80$b8014b0a@fisystem.fr> Subject: Re: udp ports (scan?) Date: Tue, 14 Sep 1999 11:40:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > no portscan; merely normal name lookup request-answer w/o answer ;) mh > > cheers > > mh > > > > > I was observing packet loss in our local network and > > while first blaming general network overload I found that > > the packet loss concentrates on a FreeBSD (3.2) machine > > while pinging at other hosts in the same network > > doesn't show the packet loss. During further examining > > this I started tcpdump on another machine with > > > > tcpdump host htobecontrld and ip proto ICMP > > > > and running it over one day or so I caught some icmp packets > > > > htobecontrld is the host I was examining > > ournameserver was obviously the source of some requests sent to > > my host-to-be-controlled which answered with the 'port unreachable' > > messages. > > > > Now I'm wondering what kind of program running on the nameserver > > (which is not under my direct control) could cause these requests > > to be launched? > > > > > > tcpdump: listening on de0 > > 13:53:51.256654 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3151 unreachable > > 14:04:26.928073 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3190 unreachable > > 14:07:50.840184 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3199 unreachable > > 14:11:15.185485 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3202 unreachable > > 14:21:37.183022 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3221 unreachable > > 14:21:47.414354 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3227 unreachable > > 14:33:02.343351 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3273 unreachable > > 14:34:02.851694 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3282 unreachable > > 14:36:45.415034 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3293 unreachable > > 15:13:09.697960 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3385 unreachable > > 15:13:09.697960 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3385 unreachable > > 15:20:09.660322 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3412 unreachable > > 15:31:05.104729 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3442 unreachable > > 15:36:29.514619 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3462 unreachable > > 15:41:01.920259 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3476 unreachable > > 15:41:15.251266 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3477 unreachable > > 15:45:08.414133 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3515 unreachable > > 15:45:29.257732 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3529 unreachable > > 15:49:52.837334 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3580 unreachable > > 16:18:31.819020 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3737 unreachable > > 16:32:39.182636 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3774 unreachable > > 16:32:50.888815 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3775 unreachable > > 16:41:31.150820 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3832 unreachable > > 16:58:50.989253 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3917 unreachable > > 16:58:54.683655 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3918 unreachable > > 16:59:18.852931 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3926 unreachable > > 17:04:28.053373 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3968 unreachable > > 17:05:20.889957 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3991 unreachable > > 17:05:25.538210 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3987 unreachable > > 17:05:29.836622 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3996 unreachable > > 17:17:36.700988 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4102 unreachable > > 17:17:36.740919 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4103 unreachable > > 17:31:44.809722 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4167 unreachable > > 17:32:38.966678 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4178 unreachable > > 17:39:54.678230 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4196 unreachable > > 17:59:49.360598 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4337 unreachable > > 18:10:06.141498 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4393 unreachable > > 18:10:14.018915 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4397 unreachable > > 18:22:38.244695 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4475 unreachable > > 18:28:14.111106 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4519 unreachable > > 18:36:13.179419 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4596 unreachable > > 18:37:22.693492 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4604 unreachable > > 18:54:54.669616 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4691 unreachable > > 18:54:57.236363 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4694 unreachable > > 18:55:03.128219 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4705 unreachable > > 19:00:34.078595 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4716 unreachable > > 19:05:12.453255 htobecontrld > ournameserver: imp: htobecontrld udp port > 4728 unreachable > > 19:16:35.928587 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4800 unreachable > > 19:43:39.675290 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4874 unreachable > > 20:28:06.247516 htobecontrld > ournameserver: icmp: htobecontrld udp port > 1065 unreachable > > 20:41:18.205457 htobecontrld > ournameserver: icmp: htobecontrld udp port > 1281 unreachable > > 20:45:42.047075 htobecontrld > ournameserver: icmp: htobecontrld udp port > 1325 unreachable > > 20:49:29.804008 htobecontrld > ournameserver: icmp: htobecontrld udp port > 1344 unreachable > > 20:59:06.544939 htobecontrld > ournameserver: icmp: htobecontrld udp port > cadsi-lm unreachable > > 21:03:36.939149 htobecontrld > ournameserver: icmp: htobecontrld udp port > symplex unreachable > > 21:11:16.690970 htobecontrld > ournameserver: icmp: htobecontrld udp port > 1583 unreachable > > 21:37:14.350186 htobecontrld > ournameserver: icmp: htobecontrld udp port > 1716 unreachable > > 21:38:03.652302 htobecontrld > ournameserver: icmp: htobecontrld udp port > 1741 unreachable > > 21:46:10.942866 htobecontrld > ournameserver: icmp: htobecontrld udp port > 1817 unreachable > > 22:05:50.686555 htobecontrld > ournameserver: icmp: htobecontrld udp port > raid-cd unreachable > > 22:16:33.673137 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2071 unreachable > > 22:21:43.078998 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2100 unreachable > > 22:28:55.425618 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2139 unreachable > > 22:31:33.480595 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2160 unreachable > > 23:02:55.916526 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2394 unreachable > > 23:18:58.826335 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2482 unreachable > > 23:31:48.014578 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2519 unreachable > > 23:31:52.421756 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2527 unreachable > > 23:59:28.936152 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2603 unreachable > > 23:59:31.216532 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2601 unreachable > > 00:58:26.300246 htobecontrld > ournameserver: icmp: htobecontrld udp port > 2777 unreachable > > 04:51:24.263385 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3580 unreachable > > 06:41:34.873900 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3811 unreachable > > 06:42:22.889204 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3810 unreachable > > 07:11:18.000575 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3882 unreachable > > 07:11:23.115720 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3883 unreachable > > 07:12:46.306956 htobecontrld > ournameserver: icmp: htobecontrld udp port > 3885 unreachable > > 08:56:33.120855 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4070 unreachable > > 09:14:47.545636 htobecontrld > openview.rz.RWTH-Aachen.DE: icmp: > htobecontrld udp port snmp unreachable > > 09:14:47.572354 htobecontrld > openview.rz.RWTH-Aachen.DE: icmp: > htobecontrld udp port snmp unreachable > > 09:15:52.561994 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4102 unreachable > > 09:20:32.254100 htobecontrld > ournameserver: icmp: htobecontrld udp port > nuts_dem unreachable > > 09:20:37.859208 htobecontrld > ournameserver: icmp: htobecontrld udp port > nuts_bootp unreachable > > 09:20:47.399799 htobecontrld > ournameserver: icmp: htobecontrld udp port > 4134 unreachable > > > > > > -- > > Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 8:30: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id D79AE15328 for ; Wed, 15 Sep 1999 08:29:11 -0700 (PDT) (envelope-from GregoryC@stcinc.com) Received: from stcinc.com (gw-covad768k-cognitivetech.ncal.verio.com [207.20.238.29] (may be forged)) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id IAA07562 for ; Wed, 15 Sep 1999 08:27:11 -0700 (PDT) Message-ID: <37DFBE91.A07AAF8B@stcinc.com> Date: Wed, 15 Sep 1999 08:43:13 -0700 From: Gregory Carvalho Reply-To: GregoryC@stcinc.com Organization: Simplified Technology Company X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: FreeBSD-security@freebsd.org Subject: FreeBSD-SA-99:01 File Flags and Man-In-The-Middle Attack Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It appears to me that this exploit can be avoided by logging in as root on all virtual terminals and immediately logging back out. Does my theory sound correct? Cordially, Gregory Carvalho GregoryC@stcinc.com Simplified Technology Company http://www.stcinc.com In God I Trust! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 11:54:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (Postfix) with ESMTP id D037014CF0 for ; Wed, 15 Sep 1999 11:54:44 -0700 (PDT) (envelope-from GregoryC@stcinc.com) Received: from stcinc.com (gw-covad768k-cognitivetech.ncal.verio.com [207.20.238.29] (may be forged)) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id LAA20235; Wed, 15 Sep 1999 11:52:24 -0700 (PDT) Message-ID: <37DFEEAB.FC57FFDB@stcinc.com> Date: Wed, 15 Sep 1999 12:08:27 -0700 From: Gregory Carvalho Reply-To: GregoryC@stcinc.com Organization: Simplified Technology Company X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kelsey Cummings , FreeBSD-Security@FreeBSD.ORG Subject: Re: FreeBSD-SA-99:01 File Flags and Man-In-The-Middle Attack References: <37DFBE91.A07AAF8B@stcinc.com> <0d3001beffa9$2f55f170$33f9c9d0@neteze.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is all I could come up with from the CIAC (http://www.ciac.org) bulletin ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-99:01/ Kelsey Cummings wrote: > > Do you have a link to the report? TIA. > > ----- Original Message ----- > From: Gregory Carvalho > To: > Sent: Wednesday, September 15, 1999 8:43 AM > Subject: FreeBSD-SA-99:01 File Flags and Man-In-The-Middle Attack > > > It appears to me that this exploit can be avoided by logging in as root > > on all virtual terminals and immediately logging back out. Does my > > theory sound correct? > > Cordially, Gregory Carvalho GregoryC@stcinc.com Simplified Technology Company http://www.stcinc.com In God I Trust! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 14:15:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from agora.neteze.com (agora.neteze.com [208.201.249.4]) by hub.freebsd.org (Postfix) with ESMTP id 61ADD14BC2 for ; Wed, 15 Sep 1999 14:15:13 -0700 (PDT) (envelope-from kc@neteze.com) Received: from admin1 ([208.201.249.51]) by agora.neteze.com (Post.Office MTA v3.5.3 release 223 ID# 0-60395U6000L600S0V35) with SMTP id com for ; Wed, 15 Sep 1999 14:19:07 -0700 Message-ID: <0e6f01beffbf$c991bb00$33f9c9d0@neteze.com> From: "Kelsey Cummings" To: Subject: FreeBSD Vulnerabilities in wu-ftpd and proftpd (J-068) Date: Wed, 15 Sep 1999 14:17:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is checking out the lastest verision of wu-ftpd (wu-ftpd-2.4.2-vr17?) from the ports collection (cvs co wu-ftpd) fix this vulnerablity, I'm relatively new to this and it wasn't clear in the bulitin what versions were affected, only that those previous to August 30, 1999 are. Thanks. ----------------------------------------------------------------- Kelsey Cummings System Administrator NetEase, Inc. kc@neteze.com ----------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 15:53:55 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id A9F6314DE4 for ; Wed, 15 Sep 1999 15:53:53 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id QAA20647 for ; Wed, 15 Sep 1999 16:53:49 -0600 (MDT) Message-Id: <4.2.0.58.19990915164546.048d0100@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Sep 1999 16:52:36 -0600 To: security@freebsd.org From: Brett Glass Subject: BPF on in 3.3-RC GENERIC kernel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Was doing some testing on the latest release candidate of FreeBSD 3.3, and noted that the Berkeley Packet Filter was enabled in the GENERIC kernel. Is this a good idea? --Brett Glass To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 15:58: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id DEA7214FC6 for ; Wed, 15 Sep 1999 15:57:58 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id IAA12550; Thu, 16 Sep 1999 08:59:22 +1000 (EST) From: Darren Reed Message-Id: <199909152259.IAA12550@cheops.anu.edu.au> Subject: Re: BPF on in 3.3-RC GENERIC kernel To: brett@lariat.org (Brett Glass) Date: Thu, 16 Sep 1999 08:59:21 +1000 (EST) Cc: security@FreeBSD.ORG In-Reply-To: <4.2.0.58.19990915164546.048d0100@localhost> from "Brett Glass" at Sep 15, 99 04:52:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Brett Glass, sie said: > > Was doing some testing on the latest release candidate of FreeBSD 3.3, and > noted that the Berkeley Packet Filter was enabled in the GENERIC kernel. Is > this a good idea? Yes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 16: 0: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by hub.freebsd.org (Postfix) with ESMTP id 24BA915005 for ; Wed, 15 Sep 1999 15:59:57 -0700 (PDT) (envelope-from Harry_M_Leitzell@cmu.edu) Received: from unix13.andrew.cmu.edu (UNIX13.ANDREW.CMU.EDU [128.2.15.17]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id SAA10968; Wed, 15 Sep 1999 18:59:45 -0400 (EDT) Date: Wed, 15 Sep 1999 18:59:45 -0400 (EDT) From: "Harry M. Leitzell" X-Sender: Harry_M_Leitzell@unix13.andrew.cmu.edu To: Brett Glass Cc: security@freebsd.org Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4.2.0.58.19990915164546.048d0100@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Correct me if I am wrong, but didn't the list have a huge arguement over this a while back and the decision was to leave it in for some reasons that someone dreamed up? Anyone who didn't see the issue brought up, might want to check the list logs (Wherever they might be) for 3.2 or another release. On Wed, 15 Sep 1999, Brett Glass wrote: > Was doing some testing on the latest release candidate of FreeBSD 3.3, and > noted that the Berkeley Packet Filter was enabled in the GENERIC kernel. Is > this a good idea? > > --Brett Glass > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > [-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] Harry M. Leitzell - Harry_M_Leitzell@cmu.edu Carnegie Mellon University Finger for PGP Public Key [-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 16:10:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id D84A914FC6 for ; Wed, 15 Sep 1999 16:10:41 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id RAA20876; Wed, 15 Sep 1999 17:10:35 -0600 (MDT) Message-Id: <4.2.0.58.19990915170025.048d0b00@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Sep 1999 17:09:23 -0600 To: "Harry M. Leitzell" From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: security@freebsd.org In-Reply-To: References: <4.2.0.58.19990915164546.048d0100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Maybe it's a religious issue, or maybe some utility depends on it. But it might not be a good idea to let it be on from the get-go. If the machine is rooted, you've got an instant packet sniffer. I plan to turn it off on EVERY install, and I sure wish it were that way to start. --Brett At 06:59 PM 9/15/99 -0400, Harry M. Leitzell wrote: > Correct me if I am wrong, but didn't the list have a huge >arguement over this a while back and the decision was to leave it in for >some reasons that someone dreamed up? Anyone who didn't see the issue >brought up, might want to check the list logs (Wherever they might be) for >3.2 or another release. > >On Wed, 15 Sep 1999, Brett Glass wrote: > > > Was doing some testing on the latest release candidate of FreeBSD 3.3, and > > noted that the Berkeley Packet Filter was enabled in the GENERIC kernel. Is > > this a good idea? > > > > --Brett Glass > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > >[-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] > Harry M. Leitzell - Harry_M_Leitzell@cmu.edu > Carnegie Mellon University > Finger for PGP Public Key >[-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 16:15: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from dt014nb6.san.rr.com (dt014nb6.san.rr.com [24.30.129.182]) by hub.freebsd.org (Postfix) with ESMTP id A997514BE5 for ; Wed, 15 Sep 1999 16:15:01 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt014nb6.san.rr.com (8.9.3/8.8.8) with ESMTP id QAA17620; Wed, 15 Sep 1999 16:36:46 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Wed, 15 Sep 1999 16:36:46 -0700 (PDT) From: Doug X-Sender: doug@dt014nb6.san.rr.com To: Brett Glass Cc: security@freebsd.org Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4.2.0.58.19990915164546.048d0100@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 15 Sep 1999, Brett Glass wrote: > Was doing some testing on the latest release candidate of FreeBSD 3.3, and > noted that the Berkeley Packet Filter was enabled in the GENERIC kernel. Is > this a good idea? Short answer, Yes. Longer answers can be found in the mail archives. Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 16:17:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from terrapin.ru.ac.za (terrapin.ru.ac.za [146.231.128.6]) by hub.freebsd.org (Postfix) with ESMTP id 55E4A14A23 for ; Wed, 15 Sep 1999 16:17:11 -0700 (PDT) (envelope-from nbm@mithrandr.moria.org) Received: from duca.dialup.ru.ac.za ([146.231.98.24] helo=mithrandr.moria.org) by terrapin.ru.ac.za with esmtp (Exim 3.03 #1) id 11ROIW-0000xH-00 for security@FreeBSD.ORG; Thu, 16 Sep 1999 01:17:08 +0200 Received: (qmail 31035 invoked by uid 1001); 15 Sep 1999 23:17:23 -0000 Date: Thu, 16 Sep 1999 01:17:23 +0200 From: Neil Blakey-Milner To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel Message-ID: <19990916011723.B28027@mithrandr.moria.org> References: <4.2.0.58.19990915164546.048d0100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <4.2.0.58.19990915164546.048d0100@localhost>; from Brett Glass on Wed, Sep 15, 1999 at 04:52:36PM -0600 Organization: Rhodes University Computer Users' Society X-Operating-System: FreeBSD 4.0-CURRENT i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed 1999-09-15 (16:52), Brett Glass wrote: > Was doing some testing on the latest release candidate of FreeBSD 3.3, and > noted that the Berkeley Packet Filter was enabled in the GENERIC kernel. Is > this a good idea? I believe it has something to do with DHCP. There were other reasons too. Neil -- Neil Blakey-Milner nbm@rucus.ru.ac.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 16:20: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id DA31B1514D for ; Wed, 15 Sep 1999 16:19:47 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id JAA12988; Thu, 16 Sep 1999 09:21:12 +1000 (EST) From: Darren Reed Message-Id: <199909152321.JAA12988@cheops.anu.edu.au> Subject: Re: BPF on in 3.3-RC GENERIC kernel To: brett@lariat.org (Brett Glass) Date: Thu, 16 Sep 1999 09:21:11 +1000 (EST) Cc: Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG In-Reply-To: <4.2.0.58.19990915170025.048d0b00@localhost> from "Brett Glass" at Sep 15, 99 05:09:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Brett Glass, sie said: > > Maybe it's a religious issue, or maybe some utility depends on it. It's called "tcpdump" and it ships with FreeBSD, by default. > But it might not be a good idea to let it be on from the get-go. > If the machine is rooted, you've got an instant packet sniffer. If the machine is rooted, you're fucked anyway, unless it's so wired down with things using file flags that you can't even use vi any more. > I plan to turn it off on EVERY install, and I sure wish it > were that way to start. Good for you. At least those of us who use it don't have to turn it on for EVERY install now :-) Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 16:23:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from po8.andrew.cmu.edu (PO8.ANDREW.CMU.EDU [128.2.10.108]) by hub.freebsd.org (Postfix) with ESMTP id 39E771533F for ; Wed, 15 Sep 1999 16:22:12 -0700 (PDT) (envelope-from tcrimi+@andrew.cmu.edu) Received: (from postman@localhost) by po8.andrew.cmu.edu (8.9.3/8.9.3) id TAA29840; Wed, 15 Sep 1999 19:22:10 -0400 (EDT) Received: via switchmail; Wed, 15 Sep 1999 19:22:10 -0400 (EDT) Received: from unix12.andrew.cmu.edu via qmail ID ; Wed, 15 Sep 1999 19:21:20 -0400 (EDT) Received: from unix12.andrew.cmu.edu via qmail ID ; Wed, 15 Sep 1999 19:21:20 -0400 (EDT) Received: from mms.4.60.Jun.27.1996.03.02.53.sun4.51.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.unix12.andrew.cmu.edu.sun4m.54 via MS.5.6.unix12.andrew.cmu.edu.sun4_51; Wed, 15 Sep 1999 19:21:20 -0400 (EDT) Message-ID: <4rs2bkG00UwE10yxw0@andrew.cmu.edu> Date: Wed, 15 Sep 1999 19:21:20 -0400 (EDT) From: Thomas Valentino Crimi To: security@freebsd.org, Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: In-Reply-To: <4.2.0.58.19990915164546.048d0100@localhost> References: <4.2.0.58.19990915164546.048d0100@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This was discussed in much detail earlier, but here is the short and skinny on it: DHCP, particularly during installation, is _VERY_ handy. As networks are being configured today, there are many users that may end up being left out in the cold, or hat least aving to go through a particular amount of effort to install. Let's not unncessarily bring up this thread again, so test all posible arguments against the archives :) A new breakthrough would probably be welcome, though. In my mind, the general doesn't-recompile-the-kernel user would especilly not go through the hoops it may take to install without DHCP support. -Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 16:28:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 30CC315652 for ; Wed, 15 Sep 1999 16:28:13 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40351>; Thu, 16 Sep 1999 09:25:54 +1000 Date: Thu, 16 Sep 1999 09:28:02 +1000 From: Peter Jeremy Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: <4.2.0.58.19990915170025.048d0b00@localhost> To: brett@lariat.org Cc: security@FreeBSD.ORG Message-Id: <99Sep16.092554est.40351@border.alcanet.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: >Maybe it's a religious issue, or maybe some utility depends on it. As Harry pointed out, this has been discussed to death on several mailing lists. BPF is necessary so the DHCP client software will work - and DHCP client is now felt to be essential. It's also necessary for some userland ppp facilities. If you feel stringly enough about the issue, feel free to submit patches so that DHCP client will work without BPF. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 16:30:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.240.222]) by hub.freebsd.org (Postfix) with ESMTP id CE91A152EA for ; Wed, 15 Sep 1999 16:30:10 -0700 (PDT) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.1) id QAA08825; Wed, 15 Sep 1999 16:30:06 -0700 (PDT) (envelope-from mph) Date: Wed, 15 Sep 1999 16:30:06 -0700 From: Matthew Hunt To: "Harry M. Leitzell" Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel Message-ID: <19990915163006.C7739@wopr.caltech.edu> References: <4.2.0.58.19990915164546.048d0100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Harry M. Leitzell on Wed, Sep 15, 1999 at 06:59:45PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 15, 1999 at 06:59:45PM -0400, Harry M. Leitzell wrote: > Correct me if I am wrong, but didn't the list have a huge > arguement over this a while back and the decision was to leave it in for > some reasons that someone dreamed up? Anyone who didn't see the issue > brought up, might want to check the list logs (Wherever they might be) for > 3.2 or another release. It is necessary for installing on a machine which gets its IP using DHCP. -- Matthew Hunt * Why are you here? http://www.pobox.com/~mph/ * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 17:19: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id 4F0F61529B for ; Wed, 15 Sep 1999 17:19:03 -0700 (PDT) (envelope-from jim@blues.ghis.net) Received: from blues.ghis.net (jim@dialup-canax393.mpx.com.au [198.142.172.93]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id RAA39879; Wed, 15 Sep 1999 17:19:00 -0700 (PDT) Received: (from jim@localhost) by blues.ghis.net (8.9.3/8.9.3) id KAA31561; Thu, 16 Sep 1999 10:18:56 +1000 (EST) (envelope-from jim) Date: Thu, 16 Sep 1999 10:18:55 +1000 From: Jim Mock To: Kelsey Cummings Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Vulnerabilities in wu-ftpd and proftpd (J-068) Message-ID: <19990916101855.C30603@blues.ghis.net> Reply-To: jim@blues.ghis.net References: <0e6f01beffbf$c991bb00$33f9c9d0@neteze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <0e6f01beffbf$c991bb00$33f9c9d0@neteze.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 15 Sep 1999 at 14:17:59 -0700, Kelsey Cummings wrote: > Is checking out the lastest verision of wu-ftpd > (wu-ftpd-2.4.2-vr17?) from the ports collection (cvs co wu-ftpd) fix > this vulnerablity, I'm relatively new to this and it wasn't clear in > the bulitin what versions were affected, only that those previous to > August 30, 1999 are. Thanks. The latest port is 2.5.0, and the patches will be fetched with the distfile. - Jim -- - Jim Mock - jim@blues.ghis.net - systems administrator - ghis.NET - - work: http://www.ghis.net/ - personal: http://www.ghis.net/~jim/ - - FreeBSD 'zine: http://www.freebsdzine.org/ - jim@freebsdzine.org - - The FreeBSD Project -- http://www.FreeBSD.org/ - jim@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 18:22:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 882EB14C2F for ; Wed, 15 Sep 1999 18:22:37 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA19173; Thu, 16 Sep 1999 03:22:36 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA08788; Thu, 16 Sep 1999 03:22:36 +0200 (MET DST) Date: Thu, 16 Sep 1999 03:22:20 +0200 From: Eivind Eklund To: Gregory Carvalho Cc: FreeBSD-security@FreeBSD.ORG Subject: Re: FreeBSD-SA-99:01 File Flags and Man-In-The-Middle Attack Message-ID: <19990916032220.K5255@bitbox.follo.net> References: <37DFBE91.A07AAF8B@stcinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <37DFBE91.A07AAF8B@stcinc.com>; from Gregory Carvalho on Wed, Sep 15, 1999 at 08:43:13AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 15, 1999 at 08:43:13AM -0700, Gregory Carvalho wrote: > It appears to me that this exploit can be avoided by logging in as root > on all virtual terminals and immediately logging back out. Does my > theory sound correct? No. It sounds totally and utterly wrong. Apply the patches (the rc scripts and the kernel) and you should be fine. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19: 1:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by hub.freebsd.org (Postfix) with ESMTP id 102C1153B3 for ; Wed, 15 Sep 1999 19:01:28 -0700 (PDT) (envelope-from ncb@zip.com.au) Received: from zipperii.zip.com.au (ncb@zipperii.zip.com.au [203.12.97.87]) by vasquez.zip.com.au (8.9.2/8.9.1) with ESMTP id LAA04070; Thu, 16 Sep 1999 11:47:37 +1000 (EST) Date: Thu, 16 Sep 1999 12:02:39 +1000 (EST) From: Nicholas Brawn To: Brett Glass Cc: "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4.2.0.58.19990915170025.048d0b00@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 15 Sep 1999, Brett Glass wrote: > Maybe it's a religious issue, or maybe some utility depends on it. > But it might not be a good idea to let it be on from the get-go. > If the machine is rooted, you've got an instant packet sniffer. > I plan to turn it off on EVERY install, and I sure wish it > were that way to start. > > --Brett > Yes, and let's include two kernels in the distribution. One for those who want BPF, and one for those who don't. Come on people, this issue is long past dead and buried. It is a simple matter to [dis|enable] BPF in the kernel. Rather than arguing about the default nature of such installs, why not promote user education about such security issues. Nick -- Email: ncb@zip.com.au (or) nicholas.brawn@hushmail.com Key fingerprint = 71C5 2EA8 903B 0BC4 8EEE 9122 7349 EADC 49C1 424E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19:14:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 23EEA14A26 for ; Wed, 15 Sep 1999 19:14:23 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA22490; Wed, 15 Sep 1999 20:14:10 -0600 (MDT) Message-Id: <4.2.0.58.19990915200910.048dba50@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Sep 1999 20:12:54 -0600 To: Darren Reed From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG In-Reply-To: <199909152321.JAA12988@cheops.anu.edu.au> References: <4.2.0.58.19990915170025.048d0b00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:21 AM 9/16/99 +1000, Darren Reed wrote: >If the machine is rooted, you're fucked anyway, unless it's so wired >down with things using file flags that you can't even use vi any more. Well, setting securelevel and making certain key files, like the kernel, immutable helps immensely. Say, there's a thought. Would it be possible to make a high security level "lock down" BPF? Or would it be possible to disable it via a kernel config option? One could run the kernel configuration utility to enable or disable it at boot. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19:19:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id A77B514A26 for ; Wed, 15 Sep 1999 19:19:09 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 415731C24; Wed, 15 Sep 1999 21:23:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 364D73817; Wed, 15 Sep 1999 21:23:15 -0400 (EDT) Date: Wed, 15 Sep 1999 21:23:15 -0400 (EDT) From: Bill Fumerola To: Brett Glass Cc: security@freebsd.org Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4.2.0.58.19990915164546.048d0100@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 15 Sep 1999, Brett Glass wrote: > Was doing some testing on the latest release candidate of FreeBSD 3.3, and > noted that the Berkeley Packet Filter was enabled in the GENERIC kernel. Is > this a good idea? A better question is: Is it a good idea to ask questions that have been hashed over in the (publically archived) mailing lists (including the one you are posting on)? -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19:20:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id C918014C0B for ; Wed, 15 Sep 1999 19:20:25 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 558D71C24; Wed, 15 Sep 1999 21:24:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 524F03817; Wed, 15 Sep 1999 21:24:31 -0400 (EDT) Date: Wed, 15 Sep 1999 21:24:31 -0400 (EDT) From: Bill Fumerola To: Brett Glass Cc: "Harry M. Leitzell" , security@freebsd.org Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4.2.0.58.19990915170025.048d0b00@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 15 Sep 1999, Brett Glass wrote: > Maybe it's a religious issue, or maybe some utility depends on it. > But it might not be a good idea to let it be on from the get-go. > If the machine is rooted, you've got an instant packet sniffer. > I plan to turn it off on EVERY install, and I sure wish it > were that way to start. Read the archive and shut the fuck up. Let me summarize: If you have a rooted machine, you have bigger problems. If you have a sniffable network, fix that at the network level. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19:20:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id C20DA14A26 for ; Wed, 15 Sep 1999 19:20:40 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA22551; Wed, 15 Sep 1999 20:20:33 -0600 (MDT) Message-Id: <4.2.0.58.19990915201332.048da870@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Sep 1999 20:16:53 -0600 To: Thomas Valentino Crimi , security@freebsd.org From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4rs2bkG00UwE10yxw0@andrew.cmu.edu> References: <4.2.0.58.19990915164546.048d0100@localhost> <4.2.0.58.19990915164546.048d0100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 07:21 PM 9/15/99 -0400, Thomas Valentino Crimi wrote: > This was discussed in much detail earlier, but here is the short and >skinny on it: > > DHCP, particularly during installation, is _VERY_ handy. As networks >are being configured today, there are many users that may end up being >left out in the cold, or hat least aving to go through a particular >amount of effort to install. I agree that DHCP is handy, and I don't want to dredge up old ghosts. But the above begs the question: Why is DHCP handled through BPF? > Let's not unncessarily bring up this thread again, so test all posible >arguments against the archives :) A new breakthrough would probably be >welcome, though. In my mind, the general doesn't-recompile-the-kernel >user would especilly not go through the hoops it may take to install >without DHCP support. Which leads to the idea of a kernel config option, similar to the one that lets you set flags for syscons. Maybe this would be the way to turn it on during install but turn it off afterward if it was not needed. Hmmm.... How do you make a driver show up in the configuration editor? --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19:20:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 20343153CF for ; Wed, 15 Sep 1999 19:20:46 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA75319; Wed, 15 Sep 1999 20:20:45 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA17712; Wed, 15 Sep 1999 20:20:08 -0600 (MDT) Message-Id: <199909160220.UAA17712@harmony.village.org> To: GregoryC@stcinc.com Subject: Re: FreeBSD-SA-99:01 File Flags and Man-In-The-Middle Attack Cc: FreeBSD-security@FreeBSD.ORG In-reply-to: Your message of "Wed, 15 Sep 1999 08:43:13 PDT." <37DFBE91.A07AAF8B@stcinc.com> References: <37DFBE91.A07AAF8B@stcinc.com> Date: Wed, 15 Sep 1999 20:20:08 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <37DFBE91.A07AAF8B@stcinc.com> Gregory Carvalho writes: : It appears to me that this exploit can be avoided by logging in as root : on all virtual terminals and immediately logging back out. Does my : theory sound correct? No. It is not. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19:20:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id DA5E9155AC for ; Wed, 15 Sep 1999 19:20:54 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA22557; Wed, 15 Sep 1999 20:20:36 -0600 (MDT) Message-Id: <4.2.0.58.19990915201822.048e0210@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Sep 1999 20:19:18 -0600 To: Nicholas Brawn From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: "Harry M. Leitzell" , security@FreeBSD.ORG In-Reply-To: References: <4.2.0.58.19990915170025.048d0b00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:02 PM 9/16/99 +1000, Nicholas Brawn wrote: >Come on people, this issue is long past dead and buried. It is a simple >matter to [dis|enable] BPF in the kernel. Right now (correct me if I'm wrong, please) it seems to require recompiling the kernel. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19:22:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 687EE153DE for ; Wed, 15 Sep 1999 19:22:09 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA22582; Wed, 15 Sep 1999 20:22:02 -0600 (MDT) Message-Id: <4.2.0.58.19990915201953.048d0ec0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Sep 1999 20:20:48 -0600 To: Bill Fumerola From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: security@freebsd.org In-Reply-To: References: <4.2.0.58.19990915164546.048d0100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:23 PM 9/15/99 -0400, Bill Fumerola wrote: >A better question is: Is it a good idea to ask questions that have been >hashed over in the (publically archived) mailing lists (including the one >you are posting on)? I think that the question above has been beaten to death in the (publicly archived) mailing lists. ;-) --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19:28:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7C80C153B8 for ; Wed, 15 Sep 1999 19:28:13 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA75354; Wed, 15 Sep 1999 20:28:12 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA17782; Wed, 15 Sep 1999 20:27:36 -0600 (MDT) Message-Id: <199909160227.UAA17782@harmony.village.org> To: "Kelsey Cummings" Subject: Re: FreeBSD Vulnerabilities in wu-ftpd and proftpd (J-068) Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Wed, 15 Sep 1999 14:17:59 PDT." <0e6f01beffbf$c991bb00$33f9c9d0@neteze.com> References: <0e6f01beffbf$c991bb00$33f9c9d0@neteze.com> Date: Wed, 15 Sep 1999 20:27:36 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- In message <0e6f01beffbf$c991bb00$33f9c9d0@neteze.com> "Kelsey Cummings" writes: : Is checking out the lastest verision of wu-ftpd (wu-ftpd-2.4.2-vr17?) from : the ports collection (cvs co wu-ftpd) fix this vulnerablity, I'm relatively : new to this and it wasn't clear in the bulitin what versions were affected, : only that those previous to August 30, 1999 are. Thanks. proftpd is still broken. Don't use it. If you build the wu-ftpd port checked out after August 30, 1999 then you are safe. Otherwise you likely aren't. Many old versions of wu-ftpd are vulnerable. The exact details are available at ftp://ftp.wu-ftpd.org/pub/wu-ftpd/2.5.0.Security.Update.asc Warner Losh FreeBSD Security Officer -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBN+BVj1UuHi5z0oilAQESGwP8CQNDDGvI60pwG/On0tHluPU6GpwFkEVx QpEFbejj2FYbYi8oFqsh7h+eRIqJM0pLDI1TEEOhn0WNZ7u9PmJGClII0qFP9fPK MukYUkfvatk2NABE5QhupTu3uzhoxYfEcftChD0HCAmv/ARud2BFVaat87gxGXwL 3Nz8RTpa63Q= =6sJu -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19:29:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 208EE153D9 for ; Wed, 15 Sep 1999 19:29:22 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA75362; Wed, 15 Sep 1999 20:29:21 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA17804; Wed, 15 Sep 1999 20:28:44 -0600 (MDT) Message-Id: <199909160228.UAA17804@harmony.village.org> To: "Harry M. Leitzell" Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Brett Glass , security@FreeBSD.ORG In-reply-to: Your message of "Wed, 15 Sep 1999 18:59:45 EDT." References: Date: Wed, 15 Sep 1999 20:28:44 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message "Harry M. Leitzell" writes: : Correct me if I am wrong, but didn't the list have a huge : arguement over this a while back and the decision was to leave it in for : some reasons that someone dreamed up? Anyone who didn't see the issue : brought up, might want to check the list logs (Wherever they might be) for : 3.2 or another release. Short answer: The convenience of DHCP overrode whatever perceived benefits from leaving it out got you. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 19:33: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 95E6E1524D for ; Wed, 15 Sep 1999 19:32:57 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA75382; Wed, 15 Sep 1999 20:32:56 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA17841; Wed, 15 Sep 1999 20:32:19 -0600 (MDT) Message-Id: <199909160232.UAA17841@harmony.village.org> To: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: "Harry M. Leitzell" , security@FreeBSD.ORG In-reply-to: Your message of "Wed, 15 Sep 1999 17:09:23 MDT." <4.2.0.58.19990915170025.048d0b00@localhost> References: <4.2.0.58.19990915170025.048d0b00@localhost> <4.2.0.58.19990915164546.048d0100@localhost> Date: Wed, 15 Sep 1999 20:32:19 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990915170025.048d0b00@localhost> Brett Glass writes: : Maybe it's a religious issue, or maybe some utility depends on it. It is a religious issue AND some utility depends on it. DHCP requires it. : But it might not be a good idea to let it be on from the get-go. The DHCP client needs it. : If the machine is rooted, you've got an instant packet sniffer. If the machine is rooted, you are in big trouble anyway. Also, there are many ways that you can make a machine that doesn't have it enabled you can sniff packets from. The added security is an illusion. If you care about your network traffic disclosure, encrypt everything. : I plan to turn it off on EVERY install, and I sure wish it : were that way to start. I'm happy for you. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 20:20:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id BF90F14DC6 for ; Wed, 15 Sep 1999 20:20:15 -0700 (PDT) (envelope-from bryanf@shogun.apt.samurai.com) Received: from shogun.apt.samurai.com (HSE-TOR-ppp47561.sympatico.ca [206.172.3.214]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id XAA21778 for ; Wed, 15 Sep 1999 23:23:50 -0400 (EDT) Received: (from bryanf@localhost) by shogun.apt.samurai.com (8.9.1b+Sun/8.9.1) id XAA02326 for freebsd-security@FreeBSD.ORG; Wed, 15 Sep 1999 23:20:12 -0400 (EDT) Date: Wed, 15 Sep 1999 23:20:12 -0400 From: Bryan Fullerton To: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Vulnerabilities in wu-ftpd and proftpd (J-068) Message-ID: <19990915232012.N1225@samurai.com> References: <0e6f01beffbf$c991bb00$33f9c9d0@neteze.com> <199909160227.UAA17782@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <199909160227.UAA17782@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 15, 1999 at 08:27:36PM -0600, Warner Losh wrote: > > proftpd is still broken. Don't use it. > > If you build the wu-ftpd port checked out after August 30, 1999 then > you are safe. Otherwise you likely aren't. If I'm using the FreeBSD ftpd from 3.2-R am I safe? (just want to be sure) Bryan -- Bryan Fullerton http://www.samurai.com/ Core Competency Samurai Consulting "No, we don't do seppuku." Can you feel the Ohmu call? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 20:21:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id CD8C414DC6 for ; Wed, 15 Sep 1999 20:21:50 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Thu, 16 Sep 1999 13:19:34 +1000 Date: Thu, 16 Sep 1999 13:21:41 +1000 From: Peter Jeremy Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: <4.2.0.58.19990915201332.048da870@localhost> To: brett@lariat.org Cc: freebsd-security@FreeBSD.ORG Message-Id: <99Sep16.131934est.40325@border.alcanet.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > Why is DHCP handled through BPF? Please go and read the archives, where this is discussed in detail. Briefly, a DHCP client needs to be able to both send and receive IP packets before its interface has an IP address. Using the standard 4.4BSD IP stack, the only way a user process (the DHCP client) can receive IP packets is using BPF. I believe Linux has some hooks in its IP stack to work around this. Feel free to provide patches to add a similar facility to the FreeBSD IP stack. >Which leads to the idea of a kernel config option, similar to the one >that lets you set flags for syscons. Feel free to supply patches. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 20:22:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id D7E50152A1 for ; Wed, 15 Sep 1999 20:22:43 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id UAA90985; Wed, 15 Sep 1999 20:22:13 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Brett Glass Cc: Thomas Valentino Crimi , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Wed, 15 Sep 1999 20:16:53 MDT." <4.2.0.58.19990915201332.048da870@localhost> Date: Wed, 15 Sep 1999 20:22:13 -0700 Message-ID: <90982.937452133@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I agree that DHCP is handy, and I don't want to dredge up old ghosts. But > the above begs the question: Why is DHCP handled through BPF? Because it is. If we want to have a productive end to this thread for once, you should fix it and send in diffs. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 20:47:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id DE70A152B5; Wed, 15 Sep 1999 20:47:05 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA75578; Wed, 15 Sep 1999 21:47:04 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: (from root@localhost) by harmony.village.org (8.9.3/8.8.3) id VAA18397; Wed, 15 Sep 1999 21:46:28 -0600 (MDT) Date: Wed, 15 Sep 1999 21:46:28 -0600 (MDT) Message-Id: <199909160346.VAA18397@harmony.village.org> From: FreeBSD Security Officer Subject: FreeBSD Security Advisory: FreeBSD-SA-99:03.ftpd REISSUED Reply-To: security-officer@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-99:03 Security Advisory FreeBSD, Inc. Topic: Three ftp daemons in ports vulnerable to attack. Category: ports Module: wu-ftpd and proftpd Announced: 1999-09-05 Reissued: 1999-09-15 Affects: FreeBSD 3.2 (and earlier) FreeBSD-current and -stable before the correction date. Corrected: FreeBSD-3.3 RELEASE FreeBSD as of 1999/08/30 for wuftpd only (Note: there is only one ports tree which is shared with all FreeBSD branches, so if you are running a -stable version of FreeBSD you will also be impacted.) FreeBSD only: NO Bugtraq Id: proftpd: 612 Patches: NONE I. Background wuftpd, beroftpd and proftpd are all optional portions of the system designed to replace the stock ftpd on a FreeBSD system. They are written and maintained by third parties and are included in the FreeBSD ports collection. II. Problem Description There are different security problems which can lead to remote root access in these ports or packages. The standard ftp daemon which ships with FreeBSD is not impacted by either of these problems. III. Impact Remote users can gain root. IV. Workaround Disable the ftp daemon until you can upgrade your system, or use the stock ftpd that comes with FreeBSD. V. Solution Upgrade your wu-ftpd port to the version in the cvs repository after August 30, 1999. If you are not using the wu-ftpd port, then you should visit their web site and follow instructions there to patch your existing version. beroftpd, which was listed in the original wu-ftpd group's advisory as having a similar problem, has not been corrected as of September 15, 1999. It will not be in the 3.3 release. The port has been marked forbidden and will remain so until the security problems have been corrected. If you are running beroftpd you are encouraged to find if patches are available for it which corrects these problems before enabling it on your system. proftpd, which had different security problems, has not been updated to a safe version as of September 15, 1999. It will not be in the 3.3 release. It will not be in the 3.3 release. The port has been marked forbidden and will remain so until the security problems have been corrected. If you are running proftpd, you are encouraged to find out if there are patches which correct these problems before reenabling it on your system. The previous advisory suggested that any FreeBSD ports version of proftpd after August 30 had the security problems corrected. This has proven to not be the case and was the primary reason for reissuing this advisory. While reissuing the advisory, we added beroftpd since it shares a code history with wu-ftpd. The original advisory mistakenly asserted that proftpd also shared a code history with wuftpd, which is not the case. VI. Credits and Pointers The wu-ftpd advisory can be found at ftp://ftp.wu-ftpd.org/pub/wu-ftpd/2.5.0.Security.Update.asc ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org Security notifications: security-notifications@freebsd.org Security public discussion: freebsd-security@freebsd.org PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBN+BmhFUuHi5z0oilAQFlOAQAiU3kAPurRruiFGfG33OsM3ni86HFpKPZ Hb9pINkP9Fu8qdKD/JKYYSxCLRhJLoqojSHXXpVvhJUOQx+1RVaiVCVNvZhV0ypx 0M/+VEg1IpusbxkTRbNFE6cUrMwAiHvbZepYp41slTiA2MwDV7cqX1yvv1InGU1z HSfQSOB/Kfs= =NPAs -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 20:58:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 914C014A00 for ; Wed, 15 Sep 1999 20:58:30 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id VAA23663; Wed, 15 Sep 1999 21:58:20 -0600 (MDT) Message-Id: <4.2.0.58.19990915215201.0462cdc0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Sep 1999 21:57:07 -0600 To: Peter Jeremy From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <99Sep16.131934est.40325@border.alcanet.com.au> References: <4.2.0.58.19990915201332.048da870@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm sure I can do the latter patch. The former would involve some learning about the innards of the stack, and probably the creation of a separate protocol module that parallels the IPX and Appletalk modules. Guidance on how this is done would be appreciated, since while I now have an idea of how to do NIC drivers I am not that familiar with how to do a new layer above them. --Brett At 01:21 PM 9/16/99 +1000, Peter Jeremy wrote: >Brett Glass wrote: > > Why is DHCP handled through BPF? >Please go and read the archives, where this is discussed in detail. > >Briefly, a DHCP client needs to be able to both send and receive IP >packets before its interface has an IP address. Using the standard >4.4BSD IP stack, the only way a user process (the DHCP client) can >receive IP packets is using BPF. > >I believe Linux has some hooks in its IP stack to work around this. >Feel free to provide patches to add a similar facility to the FreeBSD >IP stack. > > >Which leads to the idea of a kernel config option, similar to the one > >that lets you set flags for syscons. > >Feel free to supply patches. > >Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 21:15:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (law-f177.hotmail.com [209.185.131.240]) by hub.freebsd.org (Postfix) with SMTP id E115614A1E for ; Wed, 15 Sep 1999 21:15:41 -0700 (PDT) (envelope-from skalir@hotmail.com) Received: (qmail 64621 invoked by uid 0); 16 Sep 1999 04:15:41 -0000 Message-ID: <19990916041541.64620.qmail@hotmail.com> Received: from 166.62.215.188 by www.hotmail.com with HTTP; Wed, 15 Sep 1999 21:15:41 PDT X-Originating-IP: [166.62.215.188] From: "skalir scalar" To: freebsd-security@freebsd.org Subject: ipfw and syslogd Date: Wed, 15 Sep 1999 20:15:41 AKDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have syslogd on machineA logging all its stuff to machineB on my LAN with out any problems. I also run ipfw on machineA (its my gateway) Could some one tell me how to setup syslog.conf to log all ipfw logs to like /var/log/firewall.log? Thanks in advance! ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 21:29:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from net72-105.student.yale.edu (net72-105.student.yale.edu [130.132.72.105]) by hub.freebsd.org (Postfix) with ESMTP id 5F28314A1C for ; Wed, 15 Sep 1999 21:29:17 -0700 (PDT) (envelope-from root@net72-105.student.yale.edu) Received: from localhost (root@localhost) by net72-105.student.yale.edu (8.8.8/8.8.8) with ESMTP id AAA02899; Thu, 16 Sep 1999 00:28:52 -0500 (EST) (envelope-from root@net72-105.student.yale.edu) Date: Thu, 16 Sep 1999 00:28:51 -0500 (EST) From: Root To: skalir scalar Cc: freebsd-security@FreeBSD.ORG Subject: Re: ipfw and syslogd In-Reply-To: <19990916041541.64620.qmail@hotmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org put this into your /etc/syslog.conf file: !ipfw *.* /var/log/firewall.log On Wed, 15 Sep 1999, skalir scalar wrote: > I have syslogd on machineA logging all its stuff to machineB on my LAN > with out any problems. I also run ipfw on machineA (its my gateway) > Could some one tell me how to setup syslog.conf to log all ipfw logs > to like /var/log/firewall.log? Thanks in advance! > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 22:26: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E9BF514C88; Wed, 15 Sep 1999 22:25:39 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA75926; Wed, 15 Sep 1999 23:25:38 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: (from root@localhost) by harmony.village.org (8.9.3/8.8.3) id XAA19375; Wed, 15 Sep 1999 23:25:03 -0600 (MDT) Date: Wed, 15 Sep 1999 23:25:03 -0600 (MDT) Message-Id: <199909160525.XAA19375@harmony.village.org> From: FreeBSD Security Officer Subject: FreeBSD Security Advisory: FreeBSD-SA-99:04.core Reply-To: security-officer@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-99:04 Security Advisory FreeBSD, Inc. Topic: Coredumps and symbolic links Category: core Module: kernel Announced: 1999-09-15 Affects: FreeBSD 3.2 (and earlier) FreeBSD-current before the correction date. FreeBSD 3.2-stable before the correction date. FreeBSD 2.2.8-stable before the correction date. Corrected: FreeBSD-3.3 RELEASE FreeBSD-current as of 1999/08/26 FreeBSD-3.2-stable as of 1999/08/26 FreeBSD-2.2.8-stable as of 1999/08/29 The FreeBSD-3.3-RC series of releases are not affected. FreeBSD only: NO Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-99:04/ I. Background As a diagnostic aid to help programmers find bugs in their programs, the system creates core files when an illegal instruction or other fatal error happens. A flaw in the kernel allowed it to follow symbolic links when creating core files. II. Problem Description The fts library functions had a flaw in them where which would lead to a core dump when periodic ran the security checking scripts (or other scripts which traverse trees that can be controlled by users). periodic(3) should limit core size to zero to disable core dumps while it is executing commands, but does not do so. In addition, the kernel should not follow symbolic links. All three of these problems caused a situation where it was possible for an attacker could create or overwrite an arbitrary file on the system with a moderate degree of controll of its contents to cause a problem. III. Impact Local users could gain root access. IV. Workaround One can workaround this problem by preventing core dumps for periodic. This solution is less than completely satisfying, since it only plugs the known exploit hole. None the less, this may provide a short term stopgap solution until a new kernel and/or userland can be installed. # mv /usr/sbin/periodic /usr/sbin/periodic.bin # cat > /usr/sbin/periodic #!/bin/sh ulimit -c 0 /usr/sbin/periodic.bin $* ^D # chmod 555 /usr/sbin/periodic Another alternative would be to update the fts routines to a version newer than 1999/09/02 (for -current or 3.3-stable) or 1999/09/04 (for 2.2.8-stable). However, this requires that you rebuild via "make world" to take effect. V. Solution Please note: there is a separate advisory describing the fts problem and solution. Please see FreeBSD-SA-99:05.fts.asc in the advisories directory for additional information about the fts patch. Apply the following patches to your kernel. They will disallow following symbolic links when creating core files. This will stop this attack, and all similar such attacks. Here's the patch for freebsd-current: *** kern/imgact_elf.c 1999/07/09 19:10:14 1.61 --- kern/imgact_elf.c 1999/08/26 17:32:48 1.62 *************** *** 722,729 **** if (name == NULL) return (EFAULT); /* XXX -- not the best error */ ! NDINIT(&nd, LOOKUP, FOLLOW, UIO_SYSSPACE, name, p); ! error = vn_open(&nd, O_CREAT | FWRITE, S_IRUSR | S_IWUSR); free(name, M_TEMP); if (error) return (error); --- 722,729 ---- if (name == NULL) return (EFAULT); /* XXX -- not the best error */ ! NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_SYSSPACE, name, p); ! error = vn_open(&nd, O_CREAT | FWRITE | O_NOFOLLOW, S_IRUSR | S_IWUSR); free(name, M_TEMP); if (error) return (error); *** kern/imgact_aout.c 1999/05/17 00:53:36 1.52 --- kern/imgact_aout.c 1999/08/26 17:32:48 1.53 *************** *** 264,271 **** name = expand_name(p->p_comm, p->p_ucred->cr_uid, p->p_pid); if (name == NULL) return (EFAULT); /* XXX -- not the best error */ ! NDINIT(&nd, LOOKUP, FOLLOW, UIO_SYSSPACE, name, p); ! error = vn_open(&nd, O_CREAT | FWRITE, S_IRUSR | S_IWUSR); free(name, M_TEMP); if (error) return (error); --- 264,271 ---- name = expand_name(p->p_comm, p->p_ucred->cr_uid, p->p_pid); if (name == NULL) return (EFAULT); /* XXX -- not the best error */ ! NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_SYSSPACE, name, p); ! error = vn_open(&nd, O_CREAT | FWRITE | O_NOFOLLOW, S_IRUSR | S_IWUSR); free(name, M_TEMP); if (error) return (error); Here's the patch for freebsd-3.2-stable: *** kern/imgact_elf.c 1999/07/15 13:01:54 1.44.2.4 --- kern/imgact_elf.c 1999/08/26 17:35:03 1.44.2.5 *************** *** 699,706 **** if (name == NULL) return (EFAULT); /* XXX -- not the best error */ ! NDINIT(&nd, LOOKUP, FOLLOW, UIO_SYSSPACE, name, p); ! error = vn_open(&nd, O_CREAT | FWRITE, S_IRUSR | S_IWUSR); free(name, M_TEMP); if (error) return (error); --- 699,706 ---- if (name == NULL) return (EFAULT); /* XXX -- not the best error */ ! NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_SYSSPACE, name, p); ! error = vn_open(&nd, O_CREAT | FWRITE | O_NOFOLLOW, S_IRUSR | S_IWUSR); free(name, M_TEMP); if (error) return (error); *** kern/imgact_aout.c 1999/04/14 04:55:22 1.44.2.1 --- kern/imgact_aout.c 1999/08/26 17:35:02 1.44.2.2 *************** *** 259,266 **** name = expand_name(p->p_comm, p->p_ucred->cr_uid, p->p_pid); if (name == NULL) return (EFAULT); /* XXX -- not the best error */ ! NDINIT(&nd, LOOKUP, FOLLOW, UIO_SYSSPACE, name, p); ! error = vn_open(&nd, O_CREAT | FWRITE, S_IRUSR | S_IWUSR); free(name, M_TEMP); if (error) return (error); --- 259,266 ---- name = expand_name(p->p_comm, p->p_ucred->cr_uid, p->p_pid); if (name == NULL) return (EFAULT); /* XXX -- not the best error */ ! NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_SYSSPACE, name, p); ! error = vn_open(&nd, O_CREAT | FWRITE | O_NOFOLLOW, S_IRUSR | S_IWUSR); free(name, M_TEMP); if (error) return (error); Here's the patch for FreeBSD-2.2.8-stable *** sys/LINK/fcntl.h Wed Dec 18 05:08:08 1996 --- sys/fcntl.h Fri Aug 27 14:39:26 1999 *************** *** 84,89 **** --- 84,90 ---- #define O_EXLOCK 0x0020 /* open with exclusive file lock */ #define O_ASYNC 0x0040 /* signal pgrp when data ready */ #define O_FSYNC 0x0080 /* synchronous writes */ + #define O_NOFOLLOW 0x0100 /* don't follow symlinks */ #endif #define O_CREAT 0x0200 /* create if nonexistent */ #define O_TRUNC 0x0400 /* truncate to zero length */ *** kern/LINK/kern_sig.c Sat Dec 21 10:57:24 1996 --- kern/kern_sig.c Fri Aug 27 14:38:25 1999 *************** *** 1241,1249 **** p->p_rlimit[RLIMIT_CORE].rlim_cur) return (EFAULT); sprintf(name, "%s.core", p->p_comm); ! NDINIT(&nd, LOOKUP, FOLLOW, UIO_SYSSPACE, name, p); if ((error = vn_open(&nd, ! O_CREAT | FWRITE, S_IRUSR | S_IWUSR))) return (error); vp = nd.ni_vp; --- 1241,1249 ---- p->p_rlimit[RLIMIT_CORE].rlim_cur) return (EFAULT); sprintf(name, "%s.core", p->p_comm); ! NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_SYSSPACE, name, p); if ((error = vn_open(&nd, ! O_CREAT | FWRITE | O_NOFOLLOW, S_IRUSR | S_IWUSR))) return (error); vp = nd.ni_vp; *** kern/LINK/vfs_vnops.c Sat Mar 8 07:16:18 1997 --- kern/vfs_vnops.c Fri Aug 27 14:37:01 1999 *************** *** 87,93 **** if (fmode & O_CREAT) { ndp->ni_cnd.cn_nameiop = CREATE; ndp->ni_cnd.cn_flags = LOCKPARENT | LOCKLEAF; ! if ((fmode & O_EXCL) == 0) ndp->ni_cnd.cn_flags |= FOLLOW; error = namei(ndp); if (error) --- 87,93 ---- if (fmode & O_CREAT) { ndp->ni_cnd.cn_nameiop = CREATE; ndp->ni_cnd.cn_flags = LOCKPARENT | LOCKLEAF; ! if ((fmode & O_EXCL) == 0 && (fmode & O_NOFOLLOW) == 0) ndp->ni_cnd.cn_flags |= FOLLOW; error = namei(ndp); if (error) *************** *** 119,125 **** } } else { ndp->ni_cnd.cn_nameiop = LOOKUP; ! ndp->ni_cnd.cn_flags = FOLLOW | LOCKLEAF; error = namei(ndp); if (error) return (error); --- 119,126 ---- } } else { ndp->ni_cnd.cn_nameiop = LOOKUP; ! ndp->ni_cnd.cn_flags = ! ((fmode & O_NOFOLLOW) ? NOFOLLOW : FOLLOW) | LOCKLEAF; error = namei(ndp); if (error) return (error); *** kern/LINK/vfs_syscalls.c Wed Aug 4 12:44:30 1999 --- kern/vfs_syscalls.c Sat Aug 28 10:48:51 1999 *************** *** 694,699 **** --- 694,701 ---- flags = FFLAGS(uap->flags); if ((flags & FREAD + FWRITE) == 0) return (EINVAL); + if (flags & O_NOFOLLOW) + flags &= ~O_NOFOLLOW; error = falloc(p, &nfp, &indx); if (error) return (error); ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org Security notifications: security-notifications@freebsd.org Security public discussion: freebsd-security@freebsd.org PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBN+B44VUuHi5z0oilAQHkwwP9HeLkRJY/iXIYXUx8/A38EAxM/TAqxoiI ym7ZyktNtuCbum8ovCIfmkpnafaFyXmVSDhCX77LbIy+1clEBnelyueJ9TbKpBgU KWjTWmfj/7QsU2Ya/f7FK80ee8y7GjTTYxilnxxzTmM8ihHzFXrPHudoO4lTR7Op 2VII3pQVxOM= =bJXX -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 22:26:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id AB24314D04; Wed, 15 Sep 1999 22:25:57 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA75930; Wed, 15 Sep 1999 23:25:56 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: (from root@localhost) by harmony.village.org (8.9.3/8.8.3) id XAA19379; Wed, 15 Sep 1999 23:25:21 -0600 (MDT) Date: Wed, 15 Sep 1999 23:25:21 -0600 (MDT) Message-Id: <199909160525.XAA19379@harmony.village.org> From: FreeBSD Security Officer Subject: FreeBSD Security Advisory: FreeBSD-SA-99:05.fts Reply-To: security-officer@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-99:05 Security Advisory FreeBSD, Inc. Topic: fts library routine vulnerability Category: core Module: kernel Announced: 1999-09-15 Affects: FreeBSD 3.2 (and earlier) FreeBSD-current before the correction date. FreeBSD 3.2-stable before the correction date. Corrected: FreeBSD-3.3 RELEASE FreeBSD-current as of 1999/08/26 FreeBSD-3.2-stable as of 1999/08/26 The FreeBSD-3.3-RC series of releases are not affected. FreeBSD only: NO Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-99:05/ I. Background The fts library routines provide a convenient way for a program to walk a hierarchy of files. II. Problem Description The fts library functions had a buffer overflow in them where which would lead to a core dump when periodic ran the security checking scripts (or other scripts which traverse trees that can be controlled by users). periodic(3) should limit core size to zero to disable core dumps while it is executing commands, but does not do so. In addition, the kernel should not follow symbolic links. All three of these problems caused a situation where it was possible for an attacker could create or overwrite an arbitrary file on the system with a moderate degree of controll of its contents to cause a problem. III. Impact Local users could gain root access. IV. Workaround One can workaround this problem by preventing core dumps for periodic. This solution is less than completely satisfying, since it only plugs the known exploit hole. None the less, this may provide a short term stopgap solution until a new kernel and userland can be installed. # mv /usr/sbin/periodic /usr/sbin/periodic.bin # cat > /usr/sbin/periodic #!/bin/sh ulimit -c 0 /usr/sbin/periodic.bin $* ^D # chmod 555 /usr/sbin/periodic V. Solution Apply the following patches to libc and do a make world. Please also see the companion advisory FreeBSD-SA-99:04.core.asc in the advisories directory of our ftp site for details on the kernel portions of this fix. Index: lib/libc/gen/fts.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/gen/fts.c,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- fts.c 1999/08/15 19:21:29 1.10 +++ fts.c 1999/09/02 07:45:07 1.11 @@ -963,6 +963,24 @@ return (sp->fts_path == NULL); } +static void +ADJUST(p, addr) + FTSENT *p; + void *addr; +{ + if ((p)->fts_accpath >= (p)->fts_path && + (p)->fts_accpath < (p)->fts_path + (p)->fts_pathlen) { + if (p->fts_accpath != p->fts_path) + errx(1, "fts ADJUST: accpath %p path %p", + p->fts_accpath, p->fts_path); + if (p->fts_level != 0) + errx(1, "fts ADJUST: level %d not 0", p->fts_level); + (p)->fts_accpath = + (char *)addr + ((p)->fts_accpath - (p)->fts_path); + } + (p)->fts_path = addr; +} + /* * When the path is realloc'd, have to fix all of the pointers in structures * already returned. @@ -974,18 +992,18 @@ { FTSENT *p; -#define ADJUST(p) { \ - (p)->fts_accpath = \ - (char *)addr + ((p)->fts_accpath - (p)->fts_path); \ +#define ADJUST1(p) { \ + if ((p)->fts_accpath == (p)->fts_path) \ + (p)->fts_accpath = (addr); \ (p)->fts_path = addr; \ } /* Adjust the current set of children. */ for (p = sp->fts_child; p; p = p->fts_link) - ADJUST(p); + ADJUST(p, addr); /* Adjust the rest of the tree. */ for (p = sp->fts_cur; p->fts_level >= FTS_ROOTLEVEL;) { - ADJUST(p); + ADJUST(p, addr); p = p->fts_link ? p->fts_link : p->fts_parent; } } ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org Security notifications: security-notifications@freebsd.org Security public discussion: freebsd-security@freebsd.org PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBN+B9rFUuHi5z0oilAQHGYgP+IwrmdUBtCw1r8J/lt/wBrxH5wug70K1V t2graun2wIWvtkh+kmwKJP4tonzlxi/YhyqqATh4pFIZb5CUEtCR2/gcpHPwB4NX oNuIGGBtKftrrFnPf9aArFu/XFjrxyUPetYoXtfgGc5y6VlI6mupDnwt9oj34EeY VIb92qSfH+c= =tPng -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 15 23:44:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from drip.puddle.net (cx288885-b.okcs1.ok.home.com [24.4.98.148]) by hub.freebsd.org (Postfix) with ESMTP id BC48614BE4 for ; Wed, 15 Sep 1999 23:44:13 -0700 (PDT) (envelope-from river@theriver.nu) Received: by cx288885-b.okcs1.ok.home.com with Internet Mail Service (5.5.2232.9) id ; Thu, 16 Sep 1999 01:48:47 -0500 Message-ID: <21DC5E98AE1FD311B1290020AFDB6C6E63DD@cx288885-b.okcs1.ok.home.com> From: river To: "'freebsd-security@FreeBSD.ORG'" Subject: RE: ipfw and syslogd Date: Thu, 16 Sep 1999 01:48:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org is there anything else that needs to be done ? I just got ipfw setup and put this in the syslog.conf and rebooted the box and it still isnt logging. I have verbose turned on in the kernel (3.2-release) -----Original Message----- From: Root [mailto:root@net72-105.student.yale.edu] Sent: Thursday, September 16, 1999 12:29 AM To: skalir scalar Cc: freebsd-security@FreeBSD.ORG Subject: Re: ipfw and syslogd put this into your /etc/syslog.conf file: !ipfw *.* /var/log/firewall.log On Wed, 15 Sep 1999, skalir scalar wrote: > I have syslogd on machineA logging all its stuff to machineB on my LAN > with out any problems. I also run ipfw on machineA (its my gateway) > Could some one tell me how to setup syslog.conf to log all ipfw logs > to like /var/log/firewall.log? Thanks in advance! > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 1:56:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 76A0014D5E for ; Thu, 16 Sep 1999 01:56:35 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA29335; Thu, 16 Sep 1999 10:56:30 +0200 (CEST) (envelope-from des) To: Root Cc: skalir scalar , freebsd-security@FreeBSD.ORG Subject: Re: ipfw and syslogd References: From: Dag-Erling Smorgrav Date: 16 Sep 1999 10:56:29 +0200 In-Reply-To: Root's message of "Thu, 16 Sep 1999 00:28:51 -0500 (EST)" Message-ID: Lines: 9 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Root writes: > !ipfw > *.* /var/log/firewall.log Won't work in -STABLE, because ip_fw.c uses printf() instead of log(). DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 2:10:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from hsh.sita.kiev.ua (hsh.sita.kiev.ua [62.244.14.66]) by hub.freebsd.org (Postfix) with ESMTP id 810891541A for ; Thu, 16 Sep 1999 02:10:15 -0700 (PDT) (envelope-from ay@sita.kiev.ua) Received: (from ay@localhost) by hsh.sita.kiev.ua (8.Who.Cares/8.Who.Cares) id MAA01356 for freebsd-security@freebsd.org; Thu, 16 Sep 1999 12:10:13 +0300 (EEST) (envelope-from ay) Date: Thu, 16 Sep 1999 12:10:13 +0300 (EEST) From: Alexander Yeremenko Message-Id: <199909160910.MAA01356@hsh.sita.kiev.ua> To: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Newsgroups: lucky.freebsd.security Path: hsh.sita.kiev.ua!ay From: ay@sita.kiev.ua.europe Subject: Re: ipfw and syslogd User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/3.1-RELEASE (i386)) Sender: ay@sita.kiev.ua.europe (Alexander Yeremenko) Organization: Home Sweet Home Message-ID: References: <19990916041541.64620.qmail@hotmail.com> Date: Thu, 16 Sep 1999 09:10:12 GMT skalir scalar wrote: > I have syslogd on machineA logging all its stuff to machineB on my LAN > with out any problems. I also run ipfw on machineA (its my gateway) > Could some one tell me how to setup syslog.conf to log all ipfw logs > to like /var/log/firewall.log? Thanks in advance! ipfw stuff is not a standalone program, but only a part of kernel code. It doesn't uses syslog, but writes it's messages to console and stores them in internal buffer. (/sbin/ipfw is only an interface to this stuff Do not think, it's log messages may be importaint :)) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 3:36:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8503A15053 for ; Thu, 16 Sep 1999 03:36:18 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA30080; Thu, 16 Sep 1999 12:36:07 +0200 (CEST) (envelope-from des) To: Alexander Yeremenko Cc: freebsd-security@FreeBSD.ORG Subject: Re: none References: <199909160910.MAA01356@hsh.sita.kiev.ua> From: Dag-Erling Smorgrav Date: 16 Sep 1999 12:36:03 +0200 In-Reply-To: Alexander Yeremenko's message of "Thu, 16 Sep 1999 12:10:13 +0300 (EEST)" Message-ID: Lines: 11 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alexander Yeremenko writes: > ipfw stuff is not a standalone program, but only a part of kernel > code. It doesn't uses syslog, but writes it's messages to console and > stores them in internal buffer. Correct, but that's a bug (or rather sloppy design), not expected behaviour. It's been fixed in -CURRENT. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 5:37:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.249.195.3]) by hub.freebsd.org (Postfix) with ESMTP id 6C2651539A for ; Thu, 16 Sep 1999 05:37:17 -0700 (PDT) (envelope-from paulo@nlink.com.br) Received: from localhost (paulo@localhost) by mirage.nlink.com.br (8.9.3/8.9.1) with SMTP id JAA13879 for ; Thu, 16 Sep 1999 09:37:12 -0300 (EST) Date: Thu, 16 Sep 1999 09:37:12 -0300 (EST) From: Paulo Fragoso To: freebsd-security@freebsd.org Subject: make world to FreeBSD-SA-99:05.fts In-Reply-To: <199909160525.XAA19379@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, On Wed, 15 Sep 1999, FreeBSD Security Officer wrote: > V. Solution > > Apply the following patches to libc and do a make world. Please also > see the companion advisory FreeBSD-SA-99:04.core.asc in the advisories > directory of our ftp site for details on the kernel portions of this > fix. > > Index: lib/libc/gen/fts.c > =================================================================== > RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/gen/fts.c,v We've a doubt. Can we aplly this patch and only make and make install on /usr/src/lib/libc instead make world on /usr/src? Thanks, Paulo. ------ " ... Overall we've found FreeBSD to excel in performace, stability, technical support, and of course price. Two years after discovering FreeBSD, we have yet to find a reason why we switch to anything else" -David Filo, Yahoo! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 6:21:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from alfik.ms.mff.cuni.cz (alfik.ms.mff.cuni.cz [195.113.19.71]) by hub.freebsd.org (Postfix) with ESMTP id 1A7A11546C for ; Thu, 16 Sep 1999 06:20:51 -0700 (PDT) (envelope-from mencl@nenya.ms.mff.cuni.cz) Received: from nenya.ms.mff.cuni.cz by alfik.ms.mff.cuni.cz; (8.8.8/v1.00/19990210.0854) id PAA13788; Thu, 16 Sep 1999 15:20:45 +0200 (MET DST) Received: from localhost (mencl@localhost) by nenya.ms.mff.cuni.cz (8.9.1b+Sun/8.9.1) with ESMTP id PAA03508; Thu, 16 Sep 1999 15:20:44 +0200 (MET DST) Date: Thu, 16 Sep 1999 15:20:44 +0200 (MET DST) From: "Vladimir Mencl, MK, susSED" To: Paulo Fragoso Cc: freebsd-security@FreeBSD.ORG Subject: Re: make world to FreeBSD-SA-99:05.fts In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 16 Sep 1999, Paulo Fragoso wrote: > Hi, > > On Wed, 15 Sep 1999, FreeBSD Security Officer wrote: > > > V. Solution > > > > Apply the following patches to libc and do a make world. Please also > > see the companion advisory FreeBSD-SA-99:04.core.asc in the advisories > > directory of our ftp site for details on the kernel portions of this > > fix. > > > > Index: lib/libc/gen/fts.c > > =================================================================== > > RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/gen/fts.c,v > > We've a doubt. Can we aplly this patch and only make and make install on > /usr/src/lib/libc instead make world on /usr/src? It won't make a complete fix. find(1) is dynamically linked, so this ocurrence of the bug would be fixed, but rm(1), cp(1), mv(1) are all linked statically - they need to be recompiled with the new library... Vlada Mencl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 7: 9:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 706AA15464 for ; Thu, 16 Sep 1999 07:09:33 -0700 (PDT) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA01927; Thu, 16 Sep 1999 07:09:28 -0700 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda01925; Thu Sep 16 07:09:11 1999 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id HAA06535; Thu, 16 Sep 1999 07:09:09 -0700 (PDT) Message-Id: <199909161409.HAA06535@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdzv6531; Thu Sep 16 07:09:00 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.2-RELEASE X-Sender: cy To: Brett Glass Cc: Darren Reed , Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Wed, 15 Sep 1999 20:12:54 MDT." <4.2.0.58.19990915200910.048dba50@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Sep 1999 07:09:00 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990915200910.048dba50@localhost>, Brett Glass writes: > At 09:21 AM 9/16/99 +1000, Darren Reed wrote: > > >If the machine is rooted, you're fucked anyway, unless it's so wired > >down with things using file flags that you can't even use vi any more. > > Well, setting securelevel and making certain key files, like the kernel, > immutable helps immensely. > > Say, there's a thought. Would it be possible to make a high security > level "lock down" BPF? Or would it be possible to disable it via > a kernel config option? One could run the kernel configuration > utility to enable or disable it at boot. How about a compromise? Leave BPF in the generic kernel but add a boot option to disable it, then a site can create a loader.conf to to disable it. To enable it an intruder would have to modify loader.conf and reboot. This would surely be noticed -- noticed as much as an intruder building a new kernel with BPF and rebooting. This approach will have the advantage of leaving BPF disabled even after an upgrade. To satisfy any new install requirements, create a sysinstall option or question to disable it during install. We could even create a make.conf option to add this option to loader.conf during make installworld. Personally, I don't see why people are so impassioned about this. I and my team build a custom kernels for each FreeBSD, Tru64 UNIX, and Linux system we maintain and usually maintain custom /etc/system files for our Solaris boxes. We put in the kernel only what the kernel will use on a system, making the kernel as small as possible. Normally we disable BPF, however in cases where customers (usually developers) have many complaints about inaccessibility of a host or service, we turn on BPF, as it helps diagnose problems much more quickly. If you build custom kernels, as I think one should, this whole issue is irrelevant. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 7:30:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from drip.puddle.net (cx288885-b.okcs1.ok.home.com [24.4.98.148]) by hub.freebsd.org (Postfix) with ESMTP id 1EBA514DDC for ; Thu, 16 Sep 1999 07:30:38 -0700 (PDT) (envelope-from river@theriver.nu) Received: by cx288885-b.okcs1.ok.home.com with Internet Mail Service (5.5.2232.9) id ; Thu, 16 Sep 1999 09:35:11 -0500 Message-ID: <21DC5E98AE1FD311B1290020AFDB6C6E63E1@cx288885-b.okcs1.ok.home.com> From: river To: "'freebsd-security@FreeBSD.ORG'" Subject: mapping ports from outside to inside (with ipfw ?) Date: Thu, 16 Sep 1999 09:35:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there built in support to map the ports from the outside of the firewall/gateway machine to an internal server inside the firewall/gateway machine ? Or do I need to use another program for this ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 7:42: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by hub.freebsd.org (Postfix) with ESMTP id 86A9514DDC for ; Thu, 16 Sep 1999 07:42:00 -0700 (PDT) (envelope-from Harry_M_Leitzell@cmu.edu) Received: from unix3.andrew.cmu.edu (UNIX3.ANDREW.CMU.EDU [128.2.15.7]) by smtp2.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id KAA20840; Thu, 16 Sep 1999 10:41:56 -0400 (EDT) Date: Thu, 16 Sep 1999 10:41:56 -0400 (EDT) From: "Harry M. Leitzell" X-Sender: Harry_M_Leitzell@unix3.andrew.cmu.edu To: river Cc: "'freebsd-security@FreeBSD.ORG'" Subject: Re: mapping ports from outside to inside (with ipfw ?) In-Reply-To: <21DC5E98AE1FD311B1290020AFDB6C6E63E1@cx288885-b.okcs1.ok.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think 'man natd' might help you with what you want to do. On Thu, 16 Sep 1999, river wrote: > Is there built in support to map the ports from the outside of the > firewall/gateway machine to an internal server inside the firewall/gateway > machine ? Or do I need to use another program for this ? > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > [-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] Harry M. Leitzell - Harry_M_Leitzell@cmu.edu Carnegie Mellon University Finger for PGP Public Key [-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 7:44:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from drip.puddle.net (cx288885-b.okcs1.ok.home.com [24.4.98.148]) by hub.freebsd.org (Postfix) with ESMTP id 5503414FBC for ; Thu, 16 Sep 1999 07:44:46 -0700 (PDT) (envelope-from river@theriver.nu) Received: by cx288885-b.okcs1.ok.home.com with Internet Mail Service (5.5.2232.9) id ; Thu, 16 Sep 1999 09:49:19 -0500 Message-ID: <21DC5E98AE1FD311B1290020AFDB6C6E63E2@cx288885-b.okcs1.ok.home.com> From: river To: "'Harry M. Leitzell'" Cc: "'freebsd-security@FreeBSD.ORG'" Subject: RE: mapping ports from outside to inside (with ipfw ?) Date: Thu, 16 Sep 1999 09:49:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I did that....it talks about the -redirec_address command, but it applies as mentioned to IP only....so all traffic would be destined for the internal machine....not just ONE port, which is what I am looking for -----Original Message----- From: Harry M. Leitzell [mailto:Harry_M_Leitzell@cmu.edu] Sent: Thursday, September 16, 1999 9:42 AM To: river Cc: 'freebsd-security@FreeBSD.ORG' Subject: Re: mapping ports from outside to inside (with ipfw ?) I think 'man natd' might help you with what you want to do. On Thu, 16 Sep 1999, river wrote: > Is there built in support to map the ports from the outside of the > firewall/gateway machine to an internal server inside the firewall/gateway > machine ? Or do I need to use another program for this ? > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > [-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] Harry M. Leitzell - Harry_M_Leitzell@cmu.edu Carnegie Mellon University Finger for PGP Public Key [-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 7:52:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.interact.se (smtp1.interact.se [193.15.98.9]) by hub.freebsd.org (Postfix) with ESMTP id F3B6914F6D for ; Thu, 16 Sep 1999 07:52:09 -0700 (PDT) (envelope-from je@interact.se) Received: from wolfie.interact.se (wolfie.interact.se [193.15.98.202]) by smtp.interact.se (InterACT Mailer) with ESMTP id QAA14899; Thu, 16 Sep 1999 16:51:39 +0200 (CEST) Date: Thu, 16 Sep 1999 16:51:54 +0200 (CEST) From: Jonas Eriksson To: river Cc: "'Harry M. Leitzell'" , "'freebsd-security@FreeBSD.ORG'" Subject: RE: mapping ports from outside to inside (with ipfw ?) In-Reply-To: <21DC5E98AE1FD311B1290020AFDB6C6E63E2@cx288885-b.okcs1.ok.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Use -redirect_port then. =20 You can also check plug-gw from TIS Firewall Toolkit. Regards Jonas Eriksson -- InterACT Lule=E5 Network & Security Administrator Tel: +46 (0)920 88803 - Fax: +46 (0)920 88399 Current temp in Lulea/Sweden is 10.0C (50.0F) On Thu, 16 Sep 1999, river wrote: > I did that....it talks about the -redirec_address command, but it applies= as > mentioned to IP only....so all traffic would be destined for the internal > machine....not just ONE port, which is what I am looking for=20 >=20 > -----Original Message----- > From: Harry M. Leitzell [mailto:Harry_M_Leitzell@cmu.edu] > Sent: Thursday, September 16, 1999 9:42 AM > To: river > Cc: 'freebsd-security@FreeBSD.ORG' > Subject: Re: mapping ports from outside to inside (with ipfw ?) >=20 >=20 > I think 'man natd' might help you with what you want to do. >=20 > On Thu, 16 Sep 1999, river wrote: >=20 > > Is there built in support to map the ports from the outside of the > > firewall/gateway machine to an internal server inside the firewall/gate= way > > machine ? Or do I need to use another program for this ? > >=20 > >=20 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > >=20 >=20 > [-=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D= -=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D-] > =09Harry M. Leitzell - Harry_M_Leitzell@cmu.edu > =09=09Carnegie Mellon University > =09=09Finger for PGP Public Key > [-=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D= -=3D--=3D-=3D--=3D-=3D--=3D-=3D--=3D-] >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 8: 0:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from pinochet.cityline.ru (pinochet.cityline.ru [195.46.160.34]) by hub.freebsd.org (Postfix) with ESMTP id 8264014F6D for ; Thu, 16 Sep 1999 08:00:24 -0700 (PDT) (envelope-from g16@mail.ru) Received: from admin (140.166.fx.dialup.cityline.ru [195.46.166.140]) by pinochet.cityline.ru (8.9.2/t/08-Oct-1998) with SMTP id SAA02548; Thu, 16 Sep 1999 18:53:55 +0400 (MSD) Message-ID: <001e01bf0053$7d1e8160$0801a8c0@admin.uzdw-centre.ru> Reply-To: "Oleg Y. Ivanov" From: "Oleg Y. Ivanov" To: "river" Cc: Subject: RE: mapping ports from outside to inside (with ipfw ?) Date: Thu, 16 Sep 1999 18:54:23 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01BF0074.E41A5300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0019_01BF0074.E41A5300 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable >I did that....it talks about the -redirec_address command, but it = applies as >mentioned to IP only....so all traffic would be destined for the = internal >machine....not just ONE port, which is what I am looking for=20 =20 what about -redirect_port ? =20 try this : =20 use_sockets yes same_ports yes deny_incoming no dynamic yes interface redirect_port : -------------------------------------------------------------------------= ------- Sincerely Yours , Oleg Y. Ivanov : sysadmin & DBA of UzDaewoo Centre , = Moscow=20 PGP fingerprint : EDDD D812 E895 FFF1 BA34 39A4 044E 6E8D 0C0E 64FC=20 ------=_NextPart_000_0019_01BF0074.E41A5300 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
>I did that....it talks about the = -redirec_address command,=20 but it applies as
>mentioned to IP only....so all traffic would be = destined for the internal
>machine....not just ONE port, which is = what I=20 am looking for
 
what about -redirect_port ?
 
try this :
 
use_sockets yes
same_ports yes
deny_incoming=20 no
dynamic yes
interface = <your_outside_intf_here>
redirect_port <proto> =20 <internal_host>:<port>  <external_port>
Sincerely Yours , Oleg Y.=20 Ivanov : sysadmin & DBA of UzDaewoo Centre , Moscow

PGP=20 fingerprint : EDDD D812 E895 FFF1 BA34 39A4 044E 6E8D 0C0E 64FC=20
------=_NextPart_000_0019_01BF0074.E41A5300-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 8: 4:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from mag.ik.nu (mail.olm.nl [194.151.118.79]) by hub.freebsd.org (Postfix) with ESMTP id 3DDDD153FA for ; Thu, 16 Sep 1999 08:04:07 -0700 (PDT) (envelope-from ralphm@wat.moet.ik.nu) Received: (from ralphm@localhost) by mag.ik.nu (8.9.1/8.9.1) id RAA01915 for freebsd-security@freebsd.org; Thu, 16 Sep 1999 17:04:07 +0200 (CEST) Message-Id: <199909161504.RAA01915@mag.ik.nu> Subject: Re: mapping ports from outside to inside (with ipfw ?) In-Reply-To: <21DC5E98AE1FD311B1290020AFDB6C6E63E1@cx288885-b.okcs1.ok.home.com> from river at "Sep 16, 99 09:35:10 am" To: river@theriver.nu (river) Date: Thu, 16 Sep 1999 17:02:23 +0200 (CEST) From: bsdseq@mail.ik.nu X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Is there built in support to map the ports from the outside of the > firewall/gateway machine to an internal server inside the firewall/gateway > machine ? Or do I need to use another program for this ? > > Try rinetd (/usr/ports/net/rinetd). It works for tcp, and you can specify outside ports and addresses and corresponding inside ports and addresses. Does some logging and access-control too, I believe... Greetz, Ralphm (Ralph Meijer) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 8:37: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from mag.ik.nu (mail.olm.nl [194.151.118.79]) by hub.freebsd.org (Postfix) with ESMTP id 8963115699 for ; Thu, 16 Sep 1999 08:37:00 -0700 (PDT) (envelope-from ralphm@wat.moet.ik.nu) Received: (from ralphm@localhost) by mag.ik.nu (8.9.1/8.9.1) id RAA02357 for freebsd-security@freebsd.org; Thu, 16 Sep 1999 17:37:02 +0200 (CEST) Message-Id: <199909161537.RAA02357@mag.ik.nu> Subject: Re: mapping ports from outside to inside (with ipfw ?) In-Reply-To: from Pat Lynch at "Sep 16, 99 11:28:06 am" To: freebsd-security@freebsd.org From: bsdseq@mail.ik.nu Date: Thu, 16 Sep 1999 17:35:00 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, but I understood he was trying to redirect ports from specific (alias-) addresses to the inside. While this can be done with natd, I find it not so convienient to put all those redirects in /etc/rc.conf. (Yes, they can also be in a file, I know). The logging is quite nice too, though... Ralphm > I use natd, its no problem and relatively simple. > > make sure you have IP_DIVERT in the kernel (to go along with all the > firewall stuff. > > then: > > /sbin/natd -redirect_port tcp totem:113 113 -redirect_port tcp \ > different:80 80 -interface tun0 > /sbin/ipfw add divert 8668 ip from any to any via tun0 > > I'm redirecting the port 113 (ident) from the outside to my workstation > (for irc actually) and port 80 to my sparc for web serving. > > -Pat > > ... snip ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 9:16:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 79112151C9 for ; Thu, 16 Sep 1999 09:16:45 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id KAA29252; Thu, 16 Sep 1999 10:16:27 -0600 (MDT) Message-Id: <4.2.0.58.19990916100439.048ebd70@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 16 Sep 1999 10:15:02 -0600 To: Cy Schubert - ITSD Open Systems Group From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Darren Reed , Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG In-Reply-To: <199909161409.HAA06535@cwsys.cwsent.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bob Vaughan has sent me e-mail stating that he doesn't want this discussion to erupt into the tug of war it did last time, and wanted to kill it. After looking over the archives, I can see why! However, there are several useful and productive ideas in Cy's message that are definitely NOT flamage, so I'd like to send a short message in support of them. At 07:09 AM 9/16/99 -0700, Cy Schubert - ITSD Open Systems Group wrote: >How about a compromise? Leave BPF in the generic kernel but add a boot >option to disable it, then a site can create a loader.conf to to >disable it. To enable it an intruder would have to modify loader.conf >and reboot. This would surely be noticed -- noticed as much as an >intruder building a new kernel with BPF and rebooting. This approach >will have the advantage of leaving BPF disabled even after an upgrade. Yep, and if someone tries to turn it on, Tripwire will catch them. To do this, the BPF driver needs to have a visible switch you can hit to disable it, as do other drivers. I forget the exact data structures involved, but I know it's not hard. Anyone have this information on the top of his/her head? >To satisfy any new install requirements, create a sysinstall option or >question to disable it during install. We could even create a >make.conf option to add this option to loader.conf during make >installworld. I like this idea too. >Personally, I don't see why people are so impassioned about this. I >and my team build a custom kernels for each FreeBSD, Tru64 UNIX, and >Linux system we maintain and usually maintain custom /etc/system files >for our Solaris boxes. We put in the kernel only what the kernel will >use on a system, making the kernel as small as possible. Normally we >disable BPF, however in cases where customers (usually developers) have >many complaints about inaccessibility of a host or service, we turn on >BPF, as it helps diagnose problems much more quickly. > >If you build custom kernels, as I think one should, this whole issue is >irrelevant. I build custom kernels a LOT. But some of my clients go out and buy a FreeBSD disk (on my advice) and put up new machines without knowing the first thing about compiling a kernel. They then have a potential sniffer on their network, and adding Tripwire won't help unearth abuses. Since this is probably an easy PR, let's at least submit it. Again, can anyone here coach or remind me about that data structure? --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 9:19:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from peloton.runet.edu (peloton.runet.edu [137.45.96.205]) by hub.freebsd.org (Postfix) with ESMTP id 43549151B9 for ; Thu, 16 Sep 1999 09:19:56 -0700 (PDT) (envelope-from brett@peloton.runet.edu) Received: from localhost (brett@localhost) by peloton.runet.edu (8.9.3/8.9.3) with ESMTP id MAA31549; Thu, 16 Sep 1999 12:19:45 -0400 (EDT) (envelope-from brett@peloton.runet.edu) Date: Thu, 16 Sep 1999 12:19:45 -0400 (EDT) From: Brett Taylor To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4.2.0.58.19990915164546.048d0100@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi On Wed, 15 Sep 1999, Brett Glass wrote: > Was doing some testing on the latest release candidate of FreeBSD 3.3, > and noted that the Berkeley Packet Filter was enabled in the GENERIC > kernel. Is this a good idea? Um, not this thread again?!?!?! Go read the -hackers list (or -stable I can't recall which) and read the month long thread when this was discussed. Brett ***************************************************** Brett Taylor brett@peloton.runet.edu * Dept of Chem and Physics * Curie 39A (540) 831-6147 * ***************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 10:13:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id DC5C114BD6 for ; Thu, 16 Sep 1999 10:13:47 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id NAA19271 for ; Thu, 16 Sep 1999 13:13:43 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 16 Sep 1999 13:13:43 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-security@freebsd.org Subject: Re: Is this list dead (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thought people might be interested to know about SGI's Trusted Linux work--nice that they have staffing. Anyone got any money? :-) Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services ---------- Forwarded message ---------- Date: Thu, 16 Sep 1999 09:10:53 -0700 From: Casey Schaufler To: Robert Watson Cc: "Ilmar S. Habibulin" , posix1e@cyrus.watson.org Subject: Re: Is this list dead Robert Watson wrote: > > On Thu, 16 Sep 1999, Ilmar S. Habibulin wrote: > > > Subj. > > Well, it's acting a little dead, but my hope is that it will not stay that > way indefinitely. Ya know, I had noticed that something was missing, but couldn't quite place it. I had ascribed the lack of activity to it being summer (my hemispheric centrisity showing!) and expected to see things pick up once vactions wrapped up. Starting October 1st I will have actual staffing available to work on commercial C2 and B1 Linux distributions. I have a stated engineering goal of C2 feature completion by 10/2000 and B1 feature completion by 4/2001. This will be fully open source. The plan is for C2 and B1 to be regular parts of the SGI distribution. In addition, I have been working with some people who cannot themselves work in public forums, including mail and news groups. They also wish to make contributions, especially in the areas of Mandatory Access Control, (we need a less overloaded acroynm than "MAC". Any thoughts?) policy description, and security test suites. > We're been redesigning how the record gathering mechanism is integrated > into FreeBSD, as there are parallel trace mechanisms (such as ktrace) that > serve a similar function. Good art never borrows. It's much better to steal. Also, it's much easier to sell audit if you can call it an extension to an existing, well liked mechanism. > I'm interested in the possibility of pinning down an IDS module > interface--i.e., a standard API by which IDS modules can talk to a > provider of audit records, specifying what they are interested in so as to > make detecting events more efficient. This would presumably include > functions to describe interesting records, functions to retrieve the > records when available, and functions to report events via some > event-reporting architecture. My understanding is that the state of the art for IDS is to suck information out of a relational database. This seperates the security function from the data gathering and relationship processing. If IDS is a real concern, perhaps defining a set of relations might be the best way to go, and design the audit records to fit nicely into the relations. -- Casey Schaufler voice: (650) 933-1634 casey@sgi.com fax: (650) 933-0170 To Unsubscribe: send mail to majordomo@cyrus.watson.org with "unsubscribe posix1e" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 12:10:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from mission.mvnc.edu (mission.mvnc.edu [149.143.2.3]) by hub.freebsd.org (Postfix) with ESMTP id 795B214ECF for ; Thu, 16 Sep 1999 12:10:32 -0700 (PDT) (envelope-from kdrobnac@mission.mvnc.edu) Received: from localhost (kdrobnac@localhost) by mission.mvnc.edu (8.9.0/8.9.0) with SMTP id PAA20829; Thu, 16 Sep 1999 15:06:53 -0400 (EDT) Date: Thu, 16 Sep 1999 15:06:53 -0400 (EDT) From: Kenny Drobnack To: Brett Glass Cc: "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4.2.0.58.19990915170025.048d0b00@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How about this idea: from what I've seen and heard, the only things that depend on BPF are tcpdump and dhcp. The average user does not need tcpdump. So, if a user enables dhcp, BPF gets turned on, otherwise, it will stay off. Of course, the only way I could think of to do this would be to make BPF a loadable module. The problem with that is, someone running as root could just load up the module anyway... > Maybe it's a religious issue, or maybe some utility depends on it. > But it might not be a good idea to let it be on from the get-go. > If the machine is rooted, you've got an instant packet sniffer. > I plan to turn it off on EVERY install, and I sure wish it > were that way to start. ----- We are now the Knights who say... "Ekki-Ekki-Ekki-Ekki-PTANG! Zoom-Boing! Z'nourrwringmm!" -the Knights who formerly said "ni" "Monty Python and the Holy Grail" ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 12:38: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from ionet.net (mail.ionet.net [206.41.128.16]) by hub.freebsd.org (Postfix) with ESMTP id F2441152D3 for ; Thu, 16 Sep 1999 12:37:41 -0700 (PDT) (envelope-from pattersonm@psi.com) Received: from nt (dredster.ionet.net [38.193.50.179]) by ionet.net (8.9.1a/8.9.1) with SMTP id OAA21028; Thu, 16 Sep 1999 14:37:16 -0500 (CDT) Message-ID: <044b01bf007a$ebd6db80$0201a8c0@dredster.ionet.net> From: "Micheal Patterson" To: "river" , References: <21DC5E98AE1FD311B1290020AFDB6C6E63E1@cx288885-b.okcs1.ok.home.com> Subject: Re: mapping ports from outside to inside (with ipfw ?) Date: Thu, 16 Sep 1999 14:33:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You can use the -redirect_port option if it's for just a few ports. natd -n -redirect_port tcp 10.0.0.2:4000 4000 -redirect_port udp 10.0.0.2:4000 4000 would send any traffic inbound on that interface (udp or tcp) that hit the firewall/natd system on port 4000 to a specific internal system on that specific port. I use this for ICQ and identd on my home system. If this isnt' what your trying to do, my apologies. Micheal Patterson Sr Technical Support PSINet OKC pattersonm@psi.com ----- Original Message ----- From: river To: Sent: Thursday, September 16, 1999 9:35 AM Subject: mapping ports from outside to inside (with ipfw ?) > Is there built in support to map the ports from the outside of the > firewall/gateway machine to an internal server inside the firewall/gateway > machine ? Or do I need to use another program for this ? > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 12:50:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from dt014nb6.san.rr.com (dt014nb6.san.rr.com [24.30.129.182]) by hub.freebsd.org (Postfix) with ESMTP id EDB9F14EEB for ; Thu, 16 Sep 1999 12:50:32 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt014nb6.san.rr.com (8.9.3/8.8.8) with ESMTP id NAA26158; Thu, 16 Sep 1999 13:24:37 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Thu, 16 Sep 1999 13:24:36 -0700 (PDT) From: Doug X-Sender: doug@dt014nb6.san.rr.com To: Kenny Drobnack Cc: Brett Glass , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 16 Sep 1999, Kenny Drobnack wrote: > How about this idea: Don't send ideas to the list. There are not any ideas that haven't been discussed already. The only useful contribution at this point is code. Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 13:15:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.tepucom.nl (mail.tepucom.nl [195.81.12.5]) by hub.freebsd.org (Postfix) with ESMTP id 9092214F4D for ; Thu, 16 Sep 1999 13:14:51 -0700 (PDT) (envelope-from theo@tepucom.nl) Received: from kantoor-1.tepucom.nl (kantoor-1.tepucom.nl [192.168.1.22]) by mail.tepucom.nl (8.9.3/8.9.3) with SMTP id WAA88696 for ; Thu, 16 Sep 1999 22:14:35 +0200 (CEST) (envelope-from theo@tepucom.nl) Received: by kantoor-1.tepucom.nl with Microsoft Mail id <01BF008E.2A0B4180@kantoor-1.tepucom.nl>; Thu, 16 Sep 1999 21:55:18 +-200 Message-ID: <01BF008E.2A0B4180@kantoor-1.tepucom.nl> From: "Theo Purmer (Tepucom)" To: "'freebsd-security@freebsd.org'" Subject: skip Date: Thu, 16 Sep 1999 21:55:16 +-200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi is there somebody out there who knows why the www.skip.org website is down. Even the name server servicing the skip.org domain isnt servicing it anymore...... just my luck as i just wanted to download it :((( thanks theo purmer tepucom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 13:18: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (Postfix) with ESMTP id C8524151FC for ; Thu, 16 Sep 1999 13:17:57 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id QAA06042; Thu, 16 Sep 1999 16:17:48 -0400 (EDT) Message-Id: <3.0.5.32.19990916161700.01e1ecb0@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 16 Sep 1999 16:17:00 -0400 To: theo@tepucom.nl, freebsd-security@FreeBSD.ORG From: Mike Tancsa Subject: Re: skip In-Reply-To: <01BF008E.2A0B4180@kantoor-1.tepucom.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:55 PM 9/16/99 +-200, Theo Purmer (Tepucom) wrote: >hi > >is there somebody out there who knows why the www.skip.org >website is down. Even the name server servicing the skip.org >domain isnt servicing it anymore...... > >just my luck as i just wanted to download it > >:((( It seems someone didnt pay their internic bill perhaps ? Try going their by IP address 216.147.46.195 ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel 01.519.651.3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 13:19:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id F199F15430 for ; Thu, 16 Sep 1999 13:19:34 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id NAA75739; Thu, 16 Sep 1999 13:18:54 -0700 (PDT) From: Archie Cobbs Message-Id: <199909162018.NAA75739@bubba.whistle.com> Subject: Re: skip In-Reply-To: <01BF008E.2A0B4180@kantoor-1.tepucom.nl> from "Theo Purmer (Tepucom)" at "Sep 16, 1999 09:55:16 pm" To: theo@tepucom.nl (Theo Purmer (Tepucom)) Date: Thu, 16 Sep 1999 13:18:54 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG ('freebsd-security@freebsd.org') X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Theo Purmer (Tepucom) writes: > is there somebody out there who knows why the www.skip.org > website is down. Even the name server servicing the skip.org > domain isnt servicing it anymore...... > > just my luck as i just wanted to download it You can still download it by building the port, which gets it from some other site(s). -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 13:24:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.interact.se (smtp1.interact.se [193.15.98.9]) by hub.freebsd.org (Postfix) with ESMTP id E333C153F4 for ; Thu, 16 Sep 1999 13:24:19 -0700 (PDT) (envelope-from je@interact.se) Received: from aju4j (install3.interact.se [193.15.98.52]) by smtp.interact.se (InterACT Mailer) with SMTP id WAA04933; Thu, 16 Sep 1999 22:23:58 +0200 (CEST) Message-Id: <3.0.32.19990916222223.006fd734@smtp1.interact.se> X-Sender: mailman@smtp1.interact.se X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Thu, 16 Sep 1999 22:22:24 +0200 To: "Theo Purmer (Tepucom)" , "'freebsd-security@freebsd.org'" From: Jonas Eriksson Subject: Re: skip Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 21:55 1999-09-16 +-200, Theo Purmer (Tepucom) wrote: >hi > >is there somebody out there who knows why the www.skip.org >website is down. Even the name server servicing the skip.org >domain isnt servicing it anymore...... > >just my luck as i just wanted to download it Try http://www.skip-vpn.org -- Jonas Eriksson InterACT Sweden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 15:43:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 719AC14D78 for ; Thu, 16 Sep 1999 15:43:47 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA16840; Thu, 16 Sep 1999 15:43:11 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA07949; Thu, 16 Sep 1999 15:31:14 -0700 Received: from softweyr.com (dyn4.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA00608; Thu, 16 Sep 99 15:43:02 PDT Message-Id: <37E17276.AA1DDF96@softweyr.com> Date: Thu, 16 Sep 1999 16:43:02 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: "Harry M. Leitzell" Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Harry M. Leitzell" wrote: > > Correct me if I am wrong, but didn't the list have a huge > arguement over this a while back and the decision was to leave it in for > some reasons that someone dreamed up? Yes. This message brought to you by the letters D, H, C, and P. Get it? Good. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 15:58:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id 012EB15865 for ; Thu, 16 Sep 1999 15:58:38 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from crocus (c3-1f194.neo.rr.com [24.93.235.194]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id SAA10236; Thu, 16 Sep 1999 18:58:23 -0400 (EDT) Message-ID: <002b01bf0096$8b0af9f0$23b197ce@ezo.net> From: "Jim Flowers" To: "Theo Purmer (Tepucom)" , "'freebsd-security@freebsd.org'" References: <3.0.32.19990916222223.006fd734@smtp1.interact.se> Subject: Re: skip web page and mail list Date: Thu, 16 Sep 1999 18:55:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org And you can join the mail list with: To subscribe the digest, simply send a message with the word "subscribe" in the Subject: field to the following address. To: skip-info-d-request@skip-vpn.org Subject: subscribe ----- Original Message ----- From: Jonas Eriksson To: Theo Purmer (Tepucom) ; 'freebsd-security@freebsd.org' Sent: Thursday, September 16, 1999 4:22 PM Subject: Re: skip > At 21:55 1999-09-16 +-200, Theo Purmer (Tepucom) wrote: > >hi > > > >is there somebody out there who knows why the www.skip.org > >website is down. Even the name server servicing the skip.org > >domain isnt servicing it anymore...... > > > >just my luck as i just wanted to download it > > Try http://www.skip-vpn.org > > > -- Jonas Eriksson > InterACT Sweden > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 16:15: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from kinetic.tiora.net (kinetic.tiora.net [206.251.130.15]) by hub.freebsd.org (Postfix) with ESMTP id D2F1014FBC for ; Thu, 16 Sep 1999 16:15:02 -0700 (PDT) (envelope-from liam@kinetic.tiora.net) Received: from localhost (liam@localhost) by kinetic.tiora.net (8.9.3/8.9.3) with ESMTP id QAA12901; Thu, 16 Sep 1999 16:14:52 -0700 (PDT) Date: Thu, 16 Sep 1999 16:14:52 -0700 (PDT) From: Liam Slusser To: Kenny Drobnack Cc: Brett Glass , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Right...but if the system was hacked what would stop the hacker from building BPF in a kernel? It does not matter if you have it in the kernel or not..if a hacker wants it..it does not take alot of work to add it. And anyways...if you don't like it..you could always *build* your own kernel without BPF. ;) liam System Administrator Tiora Networks | www.tiora.net <---- tiora's webpage www.tiora.net/~liam <----- homepage | liam@tiora.net <-- my email address Lowered turbo powered Honda Civic's are really cool. <---------- my quote On Thu, 16 Sep 1999, Kenny Drobnack wrote: > How about this idea: from what I've seen and heard, the only things that > depend on BPF are tcpdump and dhcp. The average user does not need > tcpdump. So, if a user enables dhcp, BPF gets turned on, otherwise, it > will stay off. Of course, the only way I could think of to do this would > be to make BPF a loadable module. The problem with that is, someone > running as root could just load up the module anyway... > > > > Maybe it's a religious issue, or maybe some utility depends on it. > > But it might not be a good idea to let it be on from the get-go. > > If the machine is rooted, you've got an instant packet sniffer. > > I plan to turn it off on EVERY install, and I sure wish it > > were that way to start. > > ----- > We are now the Knights who say... > "Ekki-Ekki-Ekki-Ekki-PTANG! Zoom-Boing! Z'nourrwringmm!" > -the Knights who formerly said "ni" "Monty Python and the Holy Grail" > ---- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 17:14:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 948491545B for ; Thu, 16 Sep 1999 17:14:25 -0700 (PDT) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id RAA04139; Thu, 16 Sep 1999 17:14:24 -0700 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda04137; Thu Sep 16 17:14:19 1999 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id RAA10192; Thu, 16 Sep 1999 17:14:15 -0700 (PDT) Message-Id: <199909170014.RAA10192@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdk10165; Thu Sep 16 17:13:28 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.2-RELEASE X-Sender: cy To: Dag-Erling Smorgrav Cc: Root , skalir scalar , freebsd-security@FreeBSD.ORG Subject: Re: ipfw and syslogd In-reply-to: Your message of "16 Sep 1999 10:56:29 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Sep 1999 17:13:27 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Dag-Erling Smorgrav writes: > Root writes: > > !ipfw > > *.* /var/log/firewall.log > > Won't work in -STABLE, because ip_fw.c uses printf() instead of log(). I use this on 3.3-RC and it sends ipfw logs to our log server as follows and it still works: !ipfw *.* @syslog.server Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 17:46:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from dt014nb6.san.rr.com (dt014nb6.san.rr.com [24.30.129.182]) by hub.freebsd.org (Postfix) with ESMTP id 3BF05157E2 for ; Thu, 16 Sep 1999 17:46:50 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt014nb6.san.rr.com (8.9.3/8.8.8) with ESMTP id SAA28229; Thu, 16 Sep 1999 18:23:55 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Thu, 16 Sep 1999 18:23:54 -0700 (PDT) From: Doug X-Sender: doug@dt014nb6.san.rr.com To: Liam Slusser Cc: Kenny Drobnack , Brett Glass , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 16 Sep 1999, Liam Slusser wrote: > Right...but if the system was hacked what would stop the hacker from > building BPF in a kernel? Please don't encourage others to continue the discussion by continuing the discussion. :) "That topic was covered in the discussion available in the mail archives" is probably your best response. Thanks, Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 17:56:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 8F32C157D7 for ; Thu, 16 Sep 1999 17:56:12 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id SAA04611; Thu, 16 Sep 1999 18:56:01 -0600 (MDT) Message-Id: <4.2.0.58.19990916185341.00aaf100@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 16 Sep 1999 18:54:24 -0600 To: Liam Slusser , Kenny Drobnack From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: "Harry M. Leitzell" , security@FreeBSD.ORG In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 04:14 PM 9/16/99 -0700, Liam Slusser wrote: >Right...but if the system was hacked what would stop the hacker from >building BPF in a kernel? securelevel=2 or securelevel=3. Or Tripwire. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 18:28:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by hub.freebsd.org (Postfix) with ESMTP id 1806814D6A for ; Thu, 16 Sep 1999 18:28:20 -0700 (PDT) (envelope-from Harry_M_Leitzell@cmu.edu) Received: from unix8.andrew.cmu.edu (UNIX8.ANDREW.CMU.EDU [128.2.15.12]) by smtp2.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id VAA16502; Thu, 16 Sep 1999 21:28:12 -0400 (EDT) Date: Thu, 16 Sep 1999 21:28:11 -0400 (EDT) From: "Harry M. Leitzell" X-Sender: Harry_M_Leitzell@unix8.andrew.cmu.edu To: Brett Glass Cc: Liam Slusser , Kenny Drobnack , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4.2.0.58.19990916185341.00aaf100@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No offense, but tripwire is really a bit overrated except if the person is a script child and hasn't a clue as to what to do. If tripwire hasn't been set up with the db set on a readonly disk partition and you gain root, you can set up a KLM to change the db on the fly. On Thu, 16 Sep 1999, Brett Glass wrote: > At 04:14 PM 9/16/99 -0700, Liam Slusser wrote: > > >Right...but if the system was hacked what would stop the hacker from > >building BPF in a kernel? > > securelevel=2 or securelevel=3. > > Or Tripwire. > > --Brett > > > [-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] Harry M. Leitzell - Harry_M_Leitzell@cmu.edu Carnegie Mellon University Finger for PGP Public Key [-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 19:20:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 9E9F114A1C for ; Thu, 16 Sep 1999 19:20:29 -0700 (PDT) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.8.8) id WAA00639; Thu, 16 Sep 1999 22:22:56 -0400 (EDT) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199909170222.WAA00639@cc942873-a.ewndsr1.nj.home.com> Subject: Re: ipfw and syslogd In-Reply-To: from Dag-Erling Smorgrav at "Sep 16, 1999 10:56:29 am" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Thu, 16 Sep 1999 22:22:56 -0400 (EDT) Cc: root@net72-105.student.yale.edu (Root), skalir@hotmail.com (skalir scalar), freebsd-security@FreeBSD.ORG Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dag-Erling Smorgrav wrote, > Root writes: > > !ipfw > > *.* /var/log/firewall.log > > Won't work in -STABLE, because ip_fw.c uses printf() instead of log(). Bug or feature? -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 20:29:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from jason.argos.org (a1-3a123.neo.rr.com [24.93.180.123]) by hub.freebsd.org (Postfix) with ESMTP id D91E814EBD for ; Thu, 16 Sep 1999 20:29:38 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id XAA10111 for ; Thu, 16 Sep 1999 23:29:38 -0400 Date: Thu, 16 Sep 1999 23:29:38 -0400 (EDT) From: Mike Nowlin To: security@freebsd.org Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you know enough to (intelligently) respond to this thread, you know enough to turn BPF off. If you're not reading this list, you don't care enough about security to worry about BPF. Now drop it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 22:25:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id B263714F00 for ; Thu, 16 Sep 1999 22:25:23 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id XAA06811; Thu, 16 Sep 1999 23:25:06 -0600 (MDT) Message-Id: <4.2.0.58.19990916232349.047c27a0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 16 Sep 1999 23:25:05 -0600 To: "Harry M. Leitzell" From: Brett Glass Subject: Securing a system that's been rooted remotely (Was: BPF on in 3.3-RC GENERIC kernel) Cc: Liam Slusser , Kenny Drobnack , security@FreeBSD.ORG In-Reply-To: References: <4.2.0.58.19990916185341.00aaf100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:28 PM 9/16/99 -0400, Harry M. Leitzell wrote: > No offense, but tripwire is really a bit overrated except if the >person is a script child and hasn't a clue as to what to do. If tripwire >hasn't been set up with the db set on a readonly disk partition and you >gain root, you can set up a KLM to change the db on the fly. securelevel=2 and above disables LKMs, IIRC. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 22:31: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from sentry.granch.ru (sentry.granch.ru [212.20.5.135]) by hub.freebsd.org (Postfix) with ESMTP id 637A914F00 for ; Thu, 16 Sep 1999 22:30:40 -0700 (PDT) (envelope-from shelton@sentry.granch.ru) Received: from localhost (IDENT:shelton@localhost.granch.ru [127.0.0.1]) by sentry.granch.ru (8.9.3/8.9.3) with ESMTP id MAA39916; Fri, 17 Sep 1999 12:30:14 +0700 (NOVST) Date: Fri, 17 Sep 1999 12:30:14 +0700 (NOVST) From: "Rashid N. Achilov" To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <4.2.0.58.19990916185341.00aaf100@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 16 Sep 1999, Brett Glass wrote: > At 04:14 PM 9/16/99 -0700, Liam Slusser wrote: > > >Right...but if the system was hacked what would stop the hacker from > >building BPF in a kernel? > > securelevel=2 or securelevel=3. > > Or Tripwire. What's different between securelevel=1, securelevel=2 and securelevel=3? With Best Regards. Rashid N. Achilov (RNA1-RIPE), Cert. ID: 28514, Granch Ltd. lead engineer e-mail: achilov@granch.ru, tel (383-2) 24-2363 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 22:56:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 05BEB14F90 for ; Thu, 16 Sep 1999 22:56:10 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id XAA07017; Thu, 16 Sep 1999 23:55:58 -0600 (MDT) Message-Id: <4.2.0.58.19990916235421.047c6110@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 16 Sep 1999 23:55:57 -0600 To: "Rashid N. Achilov" From: Brett Glass Subject: Re: Securing a system that's been rooted remotely Cc: security@FreeBSD.ORG In-Reply-To: References: <4.2.0.58.19990916185341.00aaf100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:30 PM 9/17/99 +0700, Rashid N. Achilov wrote: >What's different between securelevel=1, securelevel=2 and securelevel=3? man 8 init --Brett Glass To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 16 23:28:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id 8B54614EEF for ; Thu, 16 Sep 1999 23:27:44 -0700 (PDT) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id JAA98008; Fri, 17 Sep 1999 09:26:56 +0300 (EEST) (envelope-from ru) Date: Fri, 17 Sep 1999 09:26:56 +0300 From: Ruslan Ermilov To: Dag-Erling Smorgrav Cc: freebsd-security@FreeBSD.ORG Subject: Re: ipfw and syslogd Message-ID: <19990917092656.D90628@relay.ucb.crimea.ua> Mail-Followup-To: Dag-Erling Smorgrav , freebsd-security@FreeBSD.ORG References: <199909170014.RAA10192@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199909170014.RAA10192@cwsys.cwsent.com>; from Cy Schubert - ITSD Open Systems Group on Thu, Sep 16, 1999 at 05:13:27PM -0700 X-Operating-System: FreeBSD 3.2-STABLE i386 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Sep 16, 1999 at 05:13:27PM -0700, Cy Schubert - ITSD Open Systems Group wrote: > In message , Dag-Erling Smorgrav > writes: > > Root writes: > > > !ipfw > > > *.* /var/log/firewall.log > > > > Won't work in -STABLE, because ip_fw.c uses printf() instead of log(). > > I use this on 3.3-RC and it sends ipfw logs to our log server as > follows and it still works: > > !ipfw > *.* @syslog.server > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca > ITSD Cy.Schubert@gems8.gov.bc.ca > Province of BC > "e**(i*pi)+1=0" For me it works as well (3.2-STABLE at the moment). -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 0:37:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from finland.ispro.net.tr (finland.ispro.net.tr [195.174.18.1]) by hub.freebsd.org (Postfix) with ESMTP id E263214E03 for ; Fri, 17 Sep 1999 00:37:45 -0700 (PDT) (envelope-from yurtesen@ispro.net.tr) Received: from ispro.net.tr (c14pc16.dc.turkuamk.fi [193.166.135.241]) by finland.ispro.net.tr (8.9.3/8.9.3) with ESMTP id KAA88419; Fri, 17 Sep 1999 10:36:52 +0300 (EEST) (envelope-from yurtesen@ispro.net.tr) Message-ID: <37E21A0A.1075F204@ispro.net.tr> Date: Fri, 17 Sep 1999 10:38:02 +0000 From: Evren Yurtesen X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: Brett Glass Cc: "Rashid N. Achilov" , security@FreeBSD.ORG Subject: Re: Securing a system that's been rooted remotely References: <4.2.0.58.19990916185341.00aaf100@localhost> <4.2.0.58.19990916235421.047c6110@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So what is the best way to set securelevel at boot time? Evren Brett Glass wrote: > At 12:30 PM 9/17/99 +0700, Rashid N. Achilov wrote: > > >What's different between securelevel=1, securelevel=2 and securelevel=3? > > man 8 init > > --Brett Glass > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 4:29:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from ares.maths.adelaide.edu.au (ares.maths.adelaide.edu.au [129.127.246.5]) by hub.freebsd.org (Postfix) with ESMTP id CBFD2151DB for ; Fri, 17 Sep 1999 04:29:18 -0700 (PDT) (envelope-from glewis@ares.maths.adelaide.edu.au) Received: (from glewis@localhost) by ares.maths.adelaide.edu.au (8.9.3/8.9.3) id UAA67518; Fri, 17 Sep 1999 20:58:59 +0930 (CST) (envelope-from glewis) From: Greg Lewis Message-Id: <199909171128.UAA67518@ares.maths.adelaide.edu.au> Subject: Re: Securing a system that's been rooted remotely In-Reply-To: <37E21A0A.1075F204@ispro.net.tr> from Evren Yurtesen at "Sep 17, 1999 10:38:02 am" To: Evren Yurtesen Date: Fri, 17 Sep 1999 20:58:59 +0930 (CST) Cc: freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL56 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > So what is the best way to set securelevel at boot time? > > Evren Alter the values of kern_securelevel_enable (to "YES") and kern_securelevel (to say "1", "2" or "3") in /etc/rc.conf. -- Greg Lewis glewis@trc.adelaide.edu.au Computing Officer +61 8 8303 5083 Teletraffic Research Centre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 6:31:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from isiproxy.insolwwb.net (isiproxy.insolwwb.net [208.150.248.1]) by hub.freebsd.org (Postfix) with ESMTP id A7CBA14A08 for ; Fri, 17 Sep 1999 06:31:21 -0700 (PDT) (envelope-from mgrommet@isiar.net) Received: by ISIMAIN with Internet Mail Service (5.5.2448.0) id ; Fri, 17 Sep 1999 08:30:08 -0500 Message-ID: <7011ACE3864AD31183E50008C7FA081F01D4D0@ISIMAIN> From: Michael Grommet To: "'Harry M. Leitzell'" , 'Brett Glass' Cc: 'Liam Slusser' , 'Kenny Drobnack' , "'security@FreeBSD.ORG'" Subject: RE: BPF on in 3.3-RC GENERIC kernel Date: Fri, 17 Sep 1999 08:29:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just to add my 2 cents worth, I've always been able to store the tripwire database on a floppy, physically write protected :) I suppose if you had lots and lots of files for tripwire to keep track of, this wouldnt work, but hey, even if someone is more advanced than your average script kiddie, they still won't be able to overwrite the info. -----Original Message----- From: owner-freebsd-security@FreeBSD.ORG [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Harry M. Leitzell Sent: Thursday, September 16, 1999 8:28 PM To: Brett Glass Cc: Liam Slusser; Kenny Drobnack; security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel No offense, but tripwire is really a bit overrated except if the person is a script child and hasn't a clue as to what to do. If tripwire hasn't been set up with the db set on a readonly disk partition and you gain root, you can set up a KLM to change the db on the fly. On Thu, 16 Sep 1999, Brett Glass wrote: > At 04:14 PM 9/16/99 -0700, Liam Slusser wrote: > > >Right...but if the system was hacked what would stop the hacker from > >building BPF in a kernel? > > securelevel=2 or securelevel=3. > > Or Tripwire. > > --Brett > > > [-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] Harry M. Leitzell - Harry_M_Leitzell@cmu.edu Carnegie Mellon University Finger for PGP Public Key [-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 8:16:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 2F6D5150C9 for ; Fri, 17 Sep 1999 08:16:18 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id JAA10760 for ; Fri, 17 Sep 1999 09:16:15 -0600 (MDT) Message-Id: <4.2.0.58.19990917090848.04e582e0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 09:16:11 -0600 To: security@freebsd.org From: Brett Glass Subject: Best way to do FTP with NAT and firewall? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've just set up a firewall for a client using ipfw and natd. Trouble is, his software seems to be particularly insistent on doing active, rather than passive, FTP. This poses a problem, of course, because a remote system can't open just data sockets to one behind the firewall due to NAT. I've worked with plenty of commercial firewalls that monitor FTP control connections and spoof the port number for the data sockets. SLiRP does it; so, apparently, does the pppd that comes with FreeBSD. But I can't find any documented way to do it with ipfw and natd. Are there undocumented commands to accomplish this? --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 8:26:55 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 1AB1E154F7 for ; Fri, 17 Sep 1999 08:26:52 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id JAA10867; Fri, 17 Sep 1999 09:26:29 -0600 (MDT) Message-Id: <4.2.0.58.19990917092237.044f3f00@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 09:23:43 -0600 To: Greg Lewis , Evren Yurtesen From: Brett Glass Subject: Re: Securing a system that's been rooted remotely Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <199909171128.UAA67518@ares.maths.adelaide.edu.au> References: <37E21A0A.1075F204@ispro.net.tr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org By the way, why is it that "apropos securelevel" turns up nothing? Considering that it's documented in a non-intuitive place (the man page for init(8)), it ouught to be searchable. --Brett At 08:58 PM 9/17/99 +0930, Greg Lewis wrote: > > So what is the best way to set securelevel at boot time? > > > > Evren > >Alter the values of kern_securelevel_enable (to "YES") and kern_securelevel >(to say "1", "2" or "3") in /etc/rc.conf. > >-- >Greg Lewis glewis@trc.adelaide.edu.au >Computing Officer +61 8 8303 5083 >Teletraffic Research Centre > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 8:44:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from mailhub.scl.ameslab.gov (mailhub.scl.ameslab.gov [147.155.137.127]) by hub.freebsd.org (Postfix) with ESMTP id 6455114EB4 for ; Fri, 17 Sep 1999 08:44:13 -0700 (PDT) (envelope-from ghelmer@scl.ameslab.gov) Received: from demios.ether.scl.ameslab.gov ([147.155.137.54]) by mailhub.scl.ameslab.gov with esmtp (Exim 3.02 #1) id 11S0B9-000ItC-00; Fri, 17 Sep 1999 10:44:03 -0500 Date: Fri, 17 Sep 1999 10:44:03 -0500 From: Guy Helmer To: Brett Glass Cc: security@freebsd.org Subject: Re: Best way to do FTP with NAT and firewall? In-Reply-To: <4.2.0.58.19990917090848.04e582e0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 17 Sep 1999, Brett Glass wrote: > I've just set up a firewall for a client using ipfw and natd. Trouble > is, his software seems to be particularly insistent on doing active, > rather than passive, FTP. This poses a problem, of course, because a > remote system can't open just data sockets to one behind the firewall > due to NAT. > > I've worked with plenty of commercial firewalls that monitor FTP > control connections and spoof the port number for the data sockets. > SLiRP does it; so, apparently, does the pppd that comes with FreeBSD. > But I can't find any documented way to do it with ipfw and natd. > > Are there undocumented commands to accomplish this? For FTP clients behind the firewall, natd seems automatically to understand & massage the FTP protocol, since PORT commands work through it. In my NAT firewall system's /etc/rc.firewall, I have this line: $fwcmd add pass log tcp from any 20 to ${inet}:${imask} 1024-65535 setup Since this line has the "log" option, I know it is working. Since this rule is invoked after the TCP SYN packet has been forwarded by natd, it seems safe... Guy Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- ghelmer@scl.ameslab.gov Research Assistant, Dept. of Computer Science --- ghelmer@cs.iastate.edu Teaching Assistant, ComS 652 Distributed Operating Systems http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 11:42:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id D63A914C9B for ; Fri, 17 Sep 1999 11:42:35 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.3/8.8.7) with ESMTP id OAA67918; Fri, 17 Sep 1999 14:42:14 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 17 Sep 1999 14:42:14 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: cjclark@home.com Cc: Dag-Erling Smorgrav , Root , skalir scalar , freebsd-security@FreeBSD.org Subject: Re: ipfw and syslogd In-Reply-To: <199909170222.WAA00639@cc942873-a.ewndsr1.nj.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 16 Sep 1999, Crist J. Clark wrote: > Dag-Erling Smorgrav wrote, > > Root writes: > > > !ipfw > > > *.* /var/log/firewall.log > > > > Won't work in -STABLE, because ip_fw.c uses printf() instead of log(). It should work just fine, since printf()s go to syslog too. > > Bug or feature? > Neither. I just haven't merged back the changes which make ipfw use log(9). (I should say "yet," as I hope to do so soon.) -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 11:44:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 533D01588B for ; Fri, 17 Sep 1999 11:44:17 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id NAA02939; Fri, 17 Sep 1999 13:43:44 -0500 (CDT) Date: Fri, 17 Sep 1999 13:43:43 -0500 From: "Matthew D. Fuller" To: Brett Glass Cc: "Harry M. Leitzell" , Liam Slusser , Kenny Drobnack , security@FreeBSD.ORG Subject: Re: Securing a system that's been rooted remotely (Was: BPF on in 3.3-RC GENERIC kernel) Message-ID: <19990917134343.P16305@futuresouth.com> References: <4.2.0.58.19990916185341.00aaf100@localhost> <4.2.0.58.19990916232349.047c27a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <4.2.0.58.19990916232349.047c27a0@localhost>; from Brett Glass on Thu, Sep 16, 1999 at 11:25:05PM -0600 X-OS: FreeBSD Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Sep 16, 1999 at 11:25:05PM -0600, a little birdie told me that Brett Glass remarked > > securelevel=2 and above disables LKMs, IIRC. I can't imagine anyone who would need and use a high securelevel like that, and still run a GENERIC kernel. If they do, then their worldview would seem to be slightly skewed. I run a custom (2.1.5-REL) kernel on musca, which is a 386 SX/20. It took 6 hours to compile. On mortis (4.0-CURRENT) a kernel takes approx. 2 minutes to compile. This is not a major time investment. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 12:33:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E9F7D14CCC for ; Fri, 17 Sep 1999 12:33:19 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA82625; Fri, 17 Sep 1999 13:33:17 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA04565; Fri, 17 Sep 1999 13:32:13 -0600 (MDT) Message-Id: <199909171932.NAA04565@harmony.village.org> To: Paulo Fragoso Subject: Re: make world to FreeBSD-SA-99:05.fts Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Sep 1999 09:37:12 -0300." References: Date: Fri, 17 Sep 1999 13:32:13 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Paulo Fragoso writes: : We've a doubt. Can we aplly this patch and only make and make install on : /usr/src/lib/libc instead make world on /usr/src? No. You *MUST* update the whole tree. Too many things link it in statically. Otherwise I would have said that you could just update libc :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 12:35: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E8749152F0 for ; Fri, 17 Sep 1999 12:34:52 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA82630; Fri, 17 Sep 1999 13:34:50 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA04578; Fri, 17 Sep 1999 13:33:47 -0600 (MDT) Message-Id: <199909171933.NAA04578@harmony.village.org> To: Cy Schubert - ITSD Open Systems Group Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Brett Glass , Darren Reed , Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Sep 1999 07:09:00 PDT." <199909161409.HAA06535@cwsys.cwsent.com> References: <199909161409.HAA06535@cwsys.cwsent.com> Date: Fri, 17 Sep 1999 13:33:47 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909161409.HAA06535@cwsys.cwsent.com> Cy Schubert - ITSD Open Systems Group writes: : How about a compromise? Leave BPF in the generic kernel but add a boot : option to disable it, then a site can create a loader.conf to to : disable it. Because that is every bit as dangerous as having it enabled. If an intruder wants to turn it on, make them work harder than changing one memory location in the kernel. Also, BPF isn't setup to really do this in its current incarnation. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 12:41:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9628114F6E for ; Fri, 17 Sep 1999 12:41:01 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA82654; Fri, 17 Sep 1999 13:41:00 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA04615; Fri, 17 Sep 1999 13:39:58 -0600 (MDT) Message-Id: <199909171939.NAA04615@harmony.village.org> To: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Cy Schubert - ITSD Open Systems Group , Darren Reed , Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Sep 1999 10:15:02 MDT." <4.2.0.58.19990916100439.048ebd70@localhost> References: <4.2.0.58.19990916100439.048ebd70@localhost> Date: Fri, 17 Sep 1999 13:39:58 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990916100439.048ebd70@localhost> Brett Glass writes: : To do this, the BPF driver needs to have a visible switch you can hit to : disable it, as do other drivers. I forget the exact data structures involved, : but I know it's not hard. Anyone have this information on the top of his/her : head? BPF isn't architected to allow this, so doing it effectively would be non-trivial. Also, if I can run any kernel code at all as an intruder, I can reset this simple flag and you'd never know about it. Single flags in the kernel can easily be abused if your system isn't completely and totally locked down. I don't want to encourage people to create a switch that is as easy to turn on as it is to turn off. My main objection to this is that you are looking at the wrong problem here. If I have rooted your system, I can generally cause arbitrary code to run at boot time before the secure level is changed because I've yet to see a system that is secured well enough to prevent it. The level of effort required to close all these wholes is about an order of magnitude larger than rebuilding he kernel with the bpf code removed. The best solution would be to have the IP stack that could deal with the needs of dhcp. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 12:53:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from dt014nb6.san.rr.com (dt014nb6.san.rr.com [24.30.129.182]) by hub.freebsd.org (Postfix) with ESMTP id 884F81551D for ; Fri, 17 Sep 1999 12:53:13 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt014nb6.san.rr.com (8.9.3/8.8.8) with ESMTP id NAA36090 for ; Fri, 17 Sep 1999 13:42:06 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 17 Sep 1999 13:42:06 -0700 (PDT) From: Doug X-Sender: doug@dt014nb6.san.rr.com To: security@freebsd.org Subject: CERT amd advisory Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org INRE CERT Advisory CA-99.12 - Buffer Overflow in amd, I'm wondering if it's being contemplated to MFC the recent update to amd (to the non-vulnerable version) prior to 3.3-Release CD's being cut? I know it's a big change, but I think it might be worth it. Also, FYI the URL for the FreeBSD advisory on this topic doesn't seem to be on the FTP site yet. Doug -- "My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!'" - John Belushi as "Joliet" Jake Blues, "I Don't Know" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 13: 5:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 97C4414E9F for ; Fri, 17 Sep 1999 13:05:14 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA82735; Fri, 17 Sep 1999 14:05:13 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA04763; Fri, 17 Sep 1999 14:04:10 -0600 (MDT) Message-Id: <199909172004.OAA04763@harmony.village.org> To: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Sep 1999 18:54:24 MDT." <4.2.0.58.19990916185341.00aaf100@localhost> References: <4.2.0.58.19990916185341.00aaf100@localhost> Date: Fri, 17 Sep 1999 14:04:10 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990916185341.00aaf100@localhost> Brett Glass writes: : At 04:14 PM 9/16/99 -0700, Liam Slusser wrote: : : >Right...but if the system was hacked what would stop the hacker from : >building BPF in a kernel? : : securelevel=2 or securelevel=3. : : Or Tripwire. Dreamer. This is covered in the archives. Unless every file that root could run before secure level is raised, including any dynamically linked in libraries is set immutable, you loose. However, there is a hole the size of a truck right now in that anything that is listed in the rc.d directories gets run before the secure level is changed. Did you remember to list them all in the list of files that have schg tagged on them? Also, some programs can be run based on the presense or absense of files in /etc, which cannot be marked schg or users will be unable to change their passwords, finger information, etc. If even one of these items is missed, I can force a reboot after putting my trojan into that file, load the module and then put the file back to how it was before in an environment that will give me a good chance of restoring the damage before Tripwire can run. Also, most of the commands in /etc/rc do not include complete paths, so path games are possible. Did I forget anything? Likely. This was a 5 minute glance at the source. What would a couple of hours have revealed? If you can fix all of these problems trivially, then you might have an arguement. As it is, it takes a hell of a lot of work to keep root from running completely arbitrary commands on boot. The pain of recompiling the kernel is minor in comparison. The pain of not having DHCP is much worse... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 13:12:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B0BBB14D68 for ; Fri, 17 Sep 1999 13:12:21 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA82766; Fri, 17 Sep 1999 14:12:20 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA04817; Fri, 17 Sep 1999 14:11:18 -0600 (MDT) Message-Id: <199909172011.OAA04817@harmony.village.org> To: Brett Glass Subject: Re: Securing a system that's been rooted remotely (Was: BPF on in 3.3-RC GENERIC kernel) Cc: "Harry M. Leitzell" , Liam Slusser , Kenny Drobnack , security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Sep 1999 23:25:05 MDT." <4.2.0.58.19990916232349.047c27a0@localhost> References: <4.2.0.58.19990916232349.047c27a0@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> Date: Fri, 17 Sep 1999 14:11:18 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990916232349.047c27a0@localhost> Brett Glass writes: : securelevel=2 and above disables LKMs, IIRC. except during the boot process... root is allowed to reboot... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 13:12:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from unix1.it-datacntr.louisville.edu (unix1.it-datacntr.louisville.edu [136.165.4.27]) by hub.freebsd.org (Postfix) with ESMTP id 5A7B215836 for ; Fri, 17 Sep 1999 13:12:42 -0700 (PDT) (envelope-from k.stevenson@louisville.edu) Received: from homer.louisville.edu (ktstev01@homer.louisville.edu [136.165.1.20]) by unix1.it-datacntr.louisville.edu (8.8.8/8.8.7) with ESMTP id QAA35934 for ; Fri, 17 Sep 1999 16:12:24 -0400 Received: (from ktstev01@localhost) by homer.louisville.edu (8.8.8/8.8.8) id QAA06250 for freebsd-security@freebsd.org; Fri, 17 Sep 1999 16:12:24 -0400 (EDT) Message-ID: <19990917161224.A5524@homer.louisville.edu> Date: Fri, 17 Sep 1999 16:12:24 -0400 From: Keith Stevenson To: freebsd-security@freebsd.org Subject: Re: CERT amd advisory References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Doug on Fri, Sep 17, 1999 at 01:42:06PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 17, 1999 at 01:42:06PM -0700, Doug wrote: > INRE CERT Advisory CA-99.12 - Buffer Overflow in amd, I'm > wondering if it's being contemplated to MFC the recent update to amd (to > the non-vulnerable version) prior to 3.3-Release CD's being cut? I know > it's a big change, but I think it might be worth it. Also, FYI the URL for > the FreeBSD advisory on this topic doesn't seem to be on the FTP site yet. I seem to recall the 3.3 Release Notes stating that this problem was fixed. -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.stevenson@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 13:18:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D705314BDD for ; Fri, 17 Sep 1999 13:18:28 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA82797; Fri, 17 Sep 1999 14:18:23 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA04877; Fri, 17 Sep 1999 14:17:17 -0600 (MDT) Message-Id: <199909172017.OAA04877@harmony.village.org> To: Doug Subject: Re: CERT amd advisory Cc: security@FreeBSD.ORG In-reply-to: Your message of "Fri, 17 Sep 1999 13:42:06 PDT." References: Date: Fri, 17 Sep 1999 14:17:17 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Doug writes: : INRE CERT Advisory CA-99.12 - Buffer Overflow in amd, I'm : wondering if it's being contemplated to MFC the recent update to amd (to : the non-vulnerable version) prior to 3.3-Release CD's being cut? I know : it's a big change, but I think it might be worth it. Also, FYI the URL for : the FreeBSD advisory on this topic doesn't seem to be on the FTP site yet. The advisory that I'm writing right now gives the details, but basically the relevant paches have already been MFC'd. 3.3R is not vulnerable. More to follow. My messages to Brent were a break from the writing. :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 13:20: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 6394614EA8 for ; Fri, 17 Sep 1999 13:20:01 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id WAA05084; Fri, 17 Sep 1999 22:18:35 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Warner Losh Cc: Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Fri, 17 Sep 1999 14:04:10 MDT." <199909172004.OAA04763@harmony.village.org> Date: Fri, 17 Sep 1999 22:18:35 +0200 Message-ID: <5082.937599515@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There is a new kid in town if it comes to fortifying your FreeBSD box: jail(2|8) I have installed a couple of machines now where everything it does for a living happens inside a jail. One of the machines have no network services running in the "unjailed" part, you can only access it from the console. The advantage to this approach is that the *REAL* system is protected independently of any application needed specific weak points. The way I set it up: boot normally: no network configured application disks not mounted. fsck application disks. mount application disks. consistency check specified files using only tools from the un-jailed part of the system. ifconfig interfaces. Start jail(s) running on application disks optional: start sshd in unjailed part. In essence this gives you a machine "that boots before it boots", and it allows you to really close some doors. It also limits the abilities of a intruder gaining root in the jail. try it... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 13:49:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2E1631540B for ; Fri, 17 Sep 1999 13:49:04 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA82867; Fri, 17 Sep 1999 14:48:07 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA05020; Fri, 17 Sep 1999 14:47:05 -0600 (MDT) Message-Id: <199909172047.OAA05020@harmony.village.org> To: Keith Stevenson Subject: Re: CERT amd advisory Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Fri, 17 Sep 1999 16:12:24 EDT." <19990917161224.A5524@homer.louisville.edu> References: <19990917161224.A5524@homer.louisville.edu> Date: Fri, 17 Sep 1999 14:47:05 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19990917161224.A5524@homer.louisville.edu> Keith Stevenson writes: : I seem to recall the 3.3 Release Notes stating that this problem was fixed. They do: 1.2. SECURITY FIXES ------------------- ... amd has been updated to correct a remotely exploitable root hole. ... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 13:49:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A9AF614C35 for ; Fri, 17 Sep 1999 13:49:39 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA82875; Fri, 17 Sep 1999 14:49:20 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA05040; Fri, 17 Sep 1999 14:48:19 -0600 (MDT) Message-Id: <199909172048.OAA05040@harmony.village.org> To: Poul-Henning Kamp Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG In-reply-to: Your message of "Fri, 17 Sep 1999 22:18:35 +0200." <5082.937599515@critter.freebsd.dk> References: <5082.937599515@critter.freebsd.dk> Date: Fri, 17 Sep 1999 14:48:19 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <5082.937599515@critter.freebsd.dk> Poul-Henning Kamp writes: : There is a new kid in town if it comes to fortifying your FreeBSD : box: jail(2|8) Is jail(2) in 3.3R? Or just -current? I ask because I had to have different suser tests depending on 3.x and 4.0 in the chflags security patches. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 13:54: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id A0D48158D9 for ; Fri, 17 Sep 1999 13:53:59 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id WAA05192; Fri, 17 Sep 1999 22:52:28 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Warner Losh Cc: Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Fri, 17 Sep 1999 14:48:19 MDT." <199909172048.OAA05040@harmony.village.org> Date: Fri, 17 Sep 1999 22:52:28 +0200 Message-ID: <5190.937601548@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909172048.OAA05040@harmony.village.org>, Warner Losh writes: >In message <5082.937599515@critter.freebsd.dk> Poul-Henning Kamp writes: >: There is a new kid in town if it comes to fortifying your FreeBSD >: box: jail(2|8) > >Is jail(2) in 3.3R? Or just -current? I ask because I had to have >different suser tests depending on 3.x and 4.0 in the chflags security >patches. Only current. I have no MFC plans. Although it could be trivially done I don't think there currently is a market demand for doing so, and I don't have the time anyway... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 14:42:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id A330014D3B for ; Fri, 17 Sep 1999 14:42:32 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.3/8.8.7) with ESMTP id RAA73741; Fri, 17 Sep 1999 17:42:19 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 17 Sep 1999 17:42:19 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Dag-Erling Smorgrav Cc: Will Andrews , aj@entic.net, freebsd-security@FreeBSD.org Subject: Re: ipfw question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12 Sep 1999, Dag-Erling Smorgrav wrote: > the counters. In 4.0, you can reset the log counters independently of > the match counters ('ipfw resetlog' instead of 'ipfw zero'), which > allows you to restart logging even when running at high securelevels > (all ipfw commands except resetlog are disabled at securelevel >= 3). Please note that this functionality is also in 3.3-RELEASE. > > DES > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 14:56: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from hawaii.conterra.com (hawaii.conterra.com [209.12.164.32]) by hub.freebsd.org (Postfix) with ESMTP id 8814215410 for ; Fri, 17 Sep 1999 14:56:04 -0700 (PDT) (envelope-from myself@conterra.com) Received: from dmaddox.conterra.com (root@dmaddox.conterra.com [209.12.169.48]) by hawaii.conterra.com (8.9.3/8.9.3) with ESMTP id RAA28180; Fri, 17 Sep 1999 17:55:59 -0400 (EDT) Received: (from myself@localhost) by dmaddox.conterra.com (8.9.3/8.9.1) id RAA01798; Fri, 17 Sep 1999 17:56:04 -0400 (EDT) (envelope-from myself) Date: Fri, 17 Sep 1999 17:56:03 -0400 From: "Donald J . Maddox" To: John-Mark Gurney Cc: freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info Message-ID: <19990917175603.A1571@dmaddox.conterra.com> Reply-To: dmaddox@conterra.com References: <4.1.19990913003757.0096b660@mail.thegrid.net> <4.1.19990913003757.0096b660@mail.thegrid.net> <19990913173532.A842@dmaddox.conterra.com> <3.0.3.32.19990913191825.00ad66f0@207.227.119.2> <19990913210513.A3167@dmaddox.conterra.com> <19990917120236.39316@hydrogen.fircrest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <19990917120236.39316@hydrogen.fircrest.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 17, 1999 at 12:02:36PM -0700, John-Mark Gurney wrote: > Donald J . Maddox scribbled this message on Sep 13: > > There may not be ANYTHING *BSD in the jail environment, let alone > > 'strings'. Again, assumptions. > ^^^^^^^^^^^^^^^^^^ > ummm.. yes there is... can we say ENOSYS?? I knew you could... assuming > people have write permissions and execute permissions... ^^^^^^^^ When discussing an environment one has no knowledge of whatsoever, it's not a good idea to assume a lot. For the record, it may very well be impossible to create an environment that is 100% anonymous, and yet not so crippled as to be useless; however, it may not be. I find it interesting that all the responses I've seen to this thread so far seem to assume that the environment will allow compiling and executing arbitrary code. Why would anybody assume that? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 15: 1:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 3FA461516E for ; Fri, 17 Sep 1999 15:01:07 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id QAA15233; Fri, 17 Sep 1999 16:00:18 -0600 (MDT) Message-Id: <4.2.0.58.19990917155850.047bd680@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 16:00:14 -0600 To: "Matthew D. Fuller" From: Brett Glass Subject: Re: Securing a system that's been rooted remotely (Was: BPF on in 3.3-RC GENERIC kernel) Cc: "Harry M. Leitzell" , Liam Slusser , Kenny Drobnack , security@FreeBSD.ORG In-Reply-To: <19990917134343.P16305@futuresouth.com> References: <4.2.0.58.19990916232349.047c27a0@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <4.2.0.58.19990916232349.047c27a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:43 PM 9/17/99 -0500, Matthew D. Fuller wrote: >I can't imagine anyone who would need and use a high securelevel like >that, and still run a GENERIC kernel. If they do, then their worldview >would seem to be slightly skewed. I run a custom (2.1.5-REL) kernel on >musca, which is a 386 SX/20. It took 6 hours to compile. On mortis >(4.0-CURRENT) a kernel takes approx. 2 minutes to compile. This is not a >major time investment. If securelevel isn't set high, a hacker can switch you BACK to the generic kernel with a few keystrokes. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 15: 2:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id AD82614D3B for ; Fri, 17 Sep 1999 15:02:09 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id OAA49373; Fri, 17 Sep 1999 14:58:22 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909172158.OAA49373@gndrsh.dnsmgr.net> Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <5190.937601548@critter.freebsd.dk> from Poul-Henning Kamp at "Sep 17, 1999 10:52:28 pm" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Fri, 17 Sep 1999 14:58:22 -0700 (PDT) Cc: imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In message <199909172048.OAA05040@harmony.village.org>, Warner Losh writes: > >In message <5082.937599515@critter.freebsd.dk> Poul-Henning Kamp writes: > >: There is a new kid in town if it comes to fortifying your FreeBSD > >: box: jail(2|8) > > > >Is jail(2) in 3.3R? Or just -current? I ask because I had to have > >different suser tests depending on 3.x and 4.0 in the chflags security > >patches. > > Only current. I have no MFC plans. > Although it could be trivially done I don't think there currently is > a market demand for doing so, and I don't have the time anyway... I've been waiting for this to MFC so that we could use it through out our AS. I can't run -current on production servers, I would start building jails within days of this being MFC'ed. There.. some ``market demand''. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 15: 3:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id CE93A14DDD for ; Fri, 17 Sep 1999 15:03:42 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id QAA15282; Fri, 17 Sep 1999 16:03:20 -0600 (MDT) Message-Id: <4.2.0.58.19990917160133.0483e1c0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 16:03:16 -0600 To: Warner Losh From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Cy Schubert - ITSD Open Systems Group , Darren Reed , Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG In-Reply-To: <199909171939.NAA04615@harmony.village.org> References: <4.2.0.58.19990916100439.048ebd70@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:39 PM 9/17/99 -0600, Warner Losh wrote: >The best solution would be to have the IP stack that could deal with >the needs of dhcp. Technically, DHCP really should be in its OWN stack (though it will be sending commands to control and enable the IP stack). It ought to plug in like IPX and Appletalk do. This would be a really nice, clean solution. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 15: 6:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 49EDA15924 for ; Fri, 17 Sep 1999 15:06:16 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id QAA15325; Fri, 17 Sep 1999 16:06:02 -0600 (MDT) Message-Id: <4.2.0.58.19990917160519.047cc890@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 16:05:57 -0600 To: Warner Losh From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG In-Reply-To: <199909172004.OAA04763@harmony.village.org> References: <4.2.0.58.19990916185341.00aaf100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:04 PM 9/17/99 -0600, Warner Losh wrote: > As it is, it takes a hell of a lot of work to keep root >from running completely arbitrary commands on boot. Sounds like a job for an automatic utility! --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 15: 9:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7034B1582B for ; Fri, 17 Sep 1999 15:09:21 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA83128; Fri, 17 Sep 1999 16:09:20 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA05554; Fri, 17 Sep 1999 16:08:19 -0600 (MDT) Message-Id: <199909172208.QAA05554@harmony.village.org> To: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG In-reply-to: Your message of "Fri, 17 Sep 1999 16:05:57 MDT." <4.2.0.58.19990917160519.047cc890@localhost> References: <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> Date: Fri, 17 Sep 1999 16:08:18 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990917160519.047cc890@localhost> Brett Glass writes: : At 02:04 PM 9/17/99 -0600, Warner Losh wrote: : : > As it is, it takes a hell of a lot of work to keep root : >from running completely arbitrary commands on boot. : : Sounds like a job for an automatic utility! Yes. Automation would help. Today you almost have to do chflags schg /usr/{s,}bin/* /{s,}bin/* /usr/libexec/* /etc/* /usr/lib/* to get started, but even that leaves a few holes... I'd love to see an intellegent automation tool and would happily review it. Sadly, I don't have the time to write and maintain said tool. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 15:10:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 21DAD15A05 for ; Fri, 17 Sep 1999 15:10:31 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id QAA15370; Fri, 17 Sep 1999 16:09:51 -0600 (MDT) Message-Id: <4.2.0.58.19990917160852.0476e420@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 16:09:47 -0600 To: "Rodney W. Grimes" , phk@critter.freebsd.dk (Poul-Henning Kamp) From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG In-Reply-To: <199909172158.OAA49373@gndrsh.dnsmgr.net> References: <5190.937601548@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:58 PM 9/17/99 -0700, Rodney W. Grimes wrote: >I've been waiting for this to MFC so that we could use it through out >our AS. I can't run -current on production servers, I would start >building jails within days of this being MFC'ed. > >There.. some ``market demand''. You've got more from me. I'd love to see this. In fact, I'd love to see (or learn enough to give!) a presentation on how to set it up. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 15:17: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id E747914D3B for ; Fri, 17 Sep 1999 15:17:01 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id RAA18736; Fri, 17 Sep 1999 17:16:56 -0500 (CDT) Date: Fri, 17 Sep 1999 17:16:56 -0500 From: "Matthew D. Fuller" To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: Securing a system that's been rooted remotely (Was: BPF on in 3.3-RC GENERIC kernel) Message-ID: <19990917171656.H4975@futuresouth.com> References: <4.2.0.58.19990916232349.047c27a0@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <19990917134343.P16305@futuresouth.com> <4.2.0.58.19990917155850.047bd680@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <4.2.0.58.19990917155850.047bd680@localhost>; from Brett Glass on Fri, Sep 17, 1999 at 04:00:14PM -0600 X-OS: FreeBSD Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 17, 1999 at 04:00:14PM -0600, a little birdie told me that Brett Glass remarked > > If securelevel isn't set high, a hacker can switch you BACK to the generic > kernel with a few keystrokes. You missed my main thrust. Why would you go to all the trouble to enable securelevels (usefully. read; flagging everyone and their mother), and still be running GENERIC? If you're not running GENERIC, you're running a custom kernel. If you're running a custom kernel, you're customizing stuff anyway, so you can take out/put in bpf or whatever you want. Where's the problem? -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 15:30:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id C18931517A for ; Fri, 17 Sep 1999 15:30:03 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 23121 invoked from network); 17 Sep 1999 22:29:59 -0000 Received: from shell-2.enteract.com (dscheidt@207.229.143.41) by pop3-3.enteract.com with SMTP; 17 Sep 1999 22:29:59 -0000 Date: Fri, 17 Sep 1999 17:29:57 -0500 (CDT) From: David Scheidt To: Brett Glass Cc: Greg Lewis , Evren Yurtesen , freebsd-security@FreeBSD.ORG Subject: Re: Securing a system that's been rooted remotely In-Reply-To: <4.2.0.58.19990917092237.044f3f00@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 17 Sep 1999, Brett Glass wrote: > By the way, why is it that "apropos securelevel" turns up nothing? > Considering that it's documented in a non-intuitive place (the > man page for init(8)), it ouught to be searchable. > > --Brett I doubt anyone will object to your writing a man page for the kern.securelevel sysctl, and submitting it as a PR. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 16: 8:35 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 834281503E; Fri, 17 Sep 1999 16:08:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 776B71CD47B; Fri, 17 Sep 1999 16:08:33 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Fri, 17 Sep 1999 16:08:33 -0700 (PDT) From: Kris Kennaway To: Brett Glass Cc: "Matthew D. Fuller" , security@FreeBSD.ORG Subject: Re: Securing a system that's been rooted remotely (Was: BPF on in 3.3-RC GENERIC kernel) In-Reply-To: <4.2.0.58.19990917155850.047bd680@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 17 Sep 1999, Brett Glass wrote: > At 01:43 PM 9/17/99 -0500, Matthew D. Fuller wrote: > > >I can't imagine anyone who would need and use a high securelevel like > >that, and still run a GENERIC kernel. If they do, then their worldview > >would seem to be slightly skewed. I run a custom (2.1.5-REL) kernel on > >musca, which is a 386 SX/20. It took 6 hours to compile. On mortis > >(4.0-CURRENT) a kernel takes approx. 2 minutes to compile. This is not a > >major time investment. > > If securelevel isn't set high, a hacker can switch you BACK to the generic > kernel with a few keystrokes. You're missing Matthew's point: Securelevel low, GENERIC kernel = vulnerable with or without bpf (intruder replaces kernel or loads a sniffer module) Securelevel high, GENERIC kernel = still vulnerable with or without bpf unless you really lock the system down carefully Securelevel high, GENERIC kernel, locked down with schg = silly, because for all the work you've done to audit the startup path, you might as well have just commented out the bpf driver and rebuilt your kernel too. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 16:15:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id 7F8B615B23 for ; Fri, 17 Sep 1999 16:15:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA04190 for ; Fri, 17 Sep 1999 16:12:30 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA55902; Fri, 17 Sep 1999 15:59:11 -0700 (PDT) (envelope-from dillon) Date: Fri, 17 Sep 1999 15:59:11 -0700 (PDT) From: Matthew Dillon Message-Id: <199909172259.PAA55902@apollo.backplane.com> To: Warner Losh Cc: Brett Glass , Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <199909172208.QAA05554@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Yes. Automation would help. Today you almost have to do : chflags schg /usr/{s,}bin/* /{s,}bin/* /usr/libexec/* /etc/* /usr/lib/* :to get started, but even that leaves a few holes... : :I'd love to see an intellegent automation tool and would happily :review it. Sadly, I don't have the time to write and maintain said :tool. : :Warner At BEST I cared about two things security-wise: (1) preventing non-root users from being able to gain root, and (2) detecting those intrusions that actually manage to break through to root. Making a system reasonably secure does not equate to protecting root from itself. If someone has root, you've lost. Period. It doesn't matter whether they can modify the system or not, you've still lost. Trying to protect root from itself only prevents your security scripts from detecting the fact that you've lost. In that respect, I find chflags utterly useless and the securelevel only moderately less so. All they do is prevent the hacker from making changes that would otherwise cause his presence to be detected. I still use it to some degree -- I think a distinction should absolutely be made between raw device access and access through a filesystem, but the primary purpose of those tools is simply to create enough of a delay to be able to react to a situation. Having the schg flag and securelevel give you useful tools, but you shoot yourself in the foot if you overuse them or come to depend on them. Believe me, chflaging half the files in / and /usr to schg is a major overuse. By the time you've schg'd everything to the point where root is supposedly 'safe', you might as well have simply mounted / and /usr read-only in the first place. It would have been easier. This is what I might recommend for a poor-sysad's security: * Setup the systems * Quietly do a read-only NFS export of everything from every system to a secure security box that only one or two people can get into. * Have that box md5 (etc....) and test the files for changes, for suid bits, and so forth. Once a night, every night, and to notify you if something changes. Check system configuration files even more often - doesn't cost you a thing to check a dozen or two files on every machine once every 5 minutes! I'm going to update my security page ( man 'security' ), it's a little dated. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 16:16:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id 3FDA415567; Fri, 17 Sep 1999 16:16:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA04468; Fri, 17 Sep 1999 16:12:41 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA25509; Mon, 13 Sep 1999 13:17:56 -0700 (PDT) (envelope-from dillon) Date: Mon, 13 Sep 1999 13:17:56 -0700 (PDT) From: Matthew Dillon Message-Id: <199909132017.NAA25509@apollo.backplane.com> To: Garrett Wollman Cc: Bosko Milekic , Stas Kisel , avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) References: <199909091447.SAA24055@sonet.crimea.ua> <199909131840.OAA31048@khavrinen.lcs.mit.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :In 4.3, the code was able to deal with cluster allocation failing. We :have a somewhat different situation now, because many network :interface devices have less-flexible DMA mechanisms which don't allow :packet reception into non-contiguous buffers, so we need to have at :least a certain number of clusters available for this purpose. : :-GAWollman : :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same This is an interrupt level mechanism. The mbuf code is *already* allowed to (and does) return NULL in this case so I don't think it applies to the problem under discussion. The case that is causing the panics is with the non-interrupt mbuf allocation mechanism. Specifically, the case where M_WAIT is used. The second problem under discussion, which really ought to be separated out from the mbuf panic problem, is the potential for a deadlock or denial of service attack when the system is attacked in a manner that eats all available mbufs. :wollman@lcs.mit.edu | O Siem / The fires of freedom :Opinions not those of| Dance in the burning flame -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 16:17:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id 1880115B68; Fri, 17 Sep 1999 16:16:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA04542; Fri, 17 Sep 1999 16:12:46 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA20252; Sun, 12 Sep 1999 20:36:59 -0700 (PDT) (envelope-from dillon) Date: Sun, 12 Sep 1999 20:36:59 -0700 (PDT) From: Matthew Dillon Message-Id: <199909130336.UAA20252@apollo.backplane.com> To: Bosko Milekic Cc: Stas Kisel , avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think that what needs to be done is to split the problem in two. First, allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT is used, it simply means 'try harder, sleeping a bit if necessary'. This requires ensuring that all the networking code deal with the failure case - a time consuming but straightforward task. If a failure occurs, one simply drops the packet, not the connection or anything else drastic. just the packet. The second problem that needs to be addressed is resource exhaustion. For example, allocating thousands of connections and socket-opting their buffers as large as possible, or programs such as syslog accepting new connections ad-infinitum. This is a harder problem to fix properly, but a lot of the various issues such as those with syslog can be dealt with in userland rather then the kernel. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 16:45: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from news.lucky.net (news.lucky.net [193.193.193.102]) by hub.freebsd.org (Postfix) with ESMTP id 5AA4515113 for ; Fri, 17 Sep 1999 16:44:28 -0700 (PDT) (envelope-from mail@news.lucky.net) Received: (from mail@localhost) by news.lucky.net (8.Who.Cares/8.Who.Cares) id CAA02506 for freebsd-security@freebsd.org; Sat, 18 Sep 1999 02:44:17 +0300 (envelope-from mail) To: freebsd-security@freebsd.org From: ay@sita.kiev.ua.europe Subject: Re: ipfw and syslogd User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/3.1-RELEASE (i386)) Organization: Home Sweet Home Message-ID: References: Date: Fri, 17 Sep 1999 21:20:51 GMT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brian F. Feldman wrote: > On Thu, 16 Sep 1999, Crist J. Clark wrote: >> Dag-Erling Smorgrav wrote, >> > Root writes: >> > > !ipfw >> > > *.* /var/log/firewall.log >> > >> > Won't work in -STABLE, because ip_fw.c uses printf() instead of log(). > It should work just fine, since printf()s go to syslog too. >> >> Bug or feature? >> > Neither. I just haven't merged back the changes which make ipfw use log(9). > (I should say "yet," as I hope to do so soon.) Is it a nice way to speed up kernel ? One may use ipfw show from cron to store most of valuable information from ipfw. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 16:56:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from news.lucky.net (news.lucky.net [193.193.193.102]) by hub.freebsd.org (Postfix) with ESMTP id BB86414F0A for ; Fri, 17 Sep 1999 16:56:19 -0700 (PDT) (envelope-from ay@sita.kiev.ua) Received: (from mail@localhost) by news.lucky.net (8.Who.Cares/8.Who.Cares) id CAA02689 for freebsd-security@freebsd.org; Sat, 18 Sep 1999 02:55:42 +0300 (envelope-from ay@sita.kiev.ua) To: freebsd-security@freebsd.org From: ay@sita.kiev.ua.europe Subject: Re: ipfw and syslogd User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/3.1-RELEASE (i386)) Organization: Home Sweet Home Message-ID: References: Date: Fri, 17 Sep 1999 21:20:51 GMT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brian F. Feldman wrote: > On Thu, 16 Sep 1999, Crist J. Clark wrote: >> Dag-Erling Smorgrav wrote, >> > Root writes: >> > > !ipfw >> > > *.* /var/log/firewall.log >> > >> > Won't work in -STABLE, because ip_fw.c uses printf() instead of log(). > It should work just fine, since printf()s go to syslog too. >> >> Bug or feature? >> > Neither. I just haven't merged back the changes which make ipfw use log(9). > (I should say "yet," as I hope to do so soon.) Is it a nice way to speed up kernel ? One may use ipfw show from cron to store most of valuable information from ipfw. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 19: 7:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 7E083154D4 for ; Fri, 17 Sep 1999 19:07:38 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA17036; Fri, 17 Sep 1999 20:07:30 -0600 (MDT) Message-Id: <4.2.0.58.19990917162715.047cbb10@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 16:29:27 -0600 To: "Matthew D. Fuller" From: Brett Glass Subject: Re: Securing a system that's been rooted remotely (Was: BPF on in 3.3-RC GENERIC kernel) Cc: security@FreeBSD.ORG In-Reply-To: <19990917171656.H4975@futuresouth.com> References: <4.2.0.58.19990917155850.047bd680@localhost> <4.2.0.58.19990916232349.047c27a0@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <19990917134343.P16305@futuresouth.com> <4.2.0.58.19990917155850.047bd680@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The problem is similar to that of having a standard "administrator" password that has to be changed during installation of a hardware/software product. A certain percentage of people -- no matter how smart -- will neglect to change it. Just as a general rule of thumb and guiding principle, things that make the system more insecure should be off by default. --Brett At 05:16 PM 9/17/99 -0500, Matthew D. Fuller wrote: >You missed my main thrust. >Why would you go to all the trouble to enable securelevels (usefully. >read; flagging everyone and their mother), and still be running GENERIC? >If you're not running GENERIC, you're running a custom kernel. If you're >running a custom kernel, you're customizing stuff anyway, so you can take >out/put in bpf or whatever you want. Where's the problem? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 19:13:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 47B2E15256 for ; Fri, 17 Sep 1999 19:13:31 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA17087; Fri, 17 Sep 1999 20:13:13 -0600 (MDT) Message-Id: <4.2.0.58.19990917201149.046f2420@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 20:12:52 -0600 To: David Scheidt From: Brett Glass Subject: Re: Securing a system that's been rooted remotely Cc: Greg Lewis , Evren Yurtesen , freebsd-security@FreeBSD.ORG In-Reply-To: References: <4.2.0.58.19990917092237.044f3f00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Actually, it'd be simpler to make "man securelevel" bring up security(7) or init(8). And "apropos securelevel" should produce both. --Brett At 05:29 PM 9/17/99 -0500, David Scheidt wrote: >On Fri, 17 Sep 1999, Brett Glass wrote: > > > By the way, why is it that "apropos securelevel" turns up nothing? > > Considering that it's documented in a non-intuitive place (the > > man page for init(8)), it ouught to be searchable. > > > > --Brett > >I doubt anyone will object to your writing a man page for the >kern.securelevel sysctl, and submitting it as a PR. > >David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 19:21:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id BFF14154A8 for ; Fri, 17 Sep 1999 19:21:34 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA17174; Fri, 17 Sep 1999 20:21:17 -0600 (MDT) Message-Id: <4.2.0.58.19990917201820.046f09e0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 17 Sep 1999 20:21:15 -0600 To: Matthew Dillon , Warner Losh From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG In-Reply-To: <199909172259.PAA55902@apollo.backplane.com> References: <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <199909172208.QAA05554@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 03:59 PM 9/17/99 -0700, Matthew Dillon wrote: > Making a system reasonably secure does not equate to protecting root from > itself. If someone has root, you've lost. Period. It doesn't matter > whether they can modify the system or not, you've still lost. See my article at http://boardwatch.internet.com/mag/98/dec/bwm62.html regarding why this is ungood. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 19:45:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6338414DC6 for ; Fri, 17 Sep 1999 19:45:08 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA83885; Fri, 17 Sep 1999 20:45:07 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA07013; Fri, 17 Sep 1999 20:44:08 -0600 (MDT) Message-Id: <199909180244.UAA07013@harmony.village.org> To: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: security@FreeBSD.ORG In-reply-to: Your message of "Fri, 17 Sep 1999 20:21:15 MDT." <4.2.0.58.19990917201820.046f09e0@localhost> References: <4.2.0.58.19990917201820.046f09e0@localhost> <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <199909172208.QAA05554@harmony.village.org> Date: Fri, 17 Sep 1999 20:44:08 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990917201820.046f09e0@localhost> Brett Glass writes: : http://boardwatch.internet.com/mag/98/dec/bwm62.html Are you sure that is the right URL? I can't seem to get to it from here... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 19:59:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 592DA14E6C; Fri, 17 Sep 1999 19:59:48 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.3/8.8.7) with ESMTP id WAA83493; Fri, 17 Sep 1999 22:58:30 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 17 Sep 1999 22:58:30 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Garrett Wollman , Bosko Milekic , Stas Kisel , avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.org, freebsd-security@FreeBSD.org Subject: Re: mbuf shortage situations (followup) In-Reply-To: <199909132017.NAA25509@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 13 Sep 1999, Matthew Dillon wrote: > The case that is causing the panics is with the non-interrupt mbuf > allocation mechanism. Specifically, the case where M_WAIT is used. > > The second problem under discussion, which really ought to be separated > out from the mbuf panic problem, is the potential for a deadlock or > denial of service attack when the system is attacked in a manner that > eats all available mbufs. > The traditional way to prevent resource-starvation DoSes from the user populus has been to add administrative limits. Using RLIMIT_SBSIZE does this nicely. Yes, this isn't actually fixing the panics, but it is good preventative medicine. > -Matt > Matthew Dillon > > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 22:14:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 036231556D for ; Fri, 17 Sep 1999 22:14:49 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SCpi-0006m8-00; Fri, 17 Sep 1999 23:14:46 -0600 Message-ID: <37E2C9B0.BD5846BB@softweyr.com> Date: Fri, 17 Sep 1999 17:07:28 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brett Glass Cc: Greg Lewis , Evren Yurtesen , freebsd-security@FreeBSD.ORG Subject: Re: Securing a system that's been rooted remotely References: <37E21A0A.1075F204@ispro.net.tr> <4.2.0.58.19990917092237.044f3f00@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > By the way, why is it that "apropos securelevel" turns up nothing? > Considering that it's documented in a non-intuitive place (the > man page for init(8)), it ouught to be searchable. Because the NAME entry for init(8) doesn't mention "securelevel." I don't see how you could write a meaningful entry and work securelevel into it. Perhaps adding securelevel as an alternate name would help. What we really need is a good index to the man pages. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 22:30:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 121EF1550D for ; Fri, 17 Sep 1999 22:30:16 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SD4g-0000l6-00; Fri, 17 Sep 1999 23:30:15 -0600 Message-ID: <37E32365.B9F9573B@softweyr.com> Date: Fri, 17 Sep 1999 23:30:13 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <4.2.0.58.19990917201820.046f09e0@localhost> <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <199909172208.QAA05554@harmony.village.org> <199909180244.UAA07013@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > In message <4.2.0.58.19990917201820.046f09e0@localhost> Brett Glass writes: > : http://boardwatch.internet.com/mag/98/dec/bwm62.html > > Are you sure that is the right URL? I can't seem to get to it from > here... Worked for me. A well-written, accurate analogy too. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 23:13:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 024F014F41 for ; Fri, 17 Sep 1999 23:13:42 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA84316; Sat, 18 Sep 1999 00:13:41 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA00597; Sat, 18 Sep 1999 00:12:30 -0600 (MDT) Message-Id: <199909180612.AAA00597@harmony.village.org> To: Wes Peters Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: Brett Glass , security@FreeBSD.ORG In-reply-to: Your message of "Fri, 17 Sep 1999 23:30:13 MDT." <37E32365.B9F9573B@softweyr.com> References: <37E32365.B9F9573B@softweyr.com> <4.2.0.58.19990917201820.046f09e0@localhost> <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <199909172208.QAA05554@harmony.village.org> <199909180244.UAA07013@harmony.village.org> Date: Sat, 18 Sep 1999 00:12:30 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <37E32365.B9F9573B@softweyr.com> Wes Peters writes: : Worked for me. A well-written, accurate analogy too. I'll have to try again later... I'd be very interested in this. I personally think that schg is useful against accidental mistakes, but flawed in implementation. Although some of that may be due to inperfections in /etc/rc and friends. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 23:18:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id E2B76154F3 for ; Fri, 17 Sep 1999 23:18:08 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id XAA50598; Fri, 17 Sep 1999 23:17:44 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909180617.XAA50598@gndrsh.dnsmgr.net> Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <37E32365.B9F9573B@softweyr.com> from Wes Peters at "Sep 17, 1999 11:30:13 pm" To: wes@softweyr.com (Wes Peters) Date: Fri, 17 Sep 1999 23:17:44 -0700 (PDT) Cc: imp@village.org (Warner Losh), brett@lariat.org (Brett Glass), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Warner Losh wrote: > > > > In message <4.2.0.58.19990917201820.046f09e0@localhost> Brett Glass writes: > > : http://boardwatch.internet.com/mag/98/dec/bwm62.html > > > > Are you sure that is the right URL? I can't seem to get to it from > > here... > > Worked for me. A well-written, accurate analogy too. Good article! Hummm... I wonder how many of those contractor badges laying in my drawer still work... :-). -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 23:24:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id B5A3E152F0 for ; Fri, 17 Sep 1999 23:24:27 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id XAA50611; Fri, 17 Sep 1999 23:24:07 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909180624.XAA50611@gndrsh.dnsmgr.net> Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <199909180612.AAA00597@harmony.village.org> from Warner Losh at "Sep 18, 1999 00:12:30 am" To: imp@village.org (Warner Losh) Date: Fri, 17 Sep 1999 23:24:07 -0700 (PDT) Cc: wes@softweyr.com (Wes Peters), brett@lariat.org (Brett Glass), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In message <37E32365.B9F9573B@softweyr.com> Wes Peters writes: > : Worked for me. A well-written, accurate analogy too. > > I'll have to try again later... I'd be very interested in this. I > personally think that schg is useful against accidental mistakes, but > flawed in implementation. > > Although some of that may be due to inperfections in /etc/rc and > friends. Once you read the article you will see just how flawed ``schg'' is. It only attempts to prevent action, it does not send out any alarms. The propasal that jdp has on a socket sort of notification facility for all file system modifications is a long was ahead of what could ever be done with schg, as that tool would give us the ability to real time audit even attempts at cracking on the system. ACF2 in the mainframe world, and the VMS AUDIT tools are good examples of what can be done with this type of feature. Real time alarms if someone even _tries_ to modify a schg file is what is missing... someone turning off schg on a file is another thing missing... or accessing the disk through the raw device to reset the bit, etc, etc... -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 23:29:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 5BB79152F0 for ; Fri, 17 Sep 1999 23:29:45 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA02095; Fri, 17 Sep 1999 23:28:39 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Rodney W. Grimes" Cc: imp@village.org (Warner Losh), wes@softweyr.com (Wes Peters), brett@lariat.org (Brett Glass), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Fri, 17 Sep 1999 23:24:07 PDT." <199909180624.XAA50611@gndrsh.dnsmgr.net> Date: Fri, 17 Sep 1999 23:28:39 -0700 Message-ID: <2091.937636119@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm surprised nobody has brought up /dev/audit and the whole Digital Unix approach to security (OS-level event monitoring and active counter-measures). It's not like there aren't a number of existing examples to choose from when debating a "better course" of action. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 23:33:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 6CB8814C0D for ; Fri, 17 Sep 1999 23:33:36 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id XAA50642; Fri, 17 Sep 1999 23:33:10 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909180633.XAA50642@gndrsh.dnsmgr.net> Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <2091.937636119@localhost> from "Jordan K. Hubbard" at "Sep 17, 1999 11:28:39 pm" To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Fri, 17 Sep 1999 23:33:10 -0700 (PDT) Cc: imp@village.org (Warner Losh), wes@softweyr.com (Wes Peters), brett@lariat.org (Brett Glass), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm surprised nobody has brought up /dev/audit and the whole Digital > Unix approach to security (OS-level event monitoring and active > counter-measures). It's not like there aren't a number of existing > examples to choose from when debating a "better course" of action. Can you give me an ISBN number or Digital Press title that would have the details about Digital Unix's implementation of /dev/audit? I've had the fortanate experience of not having to work on any modern Digital OS's (last was VMS 5.0 and Ultrix 3.x). I wonder if /dev/audit is lifted right out of VMS's SYS$AUDIT:. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 23:39:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E681C14FFA for ; Fri, 17 Sep 1999 23:39:25 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA84423; Sat, 18 Sep 1999 00:39:24 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA00735; Sat, 18 Sep 1999 00:38:13 -0600 (MDT) Message-Id: <199909180638.AAA00735@harmony.village.org> To: "Rodney W. Grimes" Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: jkh@zippy.cdrom.com (Jordan K. Hubbard), wes@softweyr.com (Wes Peters), brett@lariat.org (Brett Glass), security@FreeBSD.ORG In-reply-to: Your message of "Fri, 17 Sep 1999 23:33:10 PDT." <199909180633.XAA50642@gndrsh.dnsmgr.net> References: <199909180633.XAA50642@gndrsh.dnsmgr.net> Date: Sat, 18 Sep 1999 00:38:13 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909180633.XAA50642@gndrsh.dnsmgr.net> "Rodney W. Grimes" writes: : I've had the fortanate experience of not having to work on any modern : Digital OS's (last was VMS 5.0 and Ultrix 3.x). I wonder if /dev/audit : is lifted right out of VMS's SYS$AUDIT:. In conversations that I had with folks from inside digital over the years, I've been told that this was one of the things written in BLISS that was ported to Ultrix. However, I am suspicious about this assertion give what I now know about the internals of both VMS and BSD these days. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 23:56:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from mg136-146.ricochet.net (mg136-146.ricochet.net [204.179.136.146]) by hub.freebsd.org (Postfix) with ESMTP id 6055514F73 for ; Fri, 17 Sep 1999 23:56:17 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.fircrest.net (8.9.1/8.8.7) id MAA14040; Fri, 17 Sep 1999 12:02:42 -0700 (PDT) Message-ID: <19990917120236.39316@hydrogen.fircrest.net> Date: Fri, 17 Sep 1999 12:02:36 -0700 From: John-Mark Gurney To: dmaddox@conterra.com Cc: "Jeffrey J. Mountin" , freebsd-security@FreeBSD.ORG Subject: Re: How to prevent motd including os info References: <4.1.19990913003757.0096b660@mail.thegrid.net> <4.1.19990913003757.0096b660@mail.thegrid.net> <19990913173532.A842@dmaddox.conterra.com> <3.0.3.32.19990913191825.00ad66f0@207.227.119.2> <19990913210513.A3167@dmaddox.conterra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19990913210513.A3167@dmaddox.conterra.com>; from Donald J . Maddox on Mon, Sep 13, 1999 at 09:05:13PM -0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Donald J . Maddox scribbled this message on Sep 13: > There may not be ANYTHING *BSD in the jail environment, let alone > 'strings'. Again, assumptions. ummm.. yes there is... can we say ENOSYS?? I knew you could... assuming people have write permissions and execute permissions... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 17 23:57:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from jason.argos.org (a1-3a123.neo.rr.com [24.93.180.123]) by hub.freebsd.org (Postfix) with ESMTP id C768F159BE for ; Fri, 17 Sep 1999 23:57:37 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id CAA30838 for ; Sat, 18 Sep 1999 02:57:35 -0400 Date: Sat, 18 Sep 1999 02:57:35 -0400 (EDT) From: Mike Nowlin To: security@freebsd.org Subject: Re: Securing a system that's been rooted remotely (Was: BPF on in 3.3-RC GENERIC kernel) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Securelevel high, GENERIC kernel, locked down with schg = silly, because > for all the work you've done to audit the startup path, you might as well > have just commented out the bpf driver and rebuilt your kernel too. This whole discussion is silly... We've beat it into the ground several times now, and there's valid arguments on both sides. Everyone should make their own decision. The guys who decide what's in GENERIC are probably sick and tired of hearing about the pitfalls of BPF. They seem to think (and I agree) that it's easier to re-compile the kernel than fix all of the BPF-related problems. If you're worried about somebody kicking your system over to a GENERIC kernel, then just remove the damn thing and fix the boot files. mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 0: 0:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id D3FC715867 for ; Sat, 18 Sep 1999 00:00:28 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SETv-0004RS-00; Sat, 18 Sep 1999 01:00:23 -0600 Message-ID: <37E33885.B2B42D8C@softweyr.com> Date: Sat, 18 Sep 1999 01:00:21 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <37E32365.B9F9573B@softweyr.com> <4.2.0.58.19990917201820.046f09e0@localhost> <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <199909172208.QAA05554@harmony.village.org> <199909180244.UAA07013@harmony.village.org> <199909180612.AAA00597@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > In message <37E32365.B9F9573B@softweyr.com> Wes Peters writes: > : Worked for me. A well-written, accurate analogy too. > > I'll have to try again later... I'd be very interested in this. I > personally think that schg is useful against accidental mistakes, but > flawed in implementation. Agreed. It's a good tool, but isn't going to stop somebody who's both clever and dedicated. A similar facility in VMS didn't stop Kevin Mittnick from stealing the VMS source code from my ex-boss. ;^) > Although some of that may be due to inperfections in /etc/rc and > friends. I think a lot of the system startup just happened, rather than being designed from a security standpoint. I'm attempting to land myself a job where I would be paid to fix this, among other things. I'll let you all know if/when it happens. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 0: 3: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 9A274158C0 for ; Sat, 18 Sep 1999 00:03:00 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SEWQ-0004fq-00; Sat, 18 Sep 1999 01:02:58 -0600 Message-ID: <37E33920.A768C899@softweyr.com> Date: Sat, 18 Sep 1999 01:02:56 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Rodney W. Grimes" Cc: Warner Losh , Brett Glass , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <199909180624.XAA50611@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rodney W. Grimes" wrote: > > Once you read the article you will see just how flawed ``schg'' is. It > only attempts to prevent action, it does not send out any alarms. > > The propasal that jdp has on a socket sort of notification facility for > all file system modifications is a long was ahead of what could ever > be done with schg, as that tool would give us the ability to real time > audit even attempts at cracking on the system. ACF2 in the mainframe > world, and the VMS AUDIT tools are good examples of what can be done > with this type of feature. Real time alarms if someone even _tries_ > to modify a schg file is what is missing... someone turning off > schg on a file is another thing missing... or accessing the disk > through the raw device to reset the bit, etc, etc... I once spend a few days looking into a filesystem monitor. It was a good idea, but the powers that be decided they should leave that level of intervention to the system vendors (SunOS, Ultrix, etc). I told them I could do it by trapping the syscalls and they got the willies. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 0: 6:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 583E31585D for ; Sat, 18 Sep 1999 00:06:33 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SEZs-0005cZ-00; Sat, 18 Sep 1999 01:06:32 -0600 Message-ID: <37E339F6.F5C889D6@softweyr.com> Date: Sat, 18 Sep 1999 01:06:30 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: "Rodney W. Grimes" , "Jordan K. Hubbard" , Brett Glass , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <199909180633.XAA50642@gndrsh.dnsmgr.net> <199909180638.AAA00735@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > In message <199909180633.XAA50642@gndrsh.dnsmgr.net> "Rodney W. Grimes" writes: > : I've had the fortanate experience of not having to work on any modern > : Digital OS's (last was VMS 5.0 and Ultrix 3.x). I wonder if /dev/audit > : is lifted right out of VMS's SYS$AUDIT:. > > In conversations that I had with folks from inside digital over the > years, I've been told that this was one of the things written in BLISS > that was ported to Ultrix. However, I am suspicious about this > assertion give what I now know about the internals of both VMS and BSD > these days. As Terry used to say, "BLISS is ignorance." A well-defined and well-architected syscall auditing mechanism would be a great security addition, and right up the alley of what I'm looking for. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 0: 7: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 2AFCC158A2 for ; Sat, 18 Sep 1999 00:06:43 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SEa0-0005d0-00; Sat, 18 Sep 1999 01:06:41 -0600 Message-ID: <37E2C9B0.BD5846BB@softweyr.com> Date: Fri, 17 Sep 1999 17:07:28 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brett Glass Cc: Greg Lewis , Evren Yurtesen , freebsd-security@FreeBSD.ORG Subject: Re: Securing a system that's been rooted remotely References: <37E21A0A.1075F204@ispro.net.tr> <4.2.0.58.19990917092237.044f3f00@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > By the way, why is it that "apropos securelevel" turns up nothing? > Considering that it's documented in a non-intuitive place (the > man page for init(8)), it ouught to be searchable. Because the NAME entry for init(8) doesn't mention "securelevel." I don't see how you could write a meaningful entry and work securelevel into it. Perhaps adding securelevel as an alternate name would help. What we really need is a good index to the man pages. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 0:12: 1 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 8A97814DDD for ; Sat, 18 Sep 1999 00:11:51 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id AAA50768; Sat, 18 Sep 1999 00:11:35 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909180711.AAA50768@gndrsh.dnsmgr.net> Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <37E33885.B2B42D8C@softweyr.com> from Wes Peters at "Sep 18, 1999 01:00:21 am" To: wes@softweyr.com (Wes Peters) Date: Sat, 18 Sep 1999 00:11:35 -0700 (PDT) Cc: imp@village.org (Warner Losh), brett@lariat.org (Brett Glass), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Warner Losh wrote: > > > > In message <37E32365.B9F9573B@softweyr.com> Wes Peters writes: > > : Worked for me. A well-written, accurate analogy too. > > > > I'll have to try again later... I'd be very interested in this. I > > personally think that schg is useful against accidental mistakes, but > > flawed in implementation. > > Agreed. It's a good tool, but isn't going to stop somebody who's both > clever and dedicated. A similar facility in VMS didn't stop Kevin > Mittnick from stealing the VMS source code from my ex-boss. ;^) But SYS$AUDIT would have at least let him know it was stolen :-). And perhaps alerted him before Kevin got out the door with the tape. > > > Although some of that may be due to inperfections in /etc/rc and > > friends. > > I think a lot of the system startup just happened, rather than being > designed from a security standpoint. I'm attempting to land myself a > job where I would be paid to fix this, among other things. I'll let > you all know if/when it happens. 99% of most OS's ``just happen'' without concern for secuirity. And good luck on that new work load your digging yourself in for!! -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 0:22:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 207A414DE5 for ; Sat, 18 Sep 1999 00:22:30 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id AAA02246; Sat, 18 Sep 1999 00:22:02 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Rodney W. Grimes" Cc: jkh@zippy.cdrom.com (Jordan K. Hubbard), imp@village.org (Warner Losh), wes@softweyr.com (Wes Peters), brett@lariat.org (Brett Glass), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Fri, 17 Sep 1999 23:33:10 PDT." <199909180633.XAA50642@gndrsh.dnsmgr.net> Date: Sat, 18 Sep 1999 00:22:02 -0700 Message-ID: <2242.937639322@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Can you give me an ISBN number or Digital Press title that would have > the details about Digital Unix's implementation of /dev/audit? I cannot. The best I could suggest would be the same learning method I used - get ahold of a copy of Digital Unix and play around with it, reading man pages and those small portions of its documentation set which actually help. If you can have Digital to pay you to do it, this also helps. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 0:24:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id E1BFA14D63 for ; Sat, 18 Sep 1999 00:24:14 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id AAA50876; Sat, 18 Sep 1999 00:24:08 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909180724.AAA50876@gndrsh.dnsmgr.net> Subject: Re: Securing a system that's been rooted remotely In-Reply-To: <37E2C9B0.BD5846BB@softweyr.com> from Wes Peters at "Sep 17, 1999 05:07:28 pm" To: wes@softweyr.com (Wes Peters) Date: Sat, 18 Sep 1999 00:24:07 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [CC trimmed to -security] > Brett Glass wrote: > > > > By the way, why is it that "apropos securelevel" turns up nothing? > > Considering that it's documented in a non-intuitive place (the > > man page for init(8)), it ouught to be searchable. > > Because the NAME entry for init(8) doesn't mention "securelevel." I don't > see how you could write a meaningful entry and work securelevel into it. > Perhaps adding securelevel as an alternate name would help. > > What we really need is a good index to the man pages. Yea, what ever happend to ptx(1): gndrsh:root {1206}# man ptx No manual entry for ptx gndrsh:root {1207}# which ptx /usr/bin/ptx gndrsh:root {1208}# Hummm.. part of groff... probably info file documents, yep there it is. What would it take to get this thing building the Permuted Index again? cd /usr/share/man/man7; zcat *.gz | nroff -mandoc | col -b | ptx | more makes for some interesting reading :-). -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 0:29:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 4333F14DE5 for ; Sat, 18 Sep 1999 00:29:13 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id AAA02286; Sat, 18 Sep 1999 00:28:54 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Wes Peters Cc: Warner Losh , "Rodney W. Grimes" , "Jordan K. Hubbard" , Brett Glass , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Sat, 18 Sep 1999 01:06:30 MDT." <37E339F6.F5C889D6@softweyr.com> Date: Sat, 18 Sep 1999 00:28:54 -0700 Message-ID: <2282.937639734@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > A well-defined and well-architected syscall auditing mechanism would be a > great security addition, and right up the alley of what I'm looking for. Well, that much I thought Robert Watson had already done... See his postings in -current on the topic or go to http://www.watson.org/fbsd-hardening/posix1e/ - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 1:21:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from tusk.mountain-inter.net (tusk.mountain-inter.net [204.244.200.1]) by hub.freebsd.org (Postfix) with ESMTP id F362514ED4 for ; Sat, 18 Sep 1999 01:21:15 -0700 (PDT) (envelope-from sreid@sea-to-sky.net) Received: from grok.localnet (dialup17.mountain-inter.net [204.244.200.26]) by tusk.mountain-inter.net (8.9.3/8.8.7) with ESMTP id BAA28624; Sat, 18 Sep 1999 01:21:02 -0700 Received: by grok.localnet (Postfix, from userid 1000) id 0A10B212E07; Sat, 18 Sep 1999 01:25:39 -0700 (PDT) Date: Sat, 18 Sep 1999 01:25:39 -0700 From: Steve To: Warner Losh Cc: Brett Glass , Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel Message-ID: <19990918012538.A1195@grok.localnet> References: <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <4.2.0.58.19990917160519.047cc890@localhost> <199909172208.QAA05554@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199909172208.QAA05554@harmony.village.org>; from Warner Losh on Fri, Sep 17, 1999 at 04:08:18PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 17, 1999 at 04:08:18PM -0600, Warner Losh wrote: > In message <4.2.0.58.19990917160519.047cc890@localhost> Brett Glass writes: > : Sounds like a job for an automatic utility! > > Yes. Automation would help. Today you almost have to do > chflags schg /usr/{s,}bin/* /{s,}bin/* /usr/libexec/* /etc/* /usr/lib/* > to get started, but even that leaves a few holes... I think the boot scripts should be redesigned to do only what is really necessary pre-securelevel, raise the securelevel ASAP, then pass control to post-securelevel scripts. Keep the chflags requirements to a minimum. I sort of plan to do this for my own systems. Really, I have slightly more grandiose plans, mainly allowing remote sysadmin (that's me) to upload scripts and have them run pre-securelevel: stick them in a directory, reboot, and have the boot process run them after verifying PGP signatures (and sequence numbers to prevent replay attacks). For those times when you just _have_ to fix a vulnerability involving a schg file but can't get to the console for a while. This of course conflicts somewhat with my previous paragraph. I would be happy to share such a boot process if/when I actually get around to doing it. I don't think it would be very difficult. As for automating the lock-down procedure, I would suggest a change be made to the kernel such that it can print warnings when an unprotected binary or library is used, and also when an unprotected file is opened. By "unprotected" I mean one that is not schg, OR who's parent directories are not sufficiently protected to prevent stuff being moved around. At the start of the boot process enable the warnings and then disable them after securelevel is raised. If you get any of these theoretical warnings about a binary or library, fix it. If you get such warnings on an unprotected file, make sure you know what it's about. A reasonable flag for these warnings might be kern.securelevel==0 (as in, "It's not -1 because I really do want to raise the securelevel, but I'm vulnerable at the moment, so tell me if I do anything risky"). Unfortunately I don't know enough about the kernel to make such a change. BTW, what are these deficiencies people are talking about with securelevel? When properly configured it seems to me to be well suited to stopping an intruder from going invisible with trojaned ls, ps, syslogd, tripwire, etc. No more, no less. Or am I missing something? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 8:38:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id D6D9B14D74 for ; Sat, 18 Sep 1999 08:38:10 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id JAA23477; Sat, 18 Sep 1999 09:37:24 -0600 (MDT) Message-Id: <4.2.0.58.19990918093306.047917c0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 18 Sep 1999 09:33:54 -0600 To: "Rodney W. Grimes" , imp@village.org (Warner Losh) From: Brett Glass Subject: Real-time alarms Cc: wes@softweyr.com (Wes Peters), security@FreeBSD.ORG In-Reply-To: <199909180624.XAA50611@gndrsh.dnsmgr.net> References: <199909180612.AAA00597@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:24 PM 9/17/99 -0700, Rodney W. Grimes wrote: > Real time alarms if someone even _tries_ >to modify a schg file is what is missing... someone turning off >schg on a file is another thing missing... or accessing the disk >through the raw device to reset the bit, etc, etc... I like this idea a LOT. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 8:38:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 18D3A14FEA for ; Sat, 18 Sep 1999 08:38:15 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id JAA23480; Sat, 18 Sep 1999 09:37:28 -0600 (MDT) Message-Id: <4.2.0.58.19990918093413.047ff570@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 18 Sep 1999 09:37:13 -0600 To: "Jordan K. Hubbard" , "Rodney W. Grimes" From: Brett Glass Subject: Re: BPF on in 3.3-RC GENERIC kernel Cc: imp@village.org (Warner Losh), wes@softweyr.com (Wes Peters), security@FreeBSD.ORG In-Reply-To: <2091.937636119@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org DEC's /dev/audit was the way they got Orange Book Class C certification, IIRC. As I understand it, though, it produced so many logs that you needed a separate gigabyte volume to hold them all on an active system! It would be worthwhile to look into a version of this, and also Sun's stuff (which was also used to get Class C). If FreeBSD could get Class C certification, it would open up an amazing number of doors. --Brett At 11:28 PM 9/17/99 -0700, Jordan K. Hubbard wrote: >I'm surprised nobody has brought up /dev/audit and the whole Digital >Unix approach to security (OS-level event monitoring and active >counter-measures). It's not like there aren't a number of existing >examples to choose from when debating a "better course" of action. > >- Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 8:51: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from sonet.crimea.ua (OTC-sl3-FLY.CRIS.NET [212.110.136.71]) by hub.freebsd.org (Postfix) with ESMTP id 5AF9C14FB7 for ; Sat, 18 Sep 1999 08:50:57 -0700 (PDT) (envelope-from phantom@scorpion.crimea.ua) Received: (from uucp@localhost) by sonet.crimea.ua (8.8.8/8.8.8) with UUCP id SAA23137; Sat, 18 Sep 1999 18:46:15 +0400 (MSD) (envelope-from phantom@scorpion.crimea.ua) Received: (from phantom@localhost) by scorpion.crimea.ua (8.8.8/8.8.5+ssl+keepalive) id SAA25060; Sat, 18 Sep 1999 18:03:11 +0400 (MSD) Date: Sat, 18 Sep 1999 18:03:11 +0400 From: Alexey Zelkin To: Brett Glass Cc: David Scheidt , Greg Lewis , Evren Yurtesen , freebsd-security@FreeBSD.ORG Subject: Re: Securing a system that's been rooted remotely Message-ID: <19990918180311.B24671@scorpion.crimea.ua> References: <4.2.0.58.19990917092237.044f3f00@localhost> <4.2.0.58.19990917201149.046f2420@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: <4.2.0.58.19990917201149.046f2420@localhost> X-Operating-System: FreeBSD 2.2.7-RELEASE i386 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi, > > > By the way, why is it that "apropos securelevel" turns up nothing? > > > Considering that it's documented in a non-intuitive place (the > > > man page for init(8)), it ouught to be searchable. > >I doubt anyone will object to your writing a man page for the > >kern.securelevel sysctl, and submitting it as a PR. It's much simple to write additional section for securelevel in security.7, add reference to init.8 and do: MLINKS+= security.7 securelevel.7 -- /* Alexey Zelkin && phantom@cris.net */ /* Tavric National University && phantom@crimea.edu */ /* http://www.ccssu.crimea.ua/~phantom && phantom@FreeBSD.org */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 10: 5:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from funbox.demon.co.uk (funbox.demon.co.uk [158.152.85.52]) by hub.freebsd.org (Postfix) with SMTP id 4108914D07 for ; Sat, 18 Sep 1999 10:05:34 -0700 (PDT) (envelope-from dev.null@funbox.demon.co.uk) Received: from funbox.demon.co.uk, ID 37E3645D-19E2, Sat, 18 Sep 1999 10:07:25 UTC To: freebsd-security@freebsd.org From: dev.null@funbox.demon.co.uk (do not use this address) X-Date: Sat, 18 Sep 1999 11:07:24 +0100 Subject: Re: Securing a system that's been rooted remotely Message-ID: <37E3645D.19E2@funbox.demon.co.uk> Date: Sat, 18 Sep 1999 11:07:25 +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters was observed to have written: > What we really need is a good index to the man pages. glimpse works well for me... -- Tim Jackson ------------------------------------------------------------------------ please reply to: t i m . j @ f u n b o x . d e m o n . c o . u k ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 10:28:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id A3E8114DEE for ; Sat, 18 Sep 1999 10:28:20 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id TAA12087; Sat, 18 Sep 1999 19:26:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Rodney W. Grimes" Cc: imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Fri, 17 Sep 1999 14:58:22 PDT." <199909172158.OAA49373@gndrsh.dnsmgr.net> Date: Sat, 18 Sep 1999 19:26:20 +0200 Message-ID: <12085.937675580@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909172158.OAA49373@gndrsh.dnsmgr.net>, "Rodney W. Grimes" writes : >> In message <199909172048.OAA05040@harmony.village.org>, Warner Losh writes: >> >In message <5082.937599515@critter.freebsd.dk> Poul-Henning Kamp writes: >> >: There is a new kid in town if it comes to fortifying your FreeBSD >> >: box: jail(2|8) >> > >> >Is jail(2) in 3.3R? Or just -current? I ask because I had to have >> >different suser tests depending on 3.x and 4.0 in the chflags security >> >patches. >> >> Only current. I have no MFC plans. >> Although it could be trivially done I don't think there currently is >> a market demand for doing so, and I don't have the time anyway... > >I've been waiting for this to MFC so that we could use it through out >our AS. I can't run -current on production servers, I would start >building jails within days of this being MFC'ed. > >There.. some ``market demand''. Yeah, well, that was only half the problem... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 10:54: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 166F71500C for ; Sat, 18 Sep 1999 10:54:01 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA52921; Sat, 18 Sep 1999 10:53:27 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909181753.KAA52921@gndrsh.dnsmgr.net> Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <12085.937675580@critter.freebsd.dk> from Poul-Henning Kamp at "Sep 18, 1999 07:26:20 pm" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Sat, 18 Sep 1999 10:53:27 -0700 (PDT) Cc: imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In message <199909172158.OAA49373@gndrsh.dnsmgr.net>, "Rodney W. Grimes" writes > : > >> In message <199909172048.OAA05040@harmony.village.org>, Warner Losh writes: > >> >In message <5082.937599515@critter.freebsd.dk> Poul-Henning Kamp writes: > >> >: There is a new kid in town if it comes to fortifying your FreeBSD > >> >: box: jail(2|8) > >> > > >> >Is jail(2) in 3.3R? Or just -current? I ask because I had to have > >> >different suser tests depending on 3.x and 4.0 in the chflags security > >> >patches. > >> > >> Only current. I have no MFC plans. > >> Although it could be trivially done I don't think there currently is > >> a market demand for doing so, and I don't have the time anyway... > > > >I've been waiting for this to MFC so that we could use it through out > >our AS. I can't run -current on production servers, I would start > >building jails within days of this being MFC'ed. > > > >There.. some ``market demand''. > > Yeah, well, that was only half the problem... Okay, it sounds like the code is ready to MFC, if I do the work and send you a set of patches will you at least eyeball them for sanity? -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 11: 1:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id C5B131550F for ; Sat, 18 Sep 1999 11:01:27 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from spawn.nectar.com (localhost [127.0.0.1]) by gw.nectar.com (Postfix) with ESMTP id 6B9CBBD01; Sat, 18 Sep 1999 13:02:52 -0500 (CDT) X-Mailer: exmh version 2.0.2 2/24/98 X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-rsa.txt X-PGP-DSSfprint: AB2F 8D71 A4F4 467D 352E 8A41 5D79 22E4 71A2 8C73 X-PGP-DHfprint: 2D50 12E5 AB38 60BA AF4B 0778 7242 4460 1C32 F6B1 X-PGP-DH-DSSkey: http://www.nectar.com/nectar-dh-dss.txt From: Jacques Vidrine To: Poul-Henning Kamp Cc: Warner Losh , Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG In-reply-to: <5190.937601548@critter.freebsd.dk> References: <5190.937601548@critter.freebsd.dk> Subject: Re: BPF on in 3.3-RC GENERIC kernel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Sep 1999 13:02:52 -0500 Message-Id: <19990918180252.6B9CBBD01@gw.nectar.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 17 September 1999 at 22:52, Poul-Henning Kamp wrote: > Only current. I have no MFC plans. > Although it could be trivially done I don't think there currently is > a market demand for doing so, and I don't have the time anyway... Earlier in the year (May .. gosh how time flies) I backported the jail code to 3.2. Details are at http://www.nectar.com/freebsd/jail.html. I dropped it because my customer lost its funding for awhile, although I've intended to pick it up again. There has just been no urgent reason to do so. I had intended to eventually ask Poul-Henning if we could commit these to 3.x, but since I haven't sufficiently tested them, I haven't bothered. If there are a couple of folks who actually /need/ this functionality in 3.x, drop me a line and I'll continue the work. Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 11: 4: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 72BE615058 for ; Sat, 18 Sep 1999 11:04:05 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id UAA12312; Sat, 18 Sep 1999 20:00:22 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Rodney W. Grimes" Cc: imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Sat, 18 Sep 1999 10:53:27 PDT." <199909181753.KAA52921@gndrsh.dnsmgr.net> Date: Sat, 18 Sep 1999 20:00:22 +0200 Message-ID: <12310.937677622@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909181753.KAA52921@gndrsh.dnsmgr.net>, "Rodney W. Grimes" writes : >> >There.. some ``market demand''. >> >> Yeah, well, that was only half the problem... > >Okay, it sounds like the code is ready to MFC, if I do the work and >send you a set of patches will you at least eyeball them for sanity? Sure. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 11:20:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id B3C5F14D39 for ; Sat, 18 Sep 1999 11:20:34 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id LAA28902; Sat, 18 Sep 1999 11:19:09 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA66207; Sat, 18 Sep 1999 11:19:09 -0700 (PDT) (envelope-from dillon) Date: Sat, 18 Sep 1999 11:19:09 -0700 (PDT) From: Matthew Dillon Message-Id: <199909181819.LAA66207@apollo.backplane.com> To: Poul-Henning Kamp Cc: "Rodney W. Grimes" , imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <12085.937675580@critter.freebsd.dk> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In regards to the jail call, I still strongly recommend that the syscall be changed to take a sockaddr before it becomes too late, or we will blow compatibility with IPV6 coming up in the near future. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 11:35:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 8893E14D46 for ; Sat, 18 Sep 1999 11:35:25 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id UAA12436; Sat, 18 Sep 1999 20:32:54 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: "Rodney W. Grimes" , imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Sat, 18 Sep 1999 11:19:09 PDT." <199909181819.LAA66207@apollo.backplane.com> Date: Sat, 18 Sep 1999 20:32:53 +0200 Message-ID: <12434.937679573@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909181819.LAA66207@apollo.backplane.com>, Matthew Dillon writes: > In regards to the jail call, I still strongly recommend that the syscall > be changed to take a sockaddr before it becomes too late, or we will blow > compatibility with IPV6 coming up in the near future. > > -Matt Until we know more about how IPv6 multihoming will work it is too early to say what kind of argument we will need to pass to jail(2) for IPv6. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 11:40:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id DDB2E14D46 for ; Sat, 18 Sep 1999 11:40:14 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id LAA00892; Sat, 18 Sep 1999 11:39:18 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA66478; Sat, 18 Sep 1999 11:39:13 -0700 (PDT) (envelope-from dillon) Date: Sat, 18 Sep 1999 11:39:13 -0700 (PDT) From: Matthew Dillon Message-Id: <199909181839.LAA66478@apollo.backplane.com> To: Poul-Henning Kamp Cc: "Rodney W. Grimes" , imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <12434.937679573@critter.freebsd.dk> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :In message <199909181819.LAA66207@apollo.backplane.com>, Matthew Dillon writes: :> In regards to the jail call, I still strongly recommend that the syscall :> be changed to take a sockaddr before it becomes too late, or we will blow :> compatibility with IPV6 coming up in the near future. :> :> -Matt : :Until we know more about how IPv6 multihoming will work it is too :early to say what kind of argument we will need to pass to jail(2) :for IPv6. : :-- :Poul-Henning Kamp FreeBSD coreteam member Let me put it this way: Passing an unsigned 32 bit integer is obviously the *WRONG* type of argument to pass for an IP address considering that just about every single other system call takes a sockaddr of one sort or another. And, frankly, it is not too early. There's nothing wrong with a sockaddr. It's a typed data structure so compatibility will be maintained no matter what happens with IPV6. There is even already an IPV6 family defined for it. Now is the time. If you throw it into -STABLE without this, then you will screw over the people who are trying to use it when you eventually have to make the change, creating totally unnecessary pain in the process. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 11:58:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 480CA14CFE for ; Sat, 18 Sep 1999 11:58:14 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id UAA12518; Sat, 18 Sep 1999 20:55:52 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: "Rodney W. Grimes" , imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Sat, 18 Sep 1999 11:39:13 PDT." <199909181839.LAA66478@apollo.backplane.com> Date: Sat, 18 Sep 1999 20:55:52 +0200 Message-ID: <12516.937680952@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909181839.LAA66478@apollo.backplane.com>, Matthew Dillon writes: > Let me put it this way: Passing an unsigned 32 bit integer is obviously > the *WRONG* type of argument to pass for an IP address considering that > just about every single other system call takes a sockaddr of one sort > or another. Jail(2) as it stands today is an IPv4 facility, and only that. The interface is specified to make sure people don't miss this important fact. I have not yet been able to find sufficient information on how multihoming and resource location will work in IPv6 to determine if jail(2) will even be possible for IPv6. If you are able to design a protocol independent jail(2) facility I really think you should do so. For starters you can make it work for the appletalk and ipx stacks we have in the kernel. Remember: jail(2) is a security function, not a networking function. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 16:24:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (law-f198.hotmail.com [209.185.130.108]) by hub.freebsd.org (Postfix) with SMTP id 7805814CE7 for ; Sat, 18 Sep 1999 16:24:42 -0700 (PDT) (envelope-from skalir@hotmail.com) Received: (qmail 818 invoked by uid 0); 18 Sep 1999 23:24:42 -0000 Message-ID: <19990918232442.817.qmail@hotmail.com> Received: from 166.62.215.159 by www.hotmail.com with HTTP; Sat, 18 Sep 1999 16:24:42 PDT X-Originating-IP: [166.62.215.159] From: "skalir scalar" To: freebsd-security@freebsd.org Subject: ipfw and rule bases forwarding Date: Sat, 18 Sep 1999 15:24:42 AKDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am running 3.1-release (will be 3.2-stable/3.3-release soon) anyways, I have my firewall all setup and would like to use the 'fwd' feature in ipfw, but when i boot up, i get "rule based forwarding disabled", how can i enable this? thanks ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 18:15:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 2260014E8C for ; Sat, 18 Sep 1999 18:15:48 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SVZy-0006Bg-00; Sat, 18 Sep 1999 19:15:46 -0600 Message-ID: <37E43940.175437CB@softweyr.com> Date: Sat, 18 Sep 1999 19:15:44 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Rodney W. Grimes" Cc: Warner Losh , Brett Glass , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <199909180711.AAA50768@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rodney W. Grimes" wrote: > > > Warner Losh wrote: > > > > > > In message <37E32365.B9F9573B@softweyr.com> Wes Peters writes: > > > : Worked for me. A well-written, accurate analogy too. > > > > > > I'll have to try again later... I'd be very interested in this. I > > > personally think that schg is useful against accidental mistakes, but > > > flawed in implementation. > > > > Agreed. It's a good tool, but isn't going to stop somebody who's both > > clever and dedicated. A similar facility in VMS didn't stop Kevin > > Mittnick from stealing the VMS source code from my ex-boss. ;^) > > But SYS$AUDIT would have at least let him know it was stolen :-). And > perhaps alerted him before Kevin got out the door with the tape. It did, and he got it over a dial-up line, after making an end-run around one of the company's security tools that was poorly installed. Duh. > > > Although some of that may be due to inperfections in /etc/rc and > > > friends. > > > > I think a lot of the system startup just happened, rather than being > > designed from a security standpoint. I'm attempting to land myself a > > job where I would be paid to fix this, among other things. I'll let > > you all know if/when it happens. > > 99% of most OS's ``just happen'' without concern for secuirity. And > good luck on that new work load your digging yourself in for!! Yes, security usually happens as an afterthought. Even VMS, which did have good security mechanisms, was delivered out of the box with several stupidities, and most installations added several more. At least we're smart enough to make the user pick a root password on installation. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 18:18:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id BD41614E8C for ; Sat, 18 Sep 1999 18:18:33 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SVcd-0006RZ-00; Sat, 18 Sep 1999 19:18:32 -0600 Message-ID: <37E439E6.8A6AAAE7@softweyr.com> Date: Sat, 18 Sep 1999 19:18:30 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Jordan K. Hubbard" Cc: Warner Losh , "Rodney W. Grimes" , Brett Glass , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <2282.937639734@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Jordan K. Hubbard" wrote: > > > A well-defined and well-architected syscall auditing mechanism would be a > > great security addition, and right up the alley of what I'm looking for. > > Well, that much I thought Robert Watson had > already done... See his postings in -current on the topic or go to > http://www.watson.org/fbsd-hardening/posix1e/ Nothing I've read so far dissuades me from thinking it will be quite good when done. Thanks for the URL, I'll study it. I'll be meeting with "the new guys" at FreeBSDCon, attempting to wheedle my way into the new job, and this will probably help a lot. Who knows, maybe I'll get a change to help implement it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 18:28:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id BAC931510D for ; Sat, 18 Sep 1999 18:28:20 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SVm2-0007ZL-00; Sat, 18 Sep 1999 19:28:15 -0600 Message-ID: <37E43C2C.69F167F9@softweyr.com> Date: Sat, 18 Sep 1999 19:28:12 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve Cc: Warner Losh , Brett Glass , Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <4.2.0.58.19990917160519.047cc890@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <4.2.0.58.19990917160519.047cc890@localhost> <199909172208.QAA05554@harmony.village.org> <19990918012538.A1195@grok.localnet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Steve wrote: > > I think the boot scripts should be redesigned to do only what is really > necessary pre-securelevel, raise the securelevel ASAP, then pass control > to post-securelevel scripts. Keep the chflags requirements to a > minimum. I sort of plan to do this for my own systems. There are some other holes in startup, too. I'm not sure how much we should discuss in such a public forum, some of them might be better to air as a fait accompli, and some are peculiar to the application I'm looking at. > Really, I have slightly more grandiose plans, mainly allowing remote > sysadmin (that's me) to upload scripts and have them run > pre-securelevel: stick them in a directory, reboot, and have the boot > process run them after verifying PGP signatures (and sequence numbers to > prevent replay attacks). For those times when you just _have_ to fix a > vulnerability involving a schg file but can't get to the console for a > while. This of course conflicts somewhat with my previous paragraph. That's an interesting idea. I think it would be important to disallow such scripts from adding to the signatures, though. > I would be happy to share such a boot process if/when I actually get > around to doing it. I don't think it would be very difficult. That would be great. > As for automating the lock-down procedure, I would suggest a change be > made to the kernel such that it can print warnings when an unprotected > binary or library is used, and also when an unprotected file is opened. > By "unprotected" I mean one that is not schg, OR who's parent > directories are not sufficiently protected to prevent stuff being moved > around. At the start of the boot process enable the warnings and then > disable them after securelevel is raised. If you get any of these > theoretical warnings about a binary or library, fix it. If you get such > warnings on an unprotected file, make sure you know what it's about. A > reasonable flag for these warnings might be kern.securelevel==0 (as in, > "It's not -1 because I really do want to raise the securelevel, but I'm > vulnerable at the moment, so tell me if I do anything risky"). > > Unfortunately I don't know enough about the kernel to make such a > change. An interesting idea. One of the military systems I worked on long ago had a background thread that would continually checksum program memory and fault the processor if it got a checksum mismatch. Each of the binary images were padded with checksum bytes to make the checksum match, and the "unload" routine would restore the "transient program area" to a known pattern. I've often thought it would be a good idea to at least checksum executable files, or perhaps even sign them, and modify the loader so it will refuse to execute any executable (shared library, etc) not properly checksummed or signed. An interesting extension to the signing mechanism would be to require a local as well as vendor signature, so root would have to sign an executable before it can be run on THAT system. This would obviously require multiple local signatures for executables loaded from NFS servers. Does this idea show merit for high-security installations? > BTW, what are these deficiencies people are talking about with > securelevel? When properly configured it seems to me to be well suited > to stopping an intruder from going invisible with trojaned ls, ps, > syslogd, tripwire, etc. No more, no less. Or am I missing something? It's not always available (i.e. early in booting) and it doesn't tell you about denied attempts. The lack of logging is the biggest failure from the standpoint of a security manager. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 19: 4:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 903C714DD1 for ; Sat, 18 Sep 1999 19:04:14 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SWKr-000431-00; Sat, 18 Sep 1999 20:04:13 -0600 Message-ID: <37E4449B.ADDD68EE@softweyr.com> Date: Sat, 18 Sep 1999 20:04:11 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brett Glass Cc: "Rodney W. Grimes" , Warner Losh , security@FreeBSD.ORG Subject: Re: Real-time alarms References: <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > At 11:24 PM 9/17/99 -0700, Rodney W. Grimes wrote: > > > Real time alarms if someone even _tries_ > >to modify a schg file is what is missing... someone turning off > >schg on a file is another thing missing... or accessing the disk > >through the raw device to reset the bit, etc, etc... > > I like this idea a LOT. This is what we're talking about with the auditing facility. There are a lot of architectural issues to be solved, starting with "what is an alarm" and ending with "how do I securely transmit the alarms to those who need to know about them"? Fun stuff, eh? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 19:13: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 7277A14DD1 for ; Sat, 18 Sep 1999 19:13:00 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SWTK-0004iV-00; Sat, 18 Sep 1999 20:12:59 -0600 Message-ID: <37E446A9.41C4791B@softweyr.com> Date: Sat, 18 Sep 1999 20:12:57 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Rodney W. Grimes" Cc: freebsd-security@FreeBSD.ORG Subject: Re: Securing a system that's been rooted remotely References: <199909180724.AAA50876@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rodney W. Grimes" wrote: > > Wes Peters opined: > > > > What we really need is a good index to the man pages. > > Yea, what ever happend to ptx(1): > gndrsh:root {1206}# man ptx > No manual entry for ptx > gndrsh:root {1207}# which ptx > /usr/bin/ptx > gndrsh:root {1208}# > > Hummm.. part of groff... probably info file documents, yep there it is. > What would it take to get this thing building the Permuted Index again? > > cd /usr/share/man/man7; zcat *.gz | nroff -mandoc | col -b | ptx | more > makes for some interesting reading :-). man -k . | ptx produces some interesting reading, too. 84 MBytes of it on 3.1-R. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 19:15:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 66C2814CAE for ; Sat, 18 Sep 1999 19:15:47 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA27985; Sat, 18 Sep 1999 20:15:26 -0600 (MDT) Message-Id: <4.2.0.58.19990918201409.047f9f00@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 18 Sep 1999 20:15:17 -0600 To: Wes Peters From: Brett Glass Subject: Re: Real-time alarms Cc: "Rodney W. Grimes" , Warner Losh , security@FreeBSD.ORG In-Reply-To: <37E4449B.ADDD68EE@softweyr.com> References: <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:04 PM 9/18/99 -0600, Wes Peters wrote: >This is what we're talking about with the auditing facility. There are >a lot of architectural issues to be solved, starting with "what is an >alarm" and ending with "how do I securely transmit the alarms to those >who need to know about them"? > >Fun stuff, eh? Indeed. Fortunately, many of the tools are already available. E-mail comes to mind as the simplest solution to the above, though certainly not the only one. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 19:40:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id 25BF814C4C for ; Sat, 18 Sep 1999 19:40:03 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from spawn.nectar.com (localhost [127.0.0.1]) by gw.nectar.com (Postfix) with ESMTP id 817FCBD05; Sat, 18 Sep 1999 21:41:25 -0500 (CDT) X-Mailer: exmh version 2.0.2 2/24/98 X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-rsa.txt X-PGP-DSSfprint: AB2F 8D71 A4F4 467D 352E 8A41 5D79 22E4 71A2 8C73 X-PGP-DHfprint: 2D50 12E5 AB38 60BA AF4B 0778 7242 4460 1C32 F6B1 X-PGP-DH-DSSkey: http://www.nectar.com/nectar-dh-dss.txt From: Jacques Vidrine To: Wes Peters Cc: security@FreeBSD.ORG In-reply-to: <37E4449B.ADDD68EE@softweyr.com> References: <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <37E4449B.ADDD68EE@softweyr.com> Subject: Re: Real-time alarms Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Sep 1999 21:41:25 -0500 Message-Id: <19990919024125.817FCBD05@gw.nectar.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Here's a not-completely-thought-out idea. When looking at PHK's changes to suser for the jail code, I realized that he had essentially created two categories of suser calls in the kernel. One category of calls are allowed if you are NOT in a jail, and the other are allowed regardless of whether you are in a jail. I wanted to extend this so that each call to suser passes a category, kind of like we do with calls to malloc. I wanted to do this for two reasons: 1) finer granularity of control on what superuser priviledges a jailed process can use (specified at jail creation time) 2) auditing what superuser priviledges a process has used or tried to use e.g. SUSER_SIGNAL sent signals to process we don't own SUSER_RESOURCE changed our resource settings SUSER_KLD did something with a KLD SUSER_REBOOT rebooted the system SUSER_JAIL made a new jail etc. These categories could be as broad or specific as needed, although one per system call is probably too many :-) So if I'm running some server application that needs lots of root priviledges, I don't have to give away the farm.[1] Thoughts? Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org [1] for those who haven't looked at the jail code: it doesn't give away the farm, either. but the priviledges that can be used by a jailed process are ``hard wired'' and can't be customized. On 18 September 1999 at 20:04, Wes Peters wrote: > This is what we're talking about with the auditing facility. There are > a lot of architectural issues to be solved, starting with "what is an > alarm" and ending with "how do I securely transmit the alarms to those > who need to know about them"? > > Fun stuff, eh? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 19:42:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 5E36014FF4 for ; Sat, 18 Sep 1999 19:42:08 -0700 (PDT) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.8.8) id WAA07350; Sat, 18 Sep 1999 22:44:54 -0400 (EDT) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199909190244.WAA07350@cc942873-a.ewndsr1.nj.home.com> Subject: Re: ipfw and rule bases forwarding In-Reply-To: <19990918232442.817.qmail@hotmail.com> from skalir scalar at "Sep 18, 1999 03:24:42 pm" To: skalir@hotmail.com (skalir scalar) Date: Sat, 18 Sep 1999 22:44:53 -0400 (EDT) Cc: freebsd-security@FreeBSD.ORG Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org skalir scalar wrote, > I am running 3.1-release (will be 3.2-stable/3.3-release soon) > > anyways, I have my firewall all setup and would like to use the 'fwd' > feature in ipfw, but when i boot up, i get "rule based forwarding > disabled", how can i enable this? % man 8 ipfw . . . fwd ipaddr [,port] Change the next-hop on matching packets to ipaddr, which can be an IP address in dotted quad or a host ... The kernel must have been compiled with options IP- FIREWALL_FORWARD. . . . -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 21: 7:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AC3121525E for ; Sat, 18 Sep 1999 21:07:34 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id AAA03057; Sun, 19 Sep 1999 00:07:21 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Sun, 19 Sep 1999 00:07:21 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Jacques Vidrine Cc: Wes Peters , security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <19990919024125.817FCBD05@gw.nectar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org One thing one does have to be a little careful about is creating fine-grained access controls with capabilities that are effectively equivilent. For example, allowing direct disk writes is almost always equivilent to allowing direct access to kernel memory, etc. Creating distinct security capabilities can leave the policy creator with false impressinos about the policy they have created. For example, in the Java 1.2 security model, there are a number of effectively equivilent permissions--any permission allowing modification to the security environment is essentially the same--be it the right to make native calls, to modify the class loading behavior, etc. In UNIX, one could see the same effect by creating a capability allowing the binding of privileged ports in arbitrary ways--suddenly previously "secure" environments (NFS, for example) allow the ability to leverage root access. In the case of network examples, there is a strong argument that that is just poor NFS design, but it's something to keep in mind. Similarly, in the POSIX.1e capabilities the ability to send signals to arbitrary processes is often similar to the ability to write to arbitrary files, or read from arbitrary files--they can allow you to subvert security mechanisms. W.r.t. real time alarms--part of my hope for the POSIX.1e auditing code was to provide a general facility for event management and a detection environment so that we don't end up with lots of parallel mechanisms, and also so that we have portable security solutions letting us make use of products for other platforms (linux, et al). Any security sensitive events should certainly be among those audited. On Sat, 18 Sep 1999, Jacques Vidrine wrote: > Here's a not-completely-thought-out idea. When looking at PHK's > changes to suser for the jail code, I realized that he had essentially > created two categories of suser calls in the kernel. One category of > calls are allowed if you are NOT in a jail, and the other are allowed > regardless of whether you are in a jail. > > I wanted to extend this so that each call to suser passes a category, > kind of like we do with calls to malloc. I wanted to do this for > two reasons: > > 1) finer granularity of control on what superuser priviledges a > jailed process can use (specified at jail creation time) > 2) auditing what superuser priviledges a process has used > or tried to use > > e.g. SUSER_SIGNAL sent signals to process we don't own > SUSER_RESOURCE changed our resource settings > SUSER_KLD did something with a KLD > SUSER_REBOOT rebooted the system > SUSER_JAIL made a new jail > > etc. > > These categories could be as broad or specific as needed, although > one per system call is probably too many :-) > > So if I'm running some server application that needs lots of > root priviledges, I don't have to give away the farm.[1] > > Thoughts? > > Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org > > [1] for those who haven't looked at the jail code: it doesn't > give away the farm, either. but the priviledges that can > be used by a jailed process are ``hard wired'' and can't > be customized. > > On 18 September 1999 at 20:04, Wes Peters wrote: > > This is what we're talking about with the auditing facility. There are > > a lot of architectural issues to be solved, starting with "what is an > > alarm" and ending with "how do I securely transmit the alarms to those > > who need to know about them"? > > > > Fun stuff, eh? > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 21:20:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 1FFB714F3E for ; Sat, 18 Sep 1999 21:20:12 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SYSQ-00056w-00; Sat, 18 Sep 1999 22:20:10 -0600 Message-ID: <37E46478.6326218E@softweyr.com> Date: Sat, 18 Sep 1999 22:20:08 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brett Glass Cc: "Rodney W. Grimes" , Warner Losh , security@FreeBSD.ORG Subject: Re: Real-time alarms References: <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <4.2.0.58.19990918201409.047f9f00@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > At 08:04 PM 9/18/99 -0600, Wes Peters wrote: > > >This is what we're talking about with the auditing facility. There are > >a lot of architectural issues to be solved, starting with "what is an > >alarm" and ending with "how do I securely transmit the alarms to those > >who need to know about them"? > > > >Fun stuff, eh? > > Indeed. Fortunately, many of the tools are already available. E-mail comes > to mind as the simplest solution to the above, though certainly not the > only one. Too clumsy, it pretty much has to be a stream-oriented protocol. Can you image trying to generate an email message for ever open(2) call that failed? OTOH, it probably has to be a multicast protocol, because you may want notifications to go to multiple targets. This was one of the major problems with SYS$AUDIT in VMS, all it did was append to the audit logs. Of course, many vendors, including my former employer, made a good living developing audit log watchers that could make some intelligent decisions about what was appearing in the logs and generate mail messages, page people, etc. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 21:31:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 07A5515049 for ; Sat, 18 Sep 1999 21:31:22 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id WAA28914; Sat, 18 Sep 1999 22:31:03 -0600 (MDT) Message-Id: <4.2.0.58.19990918222636.047a1880@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 18 Sep 1999 22:30:56 -0600 To: Wes Peters From: Brett Glass Subject: Re: Real-time alarms Cc: "Rodney W. Grimes" , Warner Losh , security@FreeBSD.ORG In-Reply-To: <37E46478.6326218E@softweyr.com> References: <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <4.2.0.58.19990918201409.047f9f00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:20 PM 9/18/99 -0600, Wes Peters wrote: >Too clumsy, it pretty much has to be a stream-oriented protocol. Or something like syslogd? >Can you >image trying to generate an email message for ever open(2) call that >failed? No, but how about a compilation? Or a warning saying, "Looky here, there's something going on; check the logs for details"? >OTOH, it probably has to be a multicast protocol, because you may want >notifications to go to multiple targets. This was one of the major problems >with SYS$AUDIT in VMS, all it did was append to the audit logs. Of course, >many vendors, including my former employer, made a good living developing >audit log watchers that could make some intelligent decisions about what >was appearing in the logs and generate mail messages, page people, etc. I think that some combination of local logging, remote logging, and mail notification would work. Again, these should be universal facilities. People have many complaints about syslogd -- in particular, that it can be a wonderful remote disk filler. Maybe fixing syslogd would go hand in hand with creating such a facility. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 22:30:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id 6E9A6150B2 for ; Sat, 18 Sep 1999 22:30:27 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id WAA09890; Sat, 18 Sep 1999 22:34:13 -0600 Date: Sat, 18 Sep 1999 22:34:13 -0600 (MDT) From: Jobe To: security@freebsd.org Cc: wes@softweyr.com Subject: Re: Real-time alarms Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There are lots of things to be worked out here. Seemings how we have to plan our security design to twart even the most skilled of hackers. Now, with this in mind we have to realize that a very skilled hacker will no doubt be able to write lkms to wrap arbitrary system calls and arbitrary kernel routines. At this point we realize that most of the current system calls are left extremely vulnerable, not only that but in order to provide sane security accounting we must also be sure that our logging/alert routines are untarnished by rogue code. I'd suggest possibly a sysctl variable that can be set only once after the system is rebooted that controls whether the alarms are to be sent locally or over the network, or both. Use IP Encapsulated UDP Broadcast/Multicast(Partially as Wes suggested) packets to transmit the alarms to the alert host(this is assuming that our evil friend hasn't disabled protocols he doesn't need to use). If we are strictly looking at a single host based alert system why not create a userland immutable device that can relay the events to a userland monitoring system, maybe set up a mod to the in kernel process signal processing disabling _ALL_ signals sent to the monitoring application's process id. Atleast this way the only way to mung the monitoring daemon would in effect be to actually corrupt the kernel's process table such that the scheduler wasn't giving any CPU time to the process. The design of the monitoring daemon is wide open, possibly just have it open an append only pipe to an immutable file, add an extra flag to fs options to allow the prevention of SYS_write() from overwriting previously written portions of files on this fs, mount a new fs with this option under say /alerts(similar to /proc only remove the ability of the fs to be umounted), and have the monitoring and place the file on the other end of the pipe here. This system is far from perfect, and whipped up rather spontaneously I might add, any questions/comments please feel free to mail me. --Jobe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 22:42:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id EF0C614F9A for ; Sat, 18 Sep 1999 22:42:10 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id WAA09975 for ; Sat, 18 Sep 1999 22:45:55 -0600 Date: Sat, 18 Sep 1999 22:45:55 -0600 (MDT) From: Jobe To: security@freebsd.org Subject: Re: Real-time alarms Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 18 Sep 1999, Brett Glass wrote: > At 10:20 PM 9/18/99 -0600, Wes Peters wrote: > > >Too clumsy, it pretty much has to be a stream-oriented protocol. > > Or something like syslogd? > > >Can you > >image trying to generate an email message for ever open(2) call that > >failed? > > No, but how about a compilation? Or a warning saying, "Looky here, > there's something going on; check the logs for details"? > > >OTOH, it probably has to be a multicast protocol, because you may want > >notifications to go to multiple targets. This was one of the major problems > >with SYS$AUDIT in VMS, all it did was append to the audit logs. Of course, > >many vendors, including my former employer, made a good living developing > >audit log watchers that could make some intelligent decisions about what > >was appearing in the logs and generate mail messages, page people, etc. > > I think that some combination of local logging, remote logging, and mail > notification would work. Again, these should be universal facilities. > People have many complaints about syslogd -- in particular, that it can > be a wonderful remote disk filler. Maybe fixing syslogd would go hand in > hand with creating such a facility. > > --Brett Bah, using any current software for alert relay/distribution is a _bad_ idea. When designing new security policies is it not customary to build the supporting applications from the ground up? Any compromise of security in your alert relay system completely defeats the purpose of having the alarms generated in the first place. Syslog was written to be multifunctional and dynamic, the application we need has a single, lone, extremely specific purpose. Taking this into account I feel that the only way to adequetlly attack this problem is, as mentioned above, to design and build the policy's supporting applications from the ground up. --Jobe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 22:53:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (Postfix) with ESMTP id 6F73314FE1 for ; Sat, 18 Sep 1999 22:53:27 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id WAA19056; Sat, 18 Sep 1999 22:51:15 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA68627; Sat, 18 Sep 1999 22:51:14 -0700 (PDT) (envelope-from dillon) Date: Sat, 18 Sep 1999 22:51:14 -0700 (PDT) From: Matthew Dillon Message-Id: <199909190551.WAA68627@apollo.backplane.com> To: Poul-Henning Kamp Cc: "Rodney W. Grimes" , imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <12516.937680952@critter.freebsd.dk> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :Jail(2) as it stands today is an IPv4 facility, and only that. : :The interface is specified to make sure people don't miss this :important fact. : :I have not yet been able to find sufficient information on how :multihoming and resource location will work in IPv6 to determine :if jail(2) will even be possible for IPv6. : :If you are able to design a protocol independent jail(2) facility :I really think you should do so. For starters you can make it :work for the appletalk and ipx stacks we have in the kernel. : :Remember: jail(2) is a security function, not a networking function. : :-- :Poul-Henning Kamp FreeBSD coreteam member It's got a network specification in the structure, therefore it has a networking component that needs to be addressed. You can't seriously believe that you can call it "not a networking function" when one of its major features is to create a jail around an IP address! It doesn't need to support appletalk or ipx stacks, but the system call should not be constructed such that supporting those and other protocols in the future will result in the system call becoming incompatible with binaries already compiled for it from prior releases. struct sockaddr is the standard for specifying an IP address. Jail isn't using it, not even for IPV4. It's using an unsigned 32 bit int. Hell, it isn't even using a struct in_addr! The field is plain and simply inappropriately specified in the structure. It is especially important that system calls be constructed with future binary compatibility issues in mind, especially if they become widely adopted. If jail is going to be backported to -STABLE and made more 'standard' in the system, then it needs to take this issue into account *now* so we don't go around breaking all the software that starts using it when we need to extend it. It's that simple. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 22:55:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (Postfix) with ESMTP id EE5BE14FE1 for ; Sat, 18 Sep 1999 22:55:30 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id WAA28654; Sat, 18 Sep 1999 22:55:02 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA68663; Sat, 18 Sep 1999 22:54:59 -0700 (PDT) (envelope-from dillon) Date: Sat, 18 Sep 1999 22:54:59 -0700 (PDT) From: Matthew Dillon Message-Id: <199909190554.WAA68663@apollo.backplane.com> To: Wes Peters Cc: Brett Glass , Greg Lewis , Evren Yurtesen , freebsd-security@FreeBSD.ORG Subject: Re: Securing a system that's been rooted remotely References: <37E21A0A.1075F204@ispro.net.tr> <4.2.0.58.19990917092237.044f3f00@localhost> <37E2C9B0.BD5846BB@softweyr.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Brett Glass wrote: :> :> By the way, why is it that "apropos securelevel" turns up nothing? :> Considering that it's documented in a non-intuitive place (the :> man page for init(8)), it ouught to be searchable. : :Because the NAME entry for init(8) doesn't mention "securelevel." I don't :see how you could write a meaningful entry and work securelevel into it. :Perhaps adding securelevel as an alternate name would help. : :What we really need is a good index to the man pages. : :-- : "Where am I, and what am I doing in this handbasket?" : :Wes Peters Softweyr LLC :http://softweyr.com/ wes@softweyr.com I did a quick look at 'makewhatis' but did not see any specific way to be able to embed keywords in a manual page outside the NAME section. Certainly the manual reference 'SEE ALSO' section can be used to link multiple manual pages together if someone actually decides to write a 'securelevel' manual page, but barring that we are pretty much S.O.L. unless someone makes an addition to the (GNU) 'makewhatis'. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 23:29:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id ECC6915045 for ; Sat, 18 Sep 1999 23:29:40 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id IAA14491; Sun, 19 Sep 1999 08:27:18 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: "Rodney W. Grimes" , imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Sat, 18 Sep 1999 22:51:14 PDT." <199909190551.WAA68627@apollo.backplane.com> Date: Sun, 19 Sep 1999 08:27:18 +0200 Message-ID: <14489.937722438@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909190551.WAA68627@apollo.backplane.com>, Matthew Dillon writes: > It is especially important that system calls be constructed with > future binary compatibility issues in mind, especially if they > become widely adopted. You have not proved or even shown that changing this particular element will be enough to guarantee that we can support other protocols in the future. The only thing that can be done to the jail(2) syscall to improve it in that respect is to add a version number as the first element, I would have no problem with that. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 23:36:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id 6F60214D2D for ; Sat, 18 Sep 1999 23:36:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id XAA28542; Sat, 18 Sep 1999 23:34:27 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA68995; Sat, 18 Sep 1999 23:34:26 -0700 (PDT) (envelope-from dillon) Date: Sat, 18 Sep 1999 23:34:26 -0700 (PDT) From: Matthew Dillon Message-Id: <199909190634.XAA68995@apollo.backplane.com> To: Poul-Henning Kamp Cc: "Rodney W. Grimes" , imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <14489.937722438@critter.freebsd.dk> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :You have not proved or even shown that changing this particular :element will be enough to guarantee that we can support other :protocols in the future. : :The only thing that can be done to the jail(2) syscall to improve :it in that respect is to add a version number as the first element, :I would have no problem with that. : :-- :Poul-Henning Kamp FreeBSD coreteam member Well, I see it quite differently. I believe I have given ample justification for asking that the system call be cleaned up before it is exposed to wider use. You're making a blanket comments saying "Matt hasn't proved..." and not even trying to address the issues brought up doesn't really pull any weight with me. Try addressing the issues that were brought up instead. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 18 23:55:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 4947B15223 for ; Sat, 18 Sep 1999 23:55:46 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id IAA14674; Sun, 19 Sep 1999 08:53:06 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: "Rodney W. Grimes" , imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Sat, 18 Sep 1999 23:34:26 PDT." <199909190634.XAA68995@apollo.backplane.com> Date: Sun, 19 Sep 1999 08:53:06 +0200 Message-ID: <14672.937723986@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Final email from here: Matt, you have not done anything to show that changing the ip_number field to a sockaddr will be enough to support IPv6 or any other protocol in the future. Remember that IPv4 is a very simple protocol, most others are not, in particular IPv6 it seems. I do not see a reason to change an interface which is already deployed, and which have been so for more than 1.5 years, "just in case it might be enough to support IPv6." I will therefore not make any changes to the jail(2) syscalls arguments until such time as we know what arguments will actually be needed for jail(2) under IPv6, or any other protocol for that matter. Poul-Henning In message <199909190634.XAA68995@apollo.backplane.com>, Matthew Dillon writes: > >:You have not proved or even shown that changing this particular >:element will be enough to guarantee that we can support other >:protocols in the future. >: >:The only thing that can be done to the jail(2) syscall to improve >:it in that respect is to add a version number as the first element, >:I would have no problem with that. >: >:-- >:Poul-Henning Kamp FreeBSD coreteam member > > Well, I see it quite differently. I believe I have given ample > justification for asking that the system call be cleaned up before it > is exposed to wider use. You're making a blanket comments saying > "Matt hasn't proved..." and not even trying to address the issues > brought up doesn't really pull any weight with me. Try addressing > the issues that were brought up instead. > > -Matt > Matthew Dillon > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message