From owner-freebsd-security Tue Apr 14 09:02:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA08478 for freebsd-security-outgoing; Tue, 14 Apr 1998 09:02:52 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08470 for ; Tue, 14 Apr 1998 16:02:41 GMT (envelope-from tweten@ns.frihet.com) Received: from ns.frihet.com (tweten@localhost.frihet.com [127.0.0.1]) by ns.frihet.com (8.8.8/8.8.8) with ESMTP id JAA18069 for ; Tue, 14 Apr 1998 09:02:40 -0700 (PDT) (envelope-from tweten@ns.frihet.com) Message-Id: <199804141602.JAA18069@ns.frihet.com> X-Mailer: exmh version 2.0.2 2/24/98 Reply-to: tweten@frihet.com To: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD-SA-98:02.mmap From: "David E. Tweten" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Apr 1998 09:02:39 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk It's been ten days, now, since security advisory FreeBSD-SA-98:02.mmap was sent, ten days since the signature on it failed to check using my copies of exmh and pgp, and ten days since I sent a report of that fact to Stefan Powell. Since then, silence. Nobody else seems to have mentioned any signature failure, and Powell has also been silent. Is it just me? Should I start debugging my copies of exmh and MIT pgp (as opposed to the crippled pgp in ports)? -- David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 14 09:14:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA10248 for freebsd-security-outgoing; Tue, 14 Apr 1998 09:14:08 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10197 for ; Tue, 14 Apr 1998 16:13:58 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id JAA08920; Tue, 14 Apr 1998 09:14:09 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: tweten@frihet.com cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD-SA-98:02.mmap In-reply-to: Your message of "Tue, 14 Apr 1998 09:02:39 PDT." <199804141602.JAA18069@ns.frihet.com> Date: Tue, 14 Apr 1998 09:14:09 -0700 Message-ID: <8917.892570449@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Huh? That was already acknowledged to be a mistaken repost and we moved on. Just ignore it. > It's been ten days, now, since security advisory FreeBSD-SA-98:02.mmap was > sent, ten days since the signature on it failed to check using my copies of > exmh and pgp, and ten days since I sent a report of that fact to Stefan > Powell. Since then, silence. Nobody else seems to have mentioned any > signature failure, and Powell has also been silent. > > Is it just me? Should I start debugging my copies of exmh and MIT pgp (as > opposed to the crippled pgp in ports)? > -- > David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com > 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com > Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 > Those who make good products sell products; those who don't, sell solutions. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 14 10:26:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22061 for freebsd-security-outgoing; Tue, 14 Apr 1998 10:26:19 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from uground.org (condor.sysnetway.com.br [200.245.237.41]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA22052 for ; Tue, 14 Apr 1998 17:26:10 GMT (envelope-from condor@uground.org) From: condor@uground.org Received: from localhost (condor@localhost) by uground.org (8.9.0.Beta5/8.8.7) with SMTP id OAA20930 for ; Tue, 14 Apr 1998 14:24:02 -0300 Date: Tue, 14 Apr 1998 14:24:02 -0300 (EST) To: freebsd-security@FreeBSD.ORG Subject: subscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk subscribe condor@uground.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 14 11:26:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03609 for freebsd-security-outgoing; Tue, 14 Apr 1998 11:26:14 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03603 for ; Tue, 14 Apr 1998 18:26:08 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id LAA19469; (8.8.8/RDY) Tue, 14 Apr 1998 11:26:08 -0700 (PDT) Message-Id: <199804141826.LAA19469@burka.rdy.com> Subject: kernel permissions To: freebsd-security@FreeBSD.ORG Date: Tue, 14 Apr 1998 11:26:07 -0700 (PDT) X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Is there a particular reason of kernel being installed with 555 root/wheel permissions instead of 550 root/kmem ? If nobody has nothing against it - I'll commit the change. -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 14 12:28:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA23308 for freebsd-security-outgoing; Tue, 14 Apr 1998 12:28:05 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from jli.com (jli.com [199.2.111.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA23251 for ; Tue, 14 Apr 1998 19:27:53 GMT (envelope-from trost@cloud.rain.com) Received: (qmail 28283 invoked by uid 4); 14 Apr 1998 19:27:10 -0000 Received: (qmail 12285 invoked from network); 14 Apr 1998 17:54:29 -0000 Received: from localhost.cloud.rain.com (127.0.0.1) by localhost.cloud.rain.com with SMTP; 14 Apr 1998 17:54:29 -0000 To: freebsd-security@FreeBSD.ORG Subject: Re: Is there a safe way for filesystem export? References: <199804030813.DAA05256@adk.gr> In-reply-to: Your message of Fri, 03 Apr 1998 03:14:26 EST. <199804030813.DAA05256@adk.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12281.892576468.1@cloud.rain.com> Date: Tue, 14 Apr 1998 10:54:28 -0700 Message-ID: <12282.892576468@cloud.rain.com> From: Bill Trost Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk "Angelos D. Keromytis" writes: One way for doing secure (against external attackers, anyway) is to use IPsec. There is/was an IPsec implementation from WIDE for FreeBSD, and my code from OpenBSD should be trivial to port. In fact, we might make a port to FreeBSD during the summer (unfortunately, that would be available only to US citizens). There is also a port of the NRL IPSEC implementation available (to US citizens...sigh) as part of the Portland State University's Mobile IP via http://www.cs.pdx.edu/research/SMN/. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 14 13:04:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA02574 for freebsd-security-outgoing; Tue, 14 Apr 1998 13:04:15 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mb05.swip.net (mb05.swip.net [193.12.122.209]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA02507 for ; Tue, 14 Apr 1998 20:04:00 GMT (envelope-from bjarni.ingolfsson@swipnet.se) Received: from belze (dialup108-8-5.swipnet.se [130.244.108.117]) by mb05.swip.net (8.8.8/8.8.8) with SMTP id WAA05551 for ; Tue, 14 Apr 1998 22:03:51 +0200 (MET DST) Message-Id: <199804142003.WAA05551@mb05.swip.net> X-Sender: mg34035@gaia.swipnet.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 14 Apr 1998 22:02:04 +0200 To: freebsd-security@FreeBSD.ORG From: Bjarni Ingolfsson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 14 18:17:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06849 for freebsd-security-outgoing; Tue, 14 Apr 1998 18:17:13 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from r.scl.ameslab.gov (r.scl.ameslab.gov [147.155.137.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA06840; Wed, 15 Apr 1998 01:17:07 GMT (envelope-from ghelmer@scl.ameslab.gov) Received: from demios.scl.ameslab.gov (demios.ether.scl.ameslab.gov [147.155.137.54]) by r.scl.ameslab.gov (8.8.5/8.8.3) with SMTP id UAA01848; Tue, 14 Apr 1998 20:17:07 -0500 (CDT) Date: Tue, 14 Apr 1998 20:17:06 -0500 (CDT) From: Guy Helmer To: freebsd-chat@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Security Features of FreeBSD article Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk (Apologies for the cross-post -- it seems relevant to chat as well, given the freebsd advocacy discussions of late.) I recently mentioned in freebsd-security that an article I wrote, Security Tools in FreeBSD, has been published in the May issue of SysAdmin. I've just checked their web site, and they have made it their feature article for May (meaning it is on-line!). Here is the URL, which will likely only be valid for a month or so: http://www.samag.com/current/feature.html Here's hoping that we can raise the visibility of FreeBSD! Appropriate thanks directed, as always, to the core team, other developers, and everyone who helped with this article. Thanks to SysAdmin as well for publishing the article and making it available on the web. Guy Helmer, Graduate Student, Iowa State University Dept. of Computer Science Research Assistant, Ames Laboratory --- ghelmer@scl.ameslab.gov http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 14 20:37:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA05116 for freebsd-security-outgoing; Tue, 14 Apr 1998 20:37:14 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from wumpus.its.uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA05090 for ; Wed, 15 Apr 1998 03:37:07 GMT (envelope-from ncb05@uow.edu.au) Received: from wumpus.its.uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12]) by wumpus.its.uow.edu.au (8.8.8/8.8.7) with SMTP id NAA13129; Wed, 15 Apr 1998 13:36:31 +1000 (EST) Date: Wed, 15 Apr 1998 13:36:31 +1000 (EST) From: Nicholas Charles Brawn X-Sender: ncb05@wumpus.its.uow.edu.au To: Bill Trost cc: freebsd-security@FreeBSD.ORG Subject: Re: Is there a safe way for filesystem export? In-Reply-To: <12282.892576468@cloud.rain.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk While we are discussing IPsec, are there any free implementations available for us non-US folks? (for *BSD) Nicholas Brawn -- Email: ncb05@uow.edu.au Nicholas Brawn - Computer Science Undergraduate, University of Wollongong. On Tue, 14 Apr 1998, Bill Trost wrote: > "Angelos D. Keromytis" writes: > One way for doing secure (against external attackers, anyway) > is to use IPsec. There is/was an IPsec implementation from WIDE > for FreeBSD, and my code from OpenBSD should be trivial to > port. In fact, we might make a port to FreeBSD during the summer > (unfortunately, that would be available only to US citizens). > > There is also a port of the NRL IPSEC implementation available (to US > citizens...sigh) as part of the Portland State University's Mobile IP > via http://www.cs.pdx.edu/research/SMN/. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 06:15:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA20831 for freebsd-security-outgoing; Wed, 15 Apr 1998 06:15:37 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from orion.unisc.br ([200.17.83.36]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA20808; Wed, 15 Apr 1998 13:15:15 GMT (envelope-from trainini@unisc.br) Received: from gauss.unisc.br by orion.unisc.br (5.65v3.2/1.1.10.5/04Mar97-0201PM) id AA13519; Wed, 15 Apr 1998 11:15:51 -0400 Message-Id: <3.0.1.32.19980415101437.00710104@orion.unisc.br> X-Sender: trainini@orion.unisc.br X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 15 Apr 1998 10:14:37 -0300 To: freebsd-chat@FreeBSD.ORG, freebsd-security@FreeBSD.ORG From: Paulo Ricardo Trainini Subject: table is full (ajude-me por favor) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id NAA20822 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Seguido uma das máquinas da nossa rede reboota sozinha. Ela tem duas interfaces da rede. O arquivo /var/log/dmesg.today está com várias linhas de conteúdo "file: table is full". O arquivo de configuração do kernel está com "maxusers=10". Não sei se isto está relacionado. Qualquer ajuda é bem vinda. Grato pela atenção. Paulo ----- Paulo Ricardo Trainini e-mail: trainini@unisc.br fone: +55 051 717-7424 Administrador de Rede fax: +55 051 717-1855 UNISC - Universidade de Santa Cruz do Sul Setor de Informática To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 08:40:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA21858 for freebsd-security-outgoing; Wed, 15 Apr 1998 08:40:55 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA21852; Wed, 15 Apr 1998 15:40:49 GMT (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id LAA26889; Wed, 15 Apr 1998 11:40:17 -0400 (EDT) Date: Wed, 15 Apr 1998 11:40:17 -0400 (EDT) From: "Matthew N. Dodd" Reply-To: "Matthew N. Dodd" To: Paulo Ricardo Trainini cc: freebsd-chat@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: table is full (ajude-me por favor) In-Reply-To: <3.0.1.32.19980415101437.00710104@orion.unisc.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [translation from babelfish] On Wed, 15 Apr 1998, Paulo Ricardo Trainini wrote: > Seguido uma das máquinas da nossa rede reboota sozinha. Ela tem duas > interfaces da rede. O arquivo /var/log/dmesg.today está com várias linhas > de conteúdo "file: table is full". > > O arquivo de configuração do kernel está com "maxusers=10". Não sei se > isto está relacionado. > > Qualquer ajuda é bem vinda. Grato pela atenção. Translation: > "One of the machines on our network reboots. It has two interfaces to > the network. The archive /var/log/dmesg.today has the following string > 'file table is full'. > > The kernel config file has 'maxusers=10'. I do not know if this is > related. > > Any help would be appriciated. Thanks for the attention." A server should have a larger value for 'maxusers'. You should set it to 64 at the very least. "Um server deve ter um valor maior para 'maxusers'. Voce^ deve ajusta'-lo a 64 no muito o mais menos." http://babelfish.altavista.digital.com/cgi-bin/translate? /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 09:53:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA08143 for freebsd-security-outgoing; Wed, 15 Apr 1998 09:53:24 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08039; Wed, 15 Apr 1998 16:53:01 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id JAA00719; (8.8.8/RDY) Wed, 15 Apr 1998 09:52:58 -0700 (PDT) Message-Id: <199804151652.JAA00719@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: <19282.892651401@cloud.rain.com> from Bill Trost at "Apr 15, 98 07:43:21 am" To: trost@cloud.rain.com (Bill Trost) Date: Wed, 15 Apr 1998 09:52:58 -0700 (PDT) Cc: stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Bill Trost writes: > Dima Ruban writes: > Is there a particular reason of kernel being installed with 555 root/wheel > permissions instead of 550 root/kmem ? > > If nobody has nothing against it - I'll commit the change. > > Is "/kernel" typically the first command in the pipe, or should it > appear in the middle? (-: > > Maybe I am missing something, but I see no reason for /kernel to have > the execute bits set. I doubt that the boot loader cares, and no one > wants to actually execute the kernel when it's already running. Sure, 440 permissions are fine with me. > As for the world read permissions: Removing the read permissions seems > like a gratuitious pseudo-security change. Is there any reason to > prevent users from reading the kernel? Presumably, /usr/src/sys is In some case I don't want my users to read a kernel name list. > readable anyhow, so a person could build their own kernel with the same > configuration, so they may as well just copy the running one. You do not always have /usr/src/sys on your machine. Especially on a production enviroment. > Or, in other words -- if you are going to make a change, 0444 seems like > the way to go. I'd say 0440 > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 10:13:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA13734 for freebsd-security-outgoing; Wed, 15 Apr 1998 10:13:12 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA13282; Wed, 15 Apr 1998 17:11:14 GMT (envelope-from karl@Jupiter.Mcs.Net) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id MAA26282; Wed, 15 Apr 1998 12:10:50 -0500 (CDT) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.7/8.8.2) id MAA06498; Wed, 15 Apr 1998 12:10:49 -0500 (CDT) Message-ID: <19980415121049.17497@Mcs.Net> Date: Wed, 15 Apr 1998 12:10:49 -0500 From: Karl Denninger To: dima@best.net Cc: Bill Trost , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions References: <19282.892651401@cloud.rain.com> <199804151652.JAA00719@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199804151652.JAA00719@burka.rdy.com>; from Dima Ruban on Wed, Apr 15, 1998 at 09:52:58AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, Apr 15, 1998 at 09:52:58AM -0700, Dima Ruban wrote: > Bill Trost writes: > > Dima Ruban writes: > > Is there a particular reason of kernel being installed with 555 root/wheel > > permissions instead of 550 root/kmem ? > > > > If nobody has nothing against it - I'll commit the change. > > > > Is "/kernel" typically the first command in the pipe, or should it > > appear in the middle? (-: > > > > Maybe I am missing something, but I see no reason for /kernel to have > > the execute bits set. I doubt that the boot loader cares, and no one > > wants to actually execute the kernel when it's already running. > > Sure, 440 permissions are fine with me. > > > As for the world read permissions: Removing the read permissions seems > > like a gratuitious pseudo-security change. Is there any reason to > > prevent users from reading the kernel? Presumably, /usr/src/sys is > > In some case I don't want my users to read a kernel name list. > > > readable anyhow, so a person could build their own kernel with the same > > configuration, so they may as well just copy the running one. > > You do not always have /usr/src/sys on your machine. Especially > on a production enviroment. > > > Or, in other words -- if you are going to make a change, 0444 seems like > > the way to go. > > I'd say 0440 Agreed. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 10:27:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18902 for freebsd-security-outgoing; Wed, 15 Apr 1998 10:27:31 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (root@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18708; Wed, 15 Apr 1998 17:27:09 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id KAA01452; (8.8.8/RDY) Wed, 15 Apr 1998 10:20:32 -0700 (PDT) Message-Id: <199804151720.KAA01452@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: <19980415121049.17497@Mcs.Net> from Karl Denninger at "Apr 15, 98 12:10:49 pm" To: karl@Mcs.Net (Karl Denninger) Date: Wed, 15 Apr 1998 10:20:32 -0700 (PDT) Cc: dima@best.net, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Okay, if I won't have any objections in the next 2 hours, I'll commit it into -current, and either today evening or tomorrow into -stable Karl Denninger writes: > > > Or, in other words -- if you are going to make a change, 0444 seems like > > > the way to go. > > > > I'd say 0440 > > Agreed. > > -- > -- > Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin > http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV > | NEW! Corporate ISDN Prices dropped by up to 50%! > Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS > Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 11:21:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03573 for freebsd-security-outgoing; Wed, 15 Apr 1998 11:21:52 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03563 for ; Wed, 15 Apr 1998 18:21:48 GMT (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id LAA28121; Wed, 15 Apr 1998 11:21:18 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma028119; Wed Apr 15 11:20:57 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id LAA17263; Wed, 15 Apr 1998 11:20:57 -0700 (PDT) From: Archie Cobbs Message-Id: <199804151820.LAA17263@bubba.whistle.com> Subject: Re: Is there a safe way for filesystem export? In-Reply-To: from Nicholas Charles Brawn at "Apr 15, 98 01:36:31 pm" To: ncb05@uow.edu.au (Nicholas Charles Brawn) Date: Wed, 15 Apr 1998 11:20:57 -0700 (PDT) Cc: trost@cloud.rain.com, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Nicholas Charles Brawn writes: > While we are discussing IPsec, are there any free implementations > available for us non-US folks? (for *BSD) > > Nicholas Brawn > > -- > Email: ncb05@uow.edu.au > Nicholas Brawn - Computer Science Undergraduate, University of Wollongong. > > On Tue, 14 Apr 1998, Bill Trost wrote: > > > "Angelos D. Keromytis" writes: > > One way for doing secure (against external attackers, anyway) > > is to use IPsec. There is/was an IPsec implementation from WIDE > > for FreeBSD, and my code from OpenBSD should be trivial to WIDE is a Japanese organization, so that counts. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 12:25:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA16727 for freebsd-security-outgoing; Wed, 15 Apr 1998 12:25:41 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from set.spradley.tmi.net (set.spradley.tmi.net [207.170.107.99]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA16708; Wed, 15 Apr 1998 19:25:30 GMT (envelope-from tsprad@set.spradley.tmi.net) Received: from localhost (set.spradley.tmi.net) [127.0.0.1] by set.spradley.tmi.net with esmtp (Exim 1.82 #2) id 0yPXnd-0004WJ-00; Wed, 15 Apr 1998 14:24:49 -0500 X-Mailer: exmh version 2.0zeta 7/24/97 To: dima@best.net cc: trost@cloud.rain.com (Bill Trost), stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Wed, 15 Apr 1998 09:52:58 PDT." <199804151652.JAA00719@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Apr 1998 14:24:48 -0500 From: Ted Spradley Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > As for the world read permissions: Removing the read permissions seems > > like a gratuitious pseudo-security change. Is there any reason to > > prevent users from reading the kernel? Presumably, /usr/src/sys is > > In some case I don't want my users to read a kernel name list. > > > readable anyhow, so a person could build their own kernel with the same > > configuration, so they may as well just copy the running one. > > You do not always have /usr/src/sys on your machine. Especially > on a production enviroment. You can change the permissions any way you like on your machine. Users who are knowledgeable enough to worry about know where they can find the sources. To me, this is just gratuitous change for the sake of change. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 12:49:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA22591 for freebsd-security-outgoing; Wed, 15 Apr 1998 12:49:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22497; Wed, 15 Apr 1998 19:49:38 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id MAA02749; (8.8.8/RDY) Wed, 15 Apr 1998 12:49:27 -0700 (PDT) Message-Id: <199804151949.MAA02749@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: from Ted Spradley at "Apr 15, 98 02:24:48 pm" To: tsprad@set.spradley.tmi.net (Ted Spradley) Date: Wed, 15 Apr 1998 12:49:27 -0700 (PDT) Cc: dima@best.net, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Ted Spradley writes: > > > > As for the world read permissions: Removing the read permissions seems > > > like a gratuitious pseudo-security change. Is there any reason to > > > prevent users from reading the kernel? Presumably, /usr/src/sys is > > > > In some case I don't want my users to read a kernel name list. > > > > > readable anyhow, so a person could build their own kernel with the same > > > configuration, so they may as well just copy the running one. > > > > You do not always have /usr/src/sys on your machine. Especially > > on a production enviroment. > > You can change the permissions any way you like on your machine. Users who are knowledgeable enough to worry about know where they can find the sources. To me, this is just gratuitous change for the sake of change. One more time. In some cases you don't want your users to read kernel namelist. Generic kernel source code won't help. Another example. Do search on your local box for all the programs, that don't allow 'others' to read the binary. Ever wonder why? > > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 13:03:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA25874 for freebsd-security-outgoing; Wed, 15 Apr 1998 13:03:51 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from io.uwinnipeg.ca (sbalneav@io.uwinnipeg.ca [142.132.1.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA25788 for ; Wed, 15 Apr 1998 20:03:19 GMT (envelope-from sbalneav@UWinnipeg.ca) Received: from localhost (sbalneav@localhost) by io.uwinnipeg.ca (8.8.8/8.8.8) with SMTP id PAA27109 for ; Wed, 15 Apr 1998 15:03:16 -0500 (CDT) Date: Wed, 15 Apr 1998 15:03:16 -0500 (CDT) From: "Scott L. Balneaves" Reply-To: scott.balneaves@UWinnipeg.ca To: freebsd-security@FreeBSD.ORG Subject: pw_fields in struct passwd Message-ID: Organization: University of Winnipeg MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Hello all: Not sure if this is the right place to ask, but... I'm currently working on a putpwent() routine. We have a FreeBSD box that serves over 7000 student accounts. The claimid process is automatic, and I'm having to run a pwd_mkdb every hour. However, with 7000 users and an average of 100+ logged in at any time, the chances of the password database being locked are pretty high. Things are going well, I already have a program that extracts a master.passwd file from the hashed database. What isn't documented anywhere is what the pw_field entry in the passwd structure is doing. In looking through the source for chpass, it seems to be related to YP. Does anyone have any tips as to how I'm to build this field up? Thanks in advance... Scott ---------------------------------------------------------------------------- Scott Balneaves, U of W Unix Support| A right is not what someone gives you; Email: sbalneav@uwinnipeg.ca | it's what no one can take from you. | -- Ramsey Clark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 14:36:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20369 for freebsd-security-outgoing; Wed, 15 Apr 1998 14:36:42 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA20350 for ; Wed, 15 Apr 1998 21:36:21 GMT (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id RAA03456; Wed, 15 Apr 1998 17:36:08 -0400 (EDT) (envelope-from wollman) Date: Wed, 15 Apr 1998 17:36:08 -0400 (EDT) From: Garrett Wollman Message-Id: <199804152136.RAA03456@khavrinen.lcs.mit.edu> To: scott.balneaves@UWinnipeg.ca Cc: freebsd-security@FreeBSD.ORG Subject: pw_fields in struct passwd In-Reply-To: References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk < said: > anywhere is what the pw_field entry in the passwd structure is doing. In > looking through the source for chpass, it seems to be related to YP. > Does anyone have any tips as to how I'm to build this field up? It indicates which fields in the original password file were actually specified explicitly, rather than left blank; it is necessary in order to allow YP `+user' entries to work with the correct overriding behavior. -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 security" in the body of the message From owner-freebsd-security Wed Apr 15 17:31:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08248 for freebsd-security-outgoing; Wed, 15 Apr 1998 17:31:10 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from infowest.com (infowest.com [204.17.177.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08027 for ; Wed, 15 Apr 1998 17:30:28 -0700 (PDT) (envelope-from agifford@infowest.com) Received: from liberty.infowest.com (liberty.infowest.com [207.49.60.254]) by infowest.com (8.8.8/8.8.5) with SMTP id SAA10227 for ; Wed, 15 Apr 1998 18:29:36 -0600 (MDT) Date: Wed, 15 Apr 1998 18:29:36 -0600 (MDT) Message-Id: <199804160029.SAA10227@infowest.com> From: "Aaron D. Gifford" Subject: Any news on this?: CA-98.05 Multiple Vulnerabilities in BIND To: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Hello, For some reason, it seems that my subscription to freebsd-security@freebsd.org list stuttered and I haven't seen any messages from about Apr. 8th to the 14th. I was wondering if anyone during this time mentioned the recent CERT advisory regarding BIND 4.9 and 8 issued on the 8th. (I've included a copy below.) Thanks! Aaron out. Forwarded from the BUGTRAQ@netspace.org list: -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT* Advisory CA-98.05 Original issue date: April 08, 1998 Topic: Multiple Vulnerabilities in BIND 1. Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases 2. Denial-of-Service Vulnerabilities in BIND 4.9 and BIND 8 Releases 3. Denial-of-Service Vulnerability in BIND 8 Releases - ---------------------------------------------------------------------------- I. Description This advisory describes three distinct problems in BIND. Topic 1 describes a vulnerability that may allow a remote intruder to gain root access on your name server or to disrupt normal operation of your name server. Topics 2 and 3 deal with vulnerabilities that can allow an intruder to disrupt your name server. Detailed descriptions of each problem and its solutions are included in the individual sections on each topic. II. Impact Topic 1: A remote intruder can gain root-level access to your name server. Topics 2 and 3: A remote intruder is able to disrupt normal operation of your name server. III. Solution All three problems can be fixed by upgrading to the latest version of BIND, which may be available from your vendor (see Appendix A of this advisory). Questions about the availability of patches from your vendor should be directed to your vendor. Additionally, the Internet Software Consortium will announce new publicly available versions of BIND very soon on the BIND WWW page (http://www.isc.org/bind.html) and on the USENET newsgroup comp.protocols.dns.bind. Additionally, patches are provided for Topics 1 and 3, along with steps to take until you can apply the patch or upgrade to the latest version of BIND. ************************************************************************* Topic 1: Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases ************************************************************************* 1.A. Description BIND 4.9 releases prior to BIND 4.9.7 and BIND 8 releases prior to 8.1.2 do not properly bounds check a memory copy when responding to an inverse query request. An improperly or maliciously formatted inverse query on a TCP stream can crash the server or allow an attacker to gain root privileges. 1.B. Determining if your system is vulnerable The inverse query feature is disabled by default, so only the systems that have been explicitly configured to allow it are vulnerable. BIND 8 Look at the "options" block in the configuration file (typically /etc/named.conf). If there is a "fake-iquery yes;" line, then the server is vulnerable. BIND 4.9 Look at the "options" lines in the configuration file (typically /etc/named.boot). If there is a line containing "fake-iquery", then the server is vulnerable. In addition, unlike BIND 8, inverse query support can be enabled when the server is compiled. Examine conf/options.h in the source. If the line #defining INVQ is not commented out, then the server is vulnerable. 1.C. What To Do To address this problem, you can disable inverse queries, upgrade to BIND 8.1.2 when it becomes available, or apply the patch provided below. We urge you to disable inverse queries until you can take one of the other steps. Disabling inverse queries ------------------------- BIND 8 Disable inverse queries by editing named.conf so that either there is no "fake-iquery" entry in the "options" block or the entry is "fake-iquery no;" BIND 4.9 Disable inverse queries by editing named.boot, removing any "fake-iquery" entries on "options" lines. Look at conf/options.h in the source. If INVQ has been defined, comment it out and then rebuild and reinstall the server. Note: Disabling inverse query support can break ancient versions of nslookup. If nslookup fails, replace it with a version from any BIND 4.9 or BIND 8 distribution. Fixing the Inverse Query Code ----------------------------- BIND 8 Upgrade to BIND 8.1.2 when it becomes available or apply the patch at this URL: ftp://ftp.cert.org/pub/cert_advisories/Patches/CA-98.05_Topic.1_BIND8_patch.txt This file is not PGP signed. It has the following MD5 checksum: MD5 (CA-98.05_Topic.1_BIND8_patch.txt) = 12fc9d395ff987b1aad17a882ccd7840 BIND 4.9 Upgrade to BIND 4.9.7 when it becomes available or apply the patch at this URL: ftp://ftp.cert.org/pub/cert_advisories/Patches/CA-98.05_Topic.1_BIND4.9_patch.txt This file is not PGP signed. It has the following MD5 checksum: MD5 (CA-98.05_Topic.1_BIND4.9_patch.txt) = 32da0db1c27e4d484e6fcb7901267c2f Notes: (1) We are asking sites to retrieve the patches via FTP rather than including them in the advisory since our experience is that some mail handling systems translate tabs into spaces. This prevents the patch(1) program from working properly. (2) We have not PGP signed the files since our experience is that some implementations of PGP during the extraction process will strip spaces from some lines containing whitespace only. This may prevent the patch(1) program from working properly. ************************************************************************** Topic 2: Denial-of-Service Vulnerabilities in BIND 4.9 and BIND 8 Releases ************************************************************************** 2.A. Description BIND 4.9 releases prior to BIND 4.9.7 and BIND 8 releases prior to 8.1.2 do not properly bounds check many memory references in the server and the resolver. An improperly or maliciously formatted DNS message can cause the server to read from invalid memory locations, yielding garbage record data or crashing the server. Many DNS utilities that process DNS messages (e.g., dig, nslookup) also fail to do proper bounds checking. 2.B. Determining if your system is vulnerable Any system running BIND 4.9 prior to 4.9.7 or BIND 8 prior to 8.1.2 is vulnerable. 2.C. What To Do There are no workarounds for these problems. BIND 8 Upgrade to BIND 8.1.2 when it becomes available. BIND 4.9 Upgrade to BIND 4.9.7 when it becomes available. ************************************************************************** Topic 3: Denial-of-Service Vulnerability in BIND 8 Releases ************************************************************************** 3.A. Description Assume that the following self-referential resource record is in the cache on a name server: foo.example. IN A CNAME foo.example. The actual domain name used does not matter; the important thing is that the target of the CNAME is the same name. The record could be in the cache either because the server was authoritative for it or because the server is recursive and someone asked for it. Once this record is in the cache, issuing a zone transfer request using its name (e.g., "dig @my_nameserver foo.example. axfr") will cause the server to abort(). Most sites will not contain such a record in their configuration files. However, it is possible for an attacker to engineer such a record into the cache of a vulnerable nameserver and thus cause a denial of service. 3.B. Determining if your system is vulnerable If the BIND 8 server is not recursive and does not fetch glue, then the problem can be exploited only if the self-referential resource record is in a zone for which the server is authoritative. If the global zone transfer ACL in the options block has been set to deny access and has no self-referential CNAMEs in its authoritative zones, then the server is not vulnerable. Otherwise, the server is vulnerable. The nameserver is recursive by default, fetches glue by default, and the default global transfer ACL allows all hosts; so many BIND 8 servers will be vulnerable to this problem. (Note: the in.named(8) man page mentions that sending a SIGINT to the in.named process will dump the current data base and cache to, by default, /var/tmp/named_dump.db. Some sites may find this useful in looking for self-referential CNAMEs. Please see the in.named(8) man page for further details.) 3.C. What To Do To address this problem, you can apply the workaround described below, upgrade to BIND 8.1.2, or apply the patch provided at the end of this section. Until you can upgrade or apply the patch, we urge you to use the workaround. Workaround ---------- First set the global zone transfer ACL to deny access to all hosts by adding the following line to the "options" block: allow-transfer { none; }; Next, explicitly authorize zone transfers for each authoritative zone. For example, if the server was authoritative for "example", adding allow-transfer { any; }; to the "zone" statement for "example" would allow anyone to transfer "example". None of the domains for which the server is authoritative should have self-referential CNAMEs. Fixing the Problem ------------------ Upgrade to BIND 8.1.2 when it becomes available or apply the patch at the following URL to the BIND 8.1.1 source: ftp://ftp.cert.org/pub/cert_advisories/Patches/CA-98.05_Topic.3_BIND8.1.1_patch.txt This file is not PGP signed. It has the following MD5 checksum: MD5 (CA-98.05_Topic.3_BIND8.1.1_patch.txt) = 33f9dc2eaf221dd48553f490259c2a8b Notes: (1) We are asking sites to retrieve the patches via FTP rather than including them in the advisory since our experience is that some mail handling systems translate tabs into spaces. This prevents the patch(1) program from working properly. (2) We have not PGP signed the files since our experience is that some implementations of PGP during the extraction process will strip spaces from some lines containing whitespace only. This may prevent the patch(1) program from working properly. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Appendix A - Vendor Information Below is a list of the vendors who have provided information for this advisory. We will update this appendix as we receive additional information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact the vendor directly. Berkeley Software Design, Inc. (BSDI) - ------------------------------------- 1. BSD/OS 3.0/3.1 AS SHIPPED is not vulnerable. Sites wishing to enable fake-iquery can install mod M310-025, available at http://www.bsdi.com 2. BSDI will issue a 3.1 mod when a fix is available. 3. BSD/OS is not vulnerable, since we ship bind 4.9.6 Digital Equipment Corporation - ----------------------------- Digital is investigating this problem. FreeBSD, Inc. - ------------- We ship with INVQ not defined. This makes us resistent against the first vulnerability. This is true for all release after 2.2.0 (2.1.* releases are vulnerable but should be upgraded anyway). As we do not yet ship BIND 8, we are also not vulnerable to the 3rd vulnerability. We advise everyone to upgrade to BIND 4.9.7. Hewlett-Packard Company - ----------------------- HP is Vulnerable. Patches in process. Watch for the release of the associated HP Security Bulletin. Hewlett Packard's HP-UX patches/Security Bulletins/Security patches are available via email and/or WWW (via the browser of your choice) on HP's Electronic Support Center (ESC). --------------------------------------------------------------------- To subscribe to automatically receive future NEW HP Security Bulletins from the HP ESC Digest service via electronic mail, do the following: 1) From your Web browser, access the URL: http://us-support.external.hp.com (US,Canada,Asia-Pacific, and Latin-America) http://europe-support.external.hp.com (Europe) Login with your user ID and password, or register for one (remember to save the User ID assigned to you, and your password). Once you are on the Main Menu, Click on the Technical Knowledge Database, and it will connect to a HP Search Technical Knowledge DB page. Near the bottom is a hyperlink to our Security Bulletin archive. Once in the archive there is another link to our current security patch matrix. Updated daily, this matrix is categorized by platform/OS release, and by bulletin topic. To subscribe to receive future Security Bulletins be email, look for the subscription section on the Technical Knowledge Database page. IBM Corporation - --------------- The version of bind shipped with AIX is vulnerable and the following APARs will be available soon: AIX 4.1.x: IX76958 (fix for Topic 1 only) AIX 4.2.x: IX76959 (fix for Topic 1 only) AIX 4.3.x: IX76960 (fix for Topic 1 and 3 only) AIX 4.3.x: IX76962 (fix for Topic 1, 2, and 3. This is bind 8.1.2.) Until the official fixes are available, a temporary patch can be found at: ftp://aix.software.ibm.com/aix/efixes/security File sum md5 ==================================================================== named.415.tar.Z 64980 157 0e795380b84bf29385d2d946d10406cb named.421.tar.Z 44963 157 15a9a006abf4a9d0a0d3210f16d619e5 named4.430.tar.Z 48236 115 8377b14f74e207707154a9677906f20a named8.430.tar.Z 51175 160 e2db14b7055a7424078456bfbfd9bf2d Detached PGP signatures are also available with a ".asc" extension. IBM and AIX are registered trademarks of International Business Machines Corporation. NEC Corporation =============== Topic1 - Some systems are vulnerable. Patches will be available soon, especially for UX/4800 R11.x and R13.x. Topic2 - Some systems are vulnerable. Patches will be available soon after the release of bind-4.9.7, especially for UX/4800 R11.x and R13.x. Topic3 - We do not ship BIND 8 with our products so we are not vulnerable to this problem. Patches will be available from ftp://ftp.meshnet.or.jp/pub/48pub/security. The NetBSD Project - ------------------ The first problem can be fixed in NetBSD 1.3, 1.3.1, and -current prior to 19980408 with the supplied BIND 4.9.6 patch. A patch will be made available for the second problem shortly (alternatively, upgrading to BIND 4.9.7 or 8.1.2 when available will also solve this problem.) NetBSD is not affected by the third problem. Red Hat Software, Inc. - ---------------------- Red Hat fixes will be available at: Red Hat 5.0 ------------- i386: rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/bind-4.9.6-7.i386.rpm alpha: rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/bind-4.9.6-7.alpha.rpm Red Hat 4.2 ------------- i386: rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/bind-4.9.6-1.1.i386.rpm alpha: rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/bind-4.9.6-1.1.alpha.rpm SPARC: rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/bind-4.9.6-1.1.sparc.rpm The Santa Cruz Operation, Inc. - ------------------------------ The following SCO products are vulnerable: - SCO Open Desktop/Open Server 3.0, SCO UNIX 3.2v4 - SCO OpenServer 5.0 (also SCO Internet FastStart) - SCO UnixWare 2.1 - SCO UnixWare 7 SCO CMW+ 3.0 is not vulnerable as BIND/named is not supported on CMW+ platforms. Binary versions of BIND 4.9.7 will be available shortly from the SCO ftp site: ftp://ftp.sco.com/SSE/sse012.ltr - cover letter ftp://ftp.sco.com/SSE/sse012.tar.Z - replacement binaries The fix includes binaries for the following SCO operating systems: - SCO Open Desktop/Open Server 3.0, SCO UNIX 3.2v4 - SCO OpenServer 5.0 - SCO UnixWare 2.1 - SCO UnixWare 7 For the latest security bulletins and patches for SCO products, please refer to http://www.sco.com/security/ . Silicon Graphics, Inc. - ---------------------- At this time, Silicon Graphics does not have any public information for the DNS issue. Silicon Graphics is in communication with CERT and other external parties and is actively investigating this issue. Additional information, is expected shortly. When more Silicon Graphics information (including patch information) is available for release, that information will be released via the SGI security mailing list, wiretap. For subscribing to the wiretap mailing list and other SGI security related information, please refer to the Silicon Graphics Security Headquarters website located at: http://www.sgi.com/Support/security Sun Microsystems, Inc. - ---------------------- Topic 1: Patches will be produced for Solaris 5.3, 5.4, 5.5, 5.5.1 and 5.6. Topic 2: Patches will be produced for Solaris 5.3, 5.4, 5.5, 5.5.1 and 5.6. Topic 3: Bug fix will be integrated in the upcoming release of Solaris. - ---------------------------------------------------------------------------- The CERT Coordination Center thanks Bob Halley and Paul Vixie of Vixie Enterprises, who provided most of the text of this advisory. Reminder: The Internet Software Consortium will announce new publicly available versions of BIND on the BIND WWW page (http://www.isc.org/bind.html) and on the USENET newsgroup comp.protocols.dns.bind. - ---------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). See http://www.first.org/team-info/. We strongly urge you to encrypt any sensitive information you send by email. The CERT Coordination Center can support a shared DES key and PGP. Contact the CERT staff for more information. Location of CERT PGP key ftp://ftp.cert.org/pub/CERT_PGP.key CERT Contact Information - ------------------------ Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST (GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA Using encryption We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information. Location of CERT PGP key ftp://ftp.cert.org/pub/CERT_PGP.key Getting security information CERT publications and other security information are available from http://www.cert.org/ ftp://ftp.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce To be added to our mailing list for advisories and bulletins, send email to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address - --------------------------------------------------------------------------- Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff . If you do not have FTP or web access, send mail to cert@cert.org with "copyright" in the subject line. * CERT is registered U.S. Patent and Trademark Office. - --------------------------------------------------------------------------- This file: ftp://ftp.cert.org/pub/cert_advisories/CA-98.05.bind_problems http://www.cert.org/pub/alerts.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNSvm6XVP+x0t4w7BAQHHTQQA1iHeiwZLGyDVjbSfG1gte2XZorQWiXT+ WYrE6ZdJ1RuD0HFE3iSvSA/OIXeyGkwJthc9SOfcVmw9ttdmABBJFe6ympOj2+8t GxUJZCtuV+/Yf03Ak0rFnMM3ILglPyPDCY+z3bNlX0sUytUJA5QVxUXbRqaT2L2l E03NG1k5um8= =TExM -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 17:51:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16072 for freebsd-security-outgoing; Wed, 15 Apr 1998 17:51:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15983 for ; Wed, 15 Apr 1998 17:51:07 -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 UAA27392; Wed, 15 Apr 1998 20:50:42 -0400 (EDT) Date: Wed, 15 Apr 1998 20:50:42 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Aaron D. Gifford" cc: freebsd-security@FreeBSD.ORG Subject: Re: Any news on this?: CA-98.05 Multiple Vulnerabilities in BIND In-Reply-To: <199804160029.SAA10227@infowest.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 15 Apr 1998, Aaron D. Gifford wrote: > For some reason, it seems that my subscription to freebsd-security@freebsd.org > list stuttered and I haven't seen any messages from about Apr. 8th to the 14th. > I was wondering if anyone during this time mentioned the recent CERT advisory > regarding BIND 4.9 and 8 issued on the 8th. (I've included a copy below.) Mine appeared to do the same -- and I think a message I sent didn't get through either. :) Did anyone see a post about securelevel implementation in FreeBSD? If not, I'll resend. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 18:02:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18464 for freebsd-security-outgoing; Wed, 15 Apr 1998 18:02:07 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18389 for ; Wed, 15 Apr 1998 18:01:48 -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 VAA27535 for ; Wed, 15 Apr 1998 21:01:45 -0400 (EDT) Date: Wed, 15 Apr 1998 21:01:45 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-security@FreeBSD.ORG Subject: securelevels and more liberal use of schg on system files (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk (resend due to stuttering mailing lists :) ---------- Forwarded message ---------- Date: Tue, 7 Apr 1998 17:29:10 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: security@freebsd.org Subject: securelevels and more liberal use of schg on system files (fwd) The following discussion of securelevels is the result of some experimentation and largely consists of brainstorming, but might make for some interesting discussion (if other people find it interesting :). BSD/OS and others make use of securelevels in their production releases to prevent time rewinds, etc. It may be desirable that FreeBSD do so in the future. Currently, however, securelevels do little if anything to actually increase the security of a system. I think this can be improved through some careful thinking out of the issues, and would like to see this happen in FreeBSD. :) All experimentation was performed on 2.2-STABLE a few days ago. -- Through securelevels, FreeBSD can be hardened against a root compromise -- securelevel >= 2 prevents (short list): 1) Modification of init that might result in the securelevel being lowered (via ptrace, procfs) 2) Writing to /dev/kern-type files where kernel modifications could be used to lower the securelevel 3) Prevent writing to character and block devices for mountable hard drives, etc, that might be used to modify the kernel on disk, etc. 4) securelevel can only be raised, never lowered using sysctl 5) the schg, sappnd and sunlnk flags are now enforced for uid 0 (also, other behavior depending on the file system, syscalls, etc) Additionally, make installworld applies the schg flag to a few key files to prevent modification that might result on problems going to single-user mode, or next boot: /kernel # technically during install of kernel /bin/rcp /sbin/init /usr/sbin/sliplogin /usr/bin/chfn /usr/bin/chpass /usr/bin/chsh /usr/bin/crontab /usr/bin/login /usr/bin/man /usr/bin/passwd /usr/bin/rlogin /usr/bin/rsh /usr/bin/su /usr/bin/ypchfn /usr/bin/ypchpass /usr/bin/ypchsh /usr/bin/yppasswd /usr/lib/libc.so.3.1 /usr/lib/libcipher.so.2.0 /usr/lib/libdescrypt.so.2.0 /usr/libexec/ld.so /usr/libexec/mail.local There may be others, but I have not found them in my cursory search. It is now useful to observe how it is we get into a non- -1 securelevel. The man page init(8) makes the following recommendation: If the security level is initially -1, then init leaves it unchanged. Otherwise, init arranges to run the system in level 0 mode while single user and in level 1 mode while multiuser. If level 2 mode is desired while running multiuser, it can be set while single user, e.g., in the startup script /etc/rc, using sysctl(8). Note that it is not init(8) itself that performs the sysctl activity, but rather the rc(8) script. In a sense, it cannot be init(8), as the rc(8) script later runs fsck(8) to clean the file systems, and it requires write access to the block devices. However, this does leave us with a few problems. Neither /etc/rc nor /usr/sbin/sysctl are protected by schg. For that matter, neither is fsck, or any number of utilities used by rc(8) prior to being able to raise the securelevel. While some of the above files clearly deserve to be schg, there do appear to be a few interlopers (passwd? :) on the domain of the carefully protected. thithle:/# sysctl kern.securelevel kern.securelevel: 2 thithle:/# cp /bin/echo /usr/sbin/sysctl or better, thithle:/# cp ~hacked/rc /etc/rc Additionally, while we notice that the files are protected against modification (and links to them), the directories are *NOT*. /sbin/init is schg, but the directory /sbin is not! Similarly with all of the other non-/ files (i.e., all but /kernel). To replace init(8) at the next boot, I can happily do the following: thithle:/# mv /sbin /sbinsbin thithle:/# mkdir /sbin thithle:/# cp /sbinsbin/* /sbin thithle:/# cp ~hacked/myinit /sbin/init thithle:/# reboot schg does prevent modifications to init(8) that might result in paging in replacement pages of text into the current init, but not against actions over reboot. One response to the problem of key binaries in / and /etc is to mount the root partition (and /etc) as read-only devices instead of read-write. However, securelevel does not prevent the remounting of devices as read-write from an initial read-only state: thithle:/# grep wd0s1a /etc/fstab /dev/wd0s1a / ufs ro 1 1 thithle:/# mount /dev/wd0s1a on / (local, read-only) ... thithle:/# mount -o rwd / thithle:/# mount /dev/wd0s1a on / (local) ... thithle:/# So there are some fairly severe problems with the current behavior of FreeBSD with securelevel in use. Just to sumarize: 1) The set of files installed with schg is not sufficient for any environment where file systems containing binaries are writable by software (i.e., not a CD-ROM or a write-protected floppy). Even though some of the required files are protected, their directories are not protected in the default install. Default installs probably do not benefit from having so many key directories (/usr/lib, /sbin, /etc) be schg, but if securelevels are to be used, it must be published that they cannot just be "turned on" as described in init(8). 2) A read-only mount can be converted into a read-write mount without any prevention of the kernel. With the use of chroot(8), life can be made much harder for the uid 0 user when it comes to modifying key system files. However, through creation of device nodes (which is permitted in securelevel>=2) in mfs partitions, it may be possible to break out and remount / read-write. The current policy for mounting/umounting partitions in high securelevels may not be adequate, given the desire to protect key system directories against attacks over a reboot. 3) Unmentioned above, the init search path in the kernel actual attempts to run a series of possible programs: init_main.c: /* * List of paths to try when searching for "init". */ static char *initpaths[] = { "/sbin/init", "/sbin/oinit", "/sbin/init.bak", "/stand/sysinstall", NULL, }; Even the ability to move /sbin/init out of the way in any form is dangerous -- let alone replacing it. While the kernel is effective at protecting against its securelevel being lowered in the course of a particular boot/running time, FreeBSD is currently extremely succeptible to manipulation of its configuration files and key binaries. Similarly, the possibility of embedding a trojan in any number of standard UNIX utilities (inclding /stand/sysinstall) makes the system entirely untrustworthy even in single-user mode. The promise of schg/securelevels can only be kept if all instances of binaries executed while in a lower securelevel (i.e., in boot and in single-user mode) are protected against execution in lower securelevels (multi-user mode). Recommendations: Reconsider the ability to mount anything but nodev/nosuid partitions under securelevel>=2. Give thought to the issue of readonly mounts, and possibly how to protect against remounting readwrite (especially for /). Perhaps provide a fascistflags utility that makes all key binaries and directories schg. Also, notes indicating that the current securelevel behavior recommended in init(8) is not sufficient. As a side note, it is interesting that make buildworld installs files as schg in the binary tree it builds. This seems highly inappropriate -- the flags should only be set on an installworld! Otherwise make clean will not work on a securelevel>=1 system, so builds cannot be repeated in the same tree without dropping to a lower securelevel to clean the tree. installworld clearly requires a low securelevel, but often build machines are not the same as user machines. I am also interested to know why such an interesting array of commands is schg -- for example, there is no reason why passwd(1) should be schg that I can think of. Either way it aquires root access, or uses NIS. A uid-0 user could easily compile there own. Presumably this is to allow passwords to be changed safely after a penetration; this idea is probably bogus. Incidently, init(8) attempts to lower the securelevel when going out of multi-user mode on a shutdown. It cannot succeed in doing this with the current implementation, as it is not possible to lower the securelevel. However, if it were, we would also be in bad shape -- processes do not necessarily die on the transition to single user mode (if blocked on a resource, for example) -- if init(8) successfully lowered the securelevel, this process would now retain uid 0, but be running in a normal securelevel, allowing it to modify schg files, etc. Since this doesn't work, this is actually OK. init(8) does have some misconceptions, though :-). Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 18:24:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA22948 for freebsd-security-outgoing; Wed, 15 Apr 1998 18:24:45 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA22878 for ; Wed, 15 Apr 1998 18:24:32 -0700 (PDT) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id SAA01318; (8.8.8/RDY) Wed, 15 Apr 1998 18:24:28 -0700 (PDT) Message-Id: <199804160124.SAA01318@burka.rdy.com> Subject: Re: Any news on this?: CA-98.05 Multiple Vulnerabilities in BIND In-Reply-To: <199804160029.SAA10227@infowest.com> from "Aaron D. Gifford" at "Apr 15, 98 06:29:36 pm" To: agifford@infowest.com (Aaron D. Gifford) Date: Wed, 15 Apr 1998 18:24:28 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Aaron D. Gifford writes: > Hello, > > For some reason, it seems that my subscription to freebsd-security@freebsd.org > list stuttered and I haven't seen any messages from about Apr. 8th to the 14th. > I was wondering if anyone during this time mentioned the recent CERT advisory > regarding BIND 4.9 and 8 issued on the 8th. (I've included a copy below.) No, I don't think there were any news on this. The patch for this problem is simple, I'll attach it at the end of this email. However, there are bunch of other problems with current 4.9 version that gonna be fixed in the next release (hopefully). > > Thanks! > > Aaron out. -- dima *** /usr/src/contrib/bind/named/LINK/ns_req.c Tue Jul 1 13:55:47 1997 --- ns_req.c Tue Apr 14 13:47:17 1998 *************** *** 1007,1013 **** switch (type) { case T_A: #ifndef INVQ ! if (!fake_iquery) return (Refuse); #endif #ifdef INVQ --- 1007,1013 ---- switch (type) { case T_A: #ifndef INVQ ! if (!fake_iquery || dlen != INT32SZ) return (Refuse); #endif #ifdef INVQ *************** *** 1021,1027 **** dprintf(1, (ddt, "req: IQuery class %d type %d\n", class, type)); fname = (char *)msg + HFIXEDSZ; ! bcopy(fname, anbuf, alen = (char *)*cpp - fname); data = anbuf + alen - dlen; *cpp = (u_char *)fname; *buflenp -= HFIXEDSZ; --- 1021,1030 ---- dprintf(1, (ddt, "req: IQuery class %d type %d\n", class, type)); fname = (char *)msg + HFIXEDSZ; ! alen = (char *)*cpp - fname; ! if ((size_t)alen > sizeof anbuf) ! return (Refuse); ! bcopy(fname, anbuf, alen); data = anbuf + alen - dlen; *cpp = (u_char *)fname; *buflenp -= HFIXEDSZ; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 19:02:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA29351 for freebsd-security-outgoing; Wed, 15 Apr 1998 19:02:37 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from slug.saturn.net (sj1-p8.telepac.pt [194.65.177.72]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA29301 for ; Wed, 15 Apr 1998 19:02:14 -0700 (PDT) (envelope-from j@bug.fe.up.pt) Received: from localhost (jmg@localhost) by slug.saturn.net (8.8.8/8.8.8) with SMTP id QAA00842; Wed, 15 Apr 1998 16:55:44 +0100 (WEST) (envelope-from j@bug.fe.up.pt) X-Authentication-Warning: slug.saturn.net: jmg owned process doing -bs Date: Wed, 15 Apr 1998 16:55:44 +0100 (WEST) From: freebsd@bug.fe.up.pt X-Sender: jmg@slug.saturn.net To: Paulo Ricardo Trainini cc: freebsd-security@FreeBSD.ORG Subject: Re: table is full (ajude-me por favor) In-Reply-To: <3.0.1.32.19980415101437.00710104@orion.unisc.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id TAA29328 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk I thought that when posting to a FreeBSD mailing list one should write in English, right? The answer to you problem is to increase the MAXUSERS parameter in the kernel. Here is a bit of my kernel configuration: machine "i386" cpu "I586_CPU" ident SLUG maxusers 32 options "NO_F00F_HACK" If your machine has 64 MB of RAM, like mine set MAXUSERS to 32 or even 64 if your server is very loaded. With MAXUSERS set to 32 I can have ( {503} jmg@slug (16:54:01) [~] $ sysctl -a | grep maxfiles ) ( kern.maxfiles: 1064 ) ( kern.maxfilesperproc: 1064 ) 1064 open files. If you need more increase the value and recompile the kernel. Hope this helps. Jorge PS: Se nao percebeu nada diga-me que eu mando a traducao... :) On Wed, 15 Apr 1998, Paulo Ricardo Trainini wrote: > Seguido uma das máquinas da nossa rede reboota sozinha. Ela tem duas > interfaces da rede. O arquivo /var/log/dmesg.today está com várias linhas > de conteúdo "file: table is full". > > O arquivo de configuração do kernel está com "maxusers=10". Não sei se > isto está relacionado. > > Qualquer ajuda é bem vinda. Grato pela atenção. > > Paulo > > > > ----- > Paulo Ricardo Trainini e-mail: trainini@unisc.br > fone: +55 051 717-7424 > Administrador de Rede fax: +55 051 717-1855 > UNISC - Universidade de Santa Cruz do Sul > Setor de Informática > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 20:44:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA17497 for freebsd-security-outgoing; Wed, 15 Apr 1998 20:44:18 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA17318; Wed, 15 Apr 1998 20:43:54 -0700 (PDT) (envelope-from louie@whizzo.TransSys.COM) Received: from whizzo.TransSys.COM (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.8/8.7.3) with ESMTP id XAA06049; Wed, 15 Apr 1998 23:43:25 -0400 (EDT) Message-Id: <199804160343.XAA06049@whizzo.TransSys.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: dima@best.net cc: tsprad@set.spradley.tmi.net (Ted Spradley), trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: kernel permissions References: <199804151949.MAA02749@burka.rdy.com> In-reply-to: Your message of "Wed, 15 Apr 1998 12:49:27 PDT." <199804151949.MAA02749@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Apr 1998 23:43:24 -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Ted Spradley writes: > > > > > > As for the world read permissions: Removing the read permissions seems > > > > like a gratuitious pseudo-security change. Is there any reason to > > > > prevent users from reading the kernel? Presumably, /usr/src/sys is > > > > > > In some case I don't want my users to read a kernel name list. > > > > > > > readable anyhow, so a person could build their own kernel with the same > > > > configuration, so they may as well just copy the running one. > > > > > > You do not always have /usr/src/sys on your machine. Especially > > > on a production enviroment. > > > > You can change the permissions any way you like on your machine. Users who are knowledgeable enough to worry about know where they can find the sources. To me, this is just gratuitous change for the sake of change. > One more time. In some cases you don't want your users to read kernel > namelist. Generic kernel source code won't help. So, chmod 440 /kernel on *your* system. And how many cases are there where other programs installed on the system need to read the kernel namelist? You'll break those by making a change in the distribution. > Another example. Do search on your local box for all the programs, that > don't allow 'others' to read the binary. Ever wonder why? Hmm.. I found exactly 1 - suidperl. This is hardly a compelling argument to change a well established convention. I don't dispute the utility to some for changing the permissions on the /kernel file, but it's just not clear this is a universally good idea. Next thing you know, you'll want to chmod 440 /etc/rc.conf :-) louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 20:57:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA20703 for freebsd-security-outgoing; Wed, 15 Apr 1998 20:57:22 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA20695; Wed, 15 Apr 1998 20:57:18 -0700 (PDT) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id UAA03077; (8.8.8/RDY) Wed, 15 Apr 1998 20:56:35 -0700 (PDT) Message-Id: <199804160356.UAA03077@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: <199804160343.XAA06049@whizzo.TransSys.COM> from "Louis A. Mamakos" at "Apr 15, 98 11:43:24 pm" To: louie@TransSys.COM (Louis A. Mamakos) Date: Wed, 15 Apr 1998 20:56:35 -0700 (PDT) Cc: dima@best.net, tsprad@set.spradley.tmi.net, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Louis A. Mamakos writes: > > > One more time. In some cases you don't want your users to read kernel > > namelist. Generic kernel source code won't help. > > So, chmod 440 /kernel on *your* system. > > And how many cases are there where other programs installed on the system > need to read the kernel namelist? You'll break those by making a change > in the distribution. Every program that needs to have an access to the kernel namelist needs to be sgid to kmem (if it's not already sgid to root). Otherwise it won't be able to do _anything_ with this information. Which means - this change is not going to break anything. > > Another example. Do search on your local box for all the programs, that > > don't allow 'others' to read the binary. Ever wonder why? > > Hmm.. I found exactly 1 - suidperl. This is hardly a compelling argument > to change a well established convention. What about suidperl? > I don't dispute the utility to some for changing the permissions on the > /kernel file, but it's just not clear this is a universally good idea. > Next thing you know, you'll want to chmod 440 /etc/rc.conf :-) Changing permissions on rc.conf won't do _any_ good. > > louie > > > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 21:27:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA28499 for freebsd-security-outgoing; Wed, 15 Apr 1998 21:27:26 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA28327; Wed, 15 Apr 1998 21:27:09 -0700 (PDT) (envelope-from louie@whizzo.TransSys.COM) Received: from whizzo.TransSys.COM (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.8/8.7.3) with ESMTP id AAA06207; Thu, 16 Apr 1998 00:26:56 -0400 (EDT) Message-Id: <199804160426.AAA06207@whizzo.TransSys.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: dima@best.net cc: tsprad@set.spradley.tmi.net, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: kernel permissions References: <199804160356.UAA03077@burka.rdy.com> In-reply-to: Your message of "Wed, 15 Apr 1998 20:56:35 PDT." <199804160356.UAA03077@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Apr 1998 00:26:55 -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Louis A. Mamakos writes: > > > > > One more time. In some cases you don't want your users to read kernel > > > namelist. Generic kernel source code won't help. > > > > So, chmod 440 /kernel on *your* system. > > > > And how many cases are there where other programs installed on the system > > need to read the kernel namelist? You'll break those by making a change > > in the distribution. > > Every program that needs to have an access to the kernel namelist needs to > be sgid to kmem (if it's not already sgid to root). Otherwise it won't be > able to do _anything_ with this information. > > Which means - this change is not going to break anything. By this reasoning, there's no point in removing read permission either. Perhaps I'm looking at the symbols debugging a problem? Or because I'm curious how the kernel was configured, so I do a strings /kernel | egrep '^__' to get the file fed to config(8) and embedded in the file? > > > Another example. Do search on your local box for all the programs, that > > > don't allow 'others' to read the binary. Ever wonder why? > > > > Hmm.. I found exactly 1 - suidperl. This is hardly a compelling argument > > to change a well established convention. > > What about suidperl? Yeah, what about it? A more likely example would have been a program with some password embedded within it. We don't see to have any of those. > > I don't dispute the utility to some for changing the permissions on the > > /kernel file, but it's just not clear this is a universally good idea. > > Next thing you know, you'll want to chmod 440 /etc/rc.conf :-) > > Changing permissions on rc.conf won't do _any_ good. And removing read permission from the kernel does? This all seems like FUD. You seem to have unspecified reasons why you don't want your users to look at the symbols on your kernel. I suggest you remove read permission on your machine. It seems that the potential downside of removing read permission is greater than the unspecified gain of doing so. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 21:42:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA01340 for freebsd-security-outgoing; Wed, 15 Apr 1998 21:42:44 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA01329; Wed, 15 Apr 1998 21:42:37 -0700 (PDT) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id VAA03293; (8.8.8/RDY) Wed, 15 Apr 1998 21:41:56 -0700 (PDT) Message-Id: <199804160441.VAA03293@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: <199804160426.AAA06207@whizzo.TransSys.COM> from "Louis A. Mamakos" at "Apr 16, 98 00:26:55 am" To: louie@TransSys.COM (Louis A. Mamakos) Date: Wed, 15 Apr 1998 21:41:56 -0700 (PDT) Cc: dima@best.net, tsprad@set.spradley.tmi.net, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Louis A. Mamakos writes: > > Louis A. Mamakos writes: > > > > > > > One more time. In some cases you don't want your users to read kernel > > > > namelist. Generic kernel source code won't help. > > > > > > So, chmod 440 /kernel on *your* system. > > > > > > And how many cases are there where other programs installed on the system > > > need to read the kernel namelist? You'll break those by making a change > > > in the distribution. > > > > Every program that needs to have an access to the kernel namelist needs to > > be sgid to kmem (if it's not already sgid to root). Otherwise it won't be > > able to do _anything_ with this information. > > > > Which means - this change is not going to break anything. > > By this reasoning, there's no point in removing read permission either. Of course there is. Because user doesn't need to have this information. > Perhaps I'm looking at the symbols debugging a problem? Or because You must be kidding. You don't have a root access on some machine and you're looking for the kernel debugging information on it??? > I'm curious how the kernel was configured, so I do a > > strings /kernel | egrep '^__' > > to get the file fed to config(8) and embedded in the file? Ask sysadmin. > > > > Another example. Do search on your local box for all the programs, that > > > > don't allow 'others' to read the binary. Ever wonder why? > > > > > > Hmm.. I found exactly 1 - suidperl. This is hardly a compelling argument > > > to change a well established convention. > > > > What about suidperl? > > Yeah, what about it? A more likely example would have been a program > with some password embedded within it. We don't see to have any of > those. Ahh, that's what you've meant. I thought, you were saying that 0440 permissions on kernel will break suidperl. > > > I don't dispute the utility to some for changing the permissions on the > > > /kernel file, but it's just not clear this is a universally good idea. > > > Next thing you know, you'll want to chmod 440 /etc/rc.conf :-) > > > > Changing permissions on rc.conf won't do _any_ good. > > And removing read permission from the kernel does? > > This all seems like FUD. You seem to have unspecified reasons why > you don't want your users to look at the symbols on your kernel. I > suggest you remove read permission on your machine. It seems that the > potential downside of removing read permission is greater than the > unspecified gain of doing so. There's no potential downside. Or you can call having a root password a potential downside, because qurious user won't be able to see your configuration. > > > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 22:01:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04374 for freebsd-security-outgoing; Wed, 15 Apr 1998 22:01:05 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from set.spradley.tmi.net (set.spradley.tmi.net [207.170.107.99]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA04338; Wed, 15 Apr 1998 22:00:57 -0700 (PDT) (envelope-from tsprad@set.spradley.tmi.net) Received: from localhost (set.spradley.tmi.net) [127.0.0.1] by set.spradley.tmi.net with esmtp (Exim 1.82 #2) id 0yPgmY-0004v7-00; Thu, 16 Apr 1998 00:00:18 -0500 X-Mailer: exmh version 2.0zeta 7/24/97 To: dima@best.net cc: louie@TransSys.COM (Louis A. Mamakos), trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Wed, 15 Apr 1998 21:41:56 PDT." <199804160441.VAA03293@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Apr 1998 00:00:17 -0500 From: Ted Spradley Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > By this reasoning, there's no point in removing read permission either. > > Of course there is. Because user doesn't need to have this information. Is this what your argument boils down to -- *Your* users don't have a 'Need to Know' (to use the Pentagon expression). Maybe I prefer to encourage my users to learn as much as they will about the system. Maybe I take a very negative attitude about keeping any information secret, so I consider long and hard before I remove read permission for anybody from any information. Maybe that's why I use a system that has freely available source code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 22:12:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA07476 for freebsd-security-outgoing; Wed, 15 Apr 1998 22:12:04 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA07357; Wed, 15 Apr 1998 22:11:54 -0700 (PDT) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id WAA03453; (8.8.8/RDY) Wed, 15 Apr 1998 22:11:29 -0700 (PDT) Message-Id: <199804160511.WAA03453@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: from Ted Spradley at "Apr 16, 98 00:00:17 am" To: tsprad@set.spradley.tmi.net (Ted Spradley) Date: Wed, 15 Apr 1998 22:11:28 -0700 (PDT) Cc: dima@best.net, louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Ted Spradley writes: > > > > By this reasoning, there's no point in removing read permission either. > > > > Of course there is. Because user doesn't need to have this information. > > Is this what your argument boils down to -- *Your* users don't have a > 'Need to Know' (to use the Pentagon expression). Maybe I prefer to > encourage my users to learn as much as they will about the system. Maybe > I take a very negative attitude about keeping any information secret, so > I consider long and hard before I remove read permission for anybody from > any information. Maybe that's why I use a system that has freely > available source code. Okay. Here's an example. Ever hear of a commertially available drivers? When you install such stuff, you don't want somebody to be able to read them, or have a copy of kernel with them. Why? Because you did pay for them and whoever wants to have an access - didnt. Normal users *do not need* to have an read acces to the kernel. They simply don't. Do you need any other examples? What's the deal with arguing on such a simply issue? > > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 22:59:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA17437 for freebsd-security-outgoing; Wed, 15 Apr 1998 22:59:28 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from set.spradley.tmi.net (set.spradley.tmi.net [207.170.107.99]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA17356; Wed, 15 Apr 1998 22:59:17 -0700 (PDT) (envelope-from tsprad@set.spradley.tmi.net) Received: from localhost (set.spradley.tmi.net) [127.0.0.1] by set.spradley.tmi.net with esmtp (Exim 1.82 #2) id 0yPhhO-0004yk-00; Thu, 16 Apr 1998 00:59:02 -0500 X-Mailer: exmh version 2.0zeta 7/24/97 To: dima@best.net cc: louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Wed, 15 Apr 1998 22:11:28 PDT." <199804160511.WAA03453@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Apr 1998 00:59:01 -0500 From: Ted Spradley Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Normal users *do not need* to have an read acces to the kernel. > They simply don't. Normal usersdo not need *not* to have read access to the kernel. If it ain't broke, don't fix it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 15 23:09:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA20543 for freebsd-security-outgoing; Wed, 15 Apr 1998 23:09:11 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA20505; Wed, 15 Apr 1998 23:08:48 -0700 (PDT) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id XAA03735; (8.8.8/RDY) Wed, 15 Apr 1998 23:08:39 -0700 (PDT) Message-Id: <199804160608.XAA03735@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: from Ted Spradley at "Apr 16, 98 00:59:01 am" To: tsprad@set.spradley.tmi.net (Ted Spradley) Date: Wed, 15 Apr 1998 23:08:39 -0700 (PDT) Cc: dima@best.net, louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Ted Spradley writes: > > > Normal users *do not need* to have an read acces to the kernel. > > They simply don't. > > Normal usersdo not need *not* to have read access to the kernel. If it > ain't broke, don't fix it. I've already gave you an example why it shouldn't be like this. > > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 01:14:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA13782 for freebsd-security-outgoing; Thu, 16 Apr 1998 01:14:59 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA13776 for ; Thu, 16 Apr 1998 01:14:55 -0700 (PDT) (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id MAA20467; Thu, 16 Apr 1998 12:10:30 +0200 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id KAA15305; Thu, 16 Apr 1998 10:32:27 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id KAA20461; Thu, 16 Apr 1998 10:13:31 +0200 (CEST) Message-ID: <19980416101330.18307@deepo.prosa.dk> Date: Thu, 16 Apr 1998 10:13:30 +0200 From: Philippe Regnauld To: dima@best.net Cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions References: <199804160511.WAA03453@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: <199804160511.WAA03453@burka.rdy.com>; from Dima Ruban on Wed, Apr 15, 1998 at 10:11:28PM -0700 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [Cc: trimmed to a politically correct size] Dima Ruban writes: [...] > Okay. Here's an example. Ever hear of a commertially available drivers? > When you install such stuff, you don't want somebody to be able to read > them, or have a copy of kernel with them. Why? Because you did pay for them > and whoever wants to have an access - didnt. Commercially available drivers are shiiped in object format. There's very little chance it's exploitable straight out of the kernel -- nothing like the sources to said driver. > Normal users *do not need* to have an read acces to the kernel. > They simply don't. I just remember the same discussion, oh about two years ago, and IIRC, the general idea (from core) was that it was unnecessary to remove read/exec bits on a file without a strong motivation -- the reason being, as mentioned earlier, that "we were not your average commercial UNIX entity" and didn't share the "Pentagon" approach. BUT, things may have changed in the meantime: 1) The Jerk/Hacker ratio has unfortunately increased these last years 2) FreeBSD is increasingly known as an ISP platform ("reliability, security, efficiency", pick _three_) -- Thus, removing the read bits on the kernel MIGHT make sense for the out-of-the-box configuration that Mr.ISP will be using, if for some God-obscure reason he wishes to have shell accounts on his machine. Then again, we are (hopefully) all grown up enough to make our own security policy, _including_ writing shell scripts that once-and-for-all do the appropriate changes on *our* system. I also remember an argument being, "Ah, we don't want to start doing like the Linux people who set everything they can to 440" :-) > Do you need any other examples? Yes: Preventing things in the eventual (unproven) fear that they could be exploited in some way (not necessarily security) is, IMHO, "change for the sake of change". If you can prove me wrong regarding the "commercially available" driver mentioned above, I'll shut up :-) > What's the deal with arguing on such a simply issue? Oh, BSD conservatism, cast-in-stone code, superstition and old grumpy hackers ? -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle, ("MYTHOLOGY", in Marutukku distrib) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 01:44:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA17400 for freebsd-security-outgoing; Thu, 16 Apr 1998 01:44:08 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from huset.math.ntnu.no (huset.math.ntnu.no [129.241.211.212]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA17349 for ; Thu, 16 Apr 1998 01:43:56 -0700 (PDT) (envelope-from arnej@stud.math.ntnu.no) Message-Id: <199804160843.BAA17349@hub.freebsd.org> Received: (qmail 28851 invoked from network); 16 Apr 1998 08:43:53 -0000 Received: from huset.math.ntnu.no (HELO stud.math.ntnu.no) (129.241.211.212) by huset.math.ntnu.no with SMTP; 16 Apr 1998 08:43:53 -0000 To: dima@best.net Cc: tsprad@set.spradley.tmi.net, louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: Your message of "Wed, 15 Apr 1998 23:08:39 -0700 (PDT)" References: <199804160608.XAA03735@burka.rdy.com> X-Mailer: Mew version 1.54 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 16 Apr 1998 10:43:53 +0200 From: Arne Henrik Juul Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Dima Ruban wrote: > Ted Spradley writes: > > Normal usersdo not need *not* to have read access to the kernel. If it > > ain't broke, don't fix it. > > I've already gave you an example why it shouldn't be like this. Your argument was not very compelling - you can't say that most, or even many, FreeBSD machines have commercial drivers, much less that the have such drivers with so draconian license agreements that you're not even allowed to have the in-kernel object code readable for normal users. (For what it's worth, I've never heard about such a license agreement, ever, for any piece of software). On my machines, I'm mostly logged in as myself, not as root. I think this is a good practice and I'll keep on doing that. I don't *want* to have any special privileges on my normal user, and what's more, I *want* my students to be able to peek around in the system as much as possible, also on the machines where they can't be allowed to have the root password. I *don't* want to have to su root just to do normal things that shouldn't need root access. I've been inconvenienced by stupid programs being installed without read access for normal users, many times through the years. (I do sysadmin work on a large number of machines with various OS'es.) I think that if *you* want a read-protected kernel (for reasons that applies to a very small subset of FreeBSD users), *you* should write a config file for mtree that actually helps security, and apply it on *your* machine. I mean, what's the point of read-protecting the kernel in / without doing the same to /var/db/kvm_kernel.db? Logically, it's much more important to protect sendmail to be unreadable, and modify it so it won't tell its version number to normal users. Or implementing the policy that no setuid programs should be readable for users, since that allows them to inspect the object code for buffer overruns and such. (Assuming the prospective hacker isn't smart enough to go look at the sources to simplify the task :-) So please, implement whatever policy you want on *your* machine! - Arne H. Juul senior engineer, Department of Mathematical Sciences, Norwegian University of Science and Technology. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 04:20:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA12419 for freebsd-security-outgoing; Thu, 16 Apr 1998 04:20:24 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA12408; Thu, 16 Apr 1998 04:20:19 -0700 (PDT) (envelope-from tweten@ns.frihet.com) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.8.8/8.8.8) with ESMTP id EAA24061; Thu, 16 Apr 1998 04:19:58 -0700 (PDT) (envelope-from tweten@ns.frihet.com) Message-Id: <199804161119.EAA24061@ns.frihet.com> X-Mailer: exmh version 2.0.2 2/24/98 Reply-to: tweten@frihet.com To: dima@best.net Cc: tsprad@set.spradley.tmi.net (Ted Spradley), louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions From: "David E. Tweten" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Apr 1998 04:19:58 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk dima@best.net said: >Normal users *do not need* to have an read acces to the kernel. >They simply don't. I'm sorry, but this one finally pinched my corn. System administrators who believe users must prove that they need a service or resource before they will be permitted access to it have always annoyed me. When they get the upper hand, such administrators destroy user productivity by forcing the more numerous class of "users" to waste time proving when they should be using. When I have the opportunity, I try to challenge such *administrators* to prove that no users have a need before clamping down. "Prove to my you need it" is not the Unix way as I understand it. To quote from the forward of the original Bell System Technical Journal introducing Unix [volume 57, number 6, part 2], "He [Ken Thompson] and the others who soon joined him had one overriding objective: to create a computing environment where they themselves could comfortably and effectively pursue their own work ..." What resulted was a system that presumed openness, and restricted users only when there was a compelling need to do so. So, my challenge to you is, "Show me how the current kernel permissions can be used to crack FreeBSD." If you can't, please don't restrict them. If you must, please put mention of this change on a readme file list of gratuitous restrictions, so I can remove it from my systems without losing too much sleep over why it was there in the first place. -- David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 06:46:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA06503 for freebsd-security-outgoing; Thu, 16 Apr 1998 06:46:38 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from nyef.res.cmu.edu (qmailr@NYEF.RES.CMU.EDU [128.2.88.90]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA06467 for ; Thu, 16 Apr 1998 06:46:26 -0700 (PDT) (envelope-from inf@nyef.res.cmu.edu) Received: (qmail 20674 invoked by uid 1000); 16 Apr 1998 13:39:16 -0000 Message-ID: <19980416093916.41527@nyef.res.cmu.edu> Date: Thu, 16 Apr 1998 09:39:16 -0400 From: Marca Registrada To: FreeBSD-Security@FreeBSD.ORG, FreeBSD-Stable@FreeBSD.ORG Subject: Re: kernel permissions Mail-Followup-To: FreeBSD-Security@freebsd.org, FreeBSD-Stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199804160511.WAA03453@burka.rdy.com>; from Dima Ruban on Wed, Apr 15, 1998 at 10:11:28PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Quoting Dima Ruban (dima@best.net): > Okay. Here's an example. Ever hear of a commertially available drivers? > When you install such stuff, you don't want somebody to be able to read > them, or have a copy of kernel with them. Why? Because you did pay for them > and whoever wants to have an access - didnt. That would seem to be the exception rather than the norm. While I dont' debate why _some_ people would want a 440 kernel it feels like the security argument hasn't been filled, and otherwise, its creates the ever bit more presense of 'hostility' towards the user, and in this case, an unfounded one. I've actually had friends logged into my system 'borrow' my kernel config for their own system, make comments "Hrmm, so how's devfs working for you?" and do the same throughout most of my system, being that I'm the local "FreeBSD guru" who has converted people around him and (unknowningly?) took on the obligation to help. I've always been one for 'conf' options, so might I suggest this be a thing for 'config' to handle or a make.conf option? As a matter of fact, I was very happy that sendmail became a make.conf option, seeing as I use qmail and nearly ALWAYS forgot to replace sendmail after a make world. I think many such obvious policy issues should be configurable, with the predominant view the default. --- make.conf --- # To compile just the kernel with special optimisations, you should use # this instead of CFLAGS (which is not applicable to kernel builds anyway): # COPTFLAGS= -O2 -pipe KERNEL_OWNER root.kmem KERNEL_PERMS 444 #KERNEL_PERMS 440 ... Possibly in a more stylistically suitable format? -- - All we hear is internet gaagaa, internet googoo, internet gaagaa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 09:42:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12841 for freebsd-security-outgoing; Thu, 16 Apr 1998 09:42:26 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (root@ts01-13.waterford.indigo.ie [194.125.139.76]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA12827 for ; Thu, 16 Apr 1998 16:42:19 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id PAA02651; Thu, 16 Apr 1998 15:29:32 +0100 (IST) (envelope-from rotel@ginseng.indigo.ie) From: Niall Smart Message-Id: <199804161429.PAA02651@indigo.ie> Date: Thu, 16 Apr 1998 15:29:32 +0000 In-Reply-To: Robert Watson "securelevels and more liberal use of schg on system files (fwd)" (Apr 15, 9:01pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: securelevels and more liberal use of schg on system files (fwd) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 15, 9:01pm, Robert Watson wrote: } Subject: securelevels and more liberal use of schg on system files (fwd) > BSD/OS and others make use of securelevels in their production releases to > prevent time rewinds, etc. It may be desirable that FreeBSD do so in the > future. Currently, however, securelevels do little if anything to > actually increase the security of a system. I think this can be improved > through some careful thinking out of the issues, and would like to see > this happen in FreeBSD. :) All experimentation was performed on > 2.2-STABLE a few days ago. I agree that we aren't making enough of this feature. Securelevels are important in that for the average user who leaves the system at level -1 they will not affect him in any way, yet if he decides to bump the level up to 1 or 2 they can play an important role in enforcing the system security policy. To put this another way: any changes made to the securelevel system won't affect the majority of users out there who are running at level -1, so we can safely tighten up the policy without fear of making the system less convenient for the ordinary joe soap. [...] > Note that it is not init(8) itself that performs the sysctl activity, but > rather the rc(8) script. In a sense, it cannot be init(8), as the rc(8) > script later runs fsck(8) to clean the file systems, and it requires write > access to the block devices. However, this does leave us with a few > problems. Neither /etc/rc nor /usr/sbin/sysctl are protected by schg. > For that matter, neither is fsck, or any number of utilities used by rc(8) > prior to being able to raise the securelevel. While some of the above Good point. [...] > Additionally, while we notice that the files are protected against > modification (and links to them), the directories are *NOT*. /sbin/init > is schg, but the directory /sbin is not! Similarly with all of the other [...] > So there are some fairly severe problems with the current behavior of > FreeBSD with securelevel in use. Just to sumarize: > > 1) The set of files installed with schg is not sufficient for any > environment where file systems containing binaries are writable by > software (i.e., not a CD-ROM or a write-protected floppy). Even though > some of the required files are protected, their directories are not > protected in the default install. Default installs probably do not > benefit from having so many key directories (/usr/lib, /sbin, /etc) be > schg, but if securelevels are to be used, it must be published that they > cannot just be "turned on" as described in init(8). The default protections applied by make installworld seem to be rather half hearted alright. :) Anyone planning to run with securelevel >0 with the current install script would be well advised to supplement them. It would be very nice to see someone think through which binaries need to be protected as part of an overall brainstorming session about making securelevels useful. There are problems other than with file flags though, in particular there are many binaries with sgid kmem or suid root bits that really don't them. For example, ccdconfig(1), timedc(1). I don't know of any problems with these utilities, it's just that I am very reluctant to give a s[ug]id bit to a utility unless it absolutely needs it. I think this reluctance is justified by the problem which I found in ccdconfig and pointed out on BUGTRAQ some months ago. > 2) A read-only mount can be converted into a read-write mount without any > prevention of the kernel. With the use of chroot(8), life can be made > much harder for the uid 0 user when it comes to modifying key system > files. However, through creation of device nodes (which is permitted in > securelevel>=2) in mfs partitions, it may be possible to break out and > remount / read-write. The current policy for mounting/umounting > partitions in high securelevels may not be adequate, given the desire to > protect key system directories against attacks over a reboot. Yes, I think the ability to prevent mount -u rw on a ro fs is good too. > 3) Unmentioned above, the init search path in the kernel actual attempts > to run a series of possible programs: This shouldn't be a problem if the /sbin directory is tied down, should it? [...] > I am also interested to know why such an interesting array of commands is > schg -- for example, there is no reason why passwd(1) should be schg that > I can think of. Either way it aquires root access, or uses NIS. A uid-0 > user could easily compile there own. Presumably this is to allow > passwords to be changed safely after a penetration; this idea is probably > bogus. Perhaps the original intention was to prevent an intruder installing a bogus passwd utility allowing them to covertly monitor password changes on the system, thus gaining access to new systems. This would also explain the schg flags on login. Regards, Niall > Robert N Watson > Carnegie Mellon University http://www.cmu.edu/ > Trusted Information Systems http://www.tis.com/ > SafePort Network Services http://www.safeport.com/ > robert@fledge.watson.org http://www.watson.org/~robert/ -- Niall Smart. finger njs3@doc.ic.ac.uk for PGP key FreeBSD: Turning PC's into Workstations. www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 09:42:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12962 for freebsd-security-outgoing; Thu, 16 Apr 1998 09:42:55 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (root@ts01-13.waterford.indigo.ie [194.125.139.76]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA12937 for ; Thu, 16 Apr 1998 16:42:42 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id OAA02264; Thu, 16 Apr 1998 14:28:09 +0100 (IST) (envelope-from rotel@ginseng.indigo.ie) From: Niall Smart Message-Id: <199804161328.OAA02264@indigo.ie> Date: Thu, 16 Apr 1998 14:28:09 +0000 In-Reply-To: Philippe Regnauld "Re: kernel permissions" (Apr 16, 10:13am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Philippe Regnauld , dima@best.net Subject: Re: kernel permissions Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 16, 10:13am, Philippe Regnauld wrote: } Subject: Re: kernel permissions > Preventing things in the eventual (unproven) fear that > they could be exploited in some way (not necessarily > security) is, IMHO, "change for the sake of change". I'd call this "prudence". I'd call chmod 440 /kernel "over-prudence" though. :) Niall -- Niall Smart. finger njs3@doc.ic.ac.uk for PGP key FreeBSD: Turning PC's into Workstations. www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 10:34:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA24065 for freebsd-security-outgoing; Thu, 16 Apr 1998 10:34:24 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA24021 for ; Thu, 16 Apr 1998 17:34:12 GMT (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id NAA06347; Thu, 16 Apr 1998 13:34:06 -0400 (EDT) (envelope-from wollman) Date: Thu, 16 Apr 1998 13:34:06 -0400 (EDT) From: Garrett Wollman Message-Id: <199804161734.NAA06347@khavrinen.lcs.mit.edu> To: rotel@indigo.ie Cc: Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: securelevels and more liberal use of schg on system files (fwd) In-Reply-To: <199804161429.PAA02651@indigo.ie> References: <199804161429.PAA02651@indigo.ie> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk < said: > The default protections applied by make installworld seem to be > rather half hearted alright. :) Anyone planning to run with > securelevel >0 with the current install script would be well advised > to supplement them. It would be very nice to see someone think > through which binaries need to be protected as part of an overall > brainstorming session about making securelevels useful. My secure system runs with all major system directories append-only. In order for an attacker to replace an important program, he would first have to delete it (since he can't open it for write), which sappnd prevents. It also has a very restricted set of network services: anon ftp, Web cache, eklogin, and CVSup mirror---that's it. (Well, you can probably finger it, too.) -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 security" in the body of the message From owner-freebsd-security Thu Apr 16 13:44:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA26642 for freebsd-security-outgoing; Thu, 16 Apr 1998 13:44:39 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26557 for ; Thu, 16 Apr 1998 20:44:27 GMT (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 QAA14229; Thu, 16 Apr 1998 16:43:36 -0400 (EDT) Date: Thu, 16 Apr 1998 16:43:36 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Niall Smart cc: Philippe Regnauld , dima@best.net, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <199804161328.OAA02264@indigo.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Thu, 16 Apr 1998, Niall Smart wrote: > On Apr 16, 10:13am, Philippe Regnauld wrote: > } Subject: Re: kernel permissions > > > Preventing things in the eventual (unproven) fear that > > they could be exploited in some way (not necessarily > > security) is, IMHO, "change for the sake of change". > > I'd call this "prudence". I'd call chmod 440 /kernel "over-prudence" > though. :) So, one possible concern might be for US residents that with developed IPsec code in ones kernel (including encryption), ones kernel might no longer be exportable :). We wouldn't want our users grabbing the kernel code to run on their own machine :). (I know, a stretch, but...) Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 13:59:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA00491 for freebsd-security-outgoing; Thu, 16 Apr 1998 13:59:32 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA00419 for ; Thu, 16 Apr 1998 20:58:49 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id NAA09128; (8.8.8/RDY) Thu, 16 Apr 1998 13:58:26 -0700 (PDT) Message-Id: <199804162058.NAA09128@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: from Robert Watson at "Apr 16, 98 04:43:36 pm" To: robert+freebsd@cyrus.watson.org Date: Thu, 16 Apr 1998 13:58:25 -0700 (PDT) Cc: rotel@indigo.ie, regnauld@deepo.prosa.dk, dima@best.net, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Robert Watson writes: > So, one possible concern might be for US residents that with developed > IPsec code in ones kernel (including encryption), ones kernel might no > longer be exportable :). We wouldn't want our users grabbing the kernel > code to run on their own machine :). > > (I know, a stretch, but...) Heh. Right. > > Robert N Watson > > > ---- > Carnegie Mellon University http://www.cmu.edu/ > Trusted Information Systems http://www.tis.com/ > SafePort Network Services http://www.safeport.com/ > robert@fledge.watson.org http://www.watson.org/~robert/ > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 14:07:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA02869 for freebsd-security-outgoing; Thu, 16 Apr 1998 14:07:13 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA02819; Thu, 16 Apr 1998 21:06:57 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id OAA09190; (8.8.8/RDY) Thu, 16 Apr 1998 14:06:30 -0700 (PDT) Message-Id: <199804162106.OAA09190@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: <199804161119.EAA24061@ns.frihet.com> from "David E. Tweten" at "Apr 16, 98 04:19:58 am" To: tweten@frihet.com Date: Thu, 16 Apr 1998 14:06:30 -0700 (PDT) Cc: dima@best.net, tsprad@set.spradley.tmi.net, louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 David E. Tweten writes: > dima@best.net said: > >Normal users *do not need* to have an read acces to the kernel. > >They simply don't. > > I'm sorry, but this one finally pinched my corn. System administrators who > believe users must prove that they need a service or resource before they > will be permitted access to it have always annoyed me. When they get the > upper hand, such administrators destroy user productivity by forcing the more > numerous class of "users" to waste time proving when they should be using. > When I have the opportunity, I try to challenge such *administrators* to > prove that no users have a need before clamping down. Excuse me? What are they (users) going to do with kernel name list besides attempting to hack your machine? They can't really use it anyway. > "Prove to my you need it" is not the Unix way as I understand it. To quote > from the forward of the original Bell System Technical Journal introducing > Unix [volume 57, number 6, part 2], "He [Ken Thompson] and the others who > soon joined him had one overriding objective: to create a computing > environment where they themselves could comfortably and effectively pursue > their own work ..." What resulted was a system that presumed openness, and > restricted users only when there was a compelling need to do so. > > So, my challenge to you is, "Show me how the current kernel permissions can > be used to crack FreeBSD." If you can't, please don't restrict them. If you This is totally wrong. If we will be closing only a security *holes*, we won't go anywhere. Thre's such a thing called *potential* problem. This one was one of potential problems as well. > must, please put mention of this change on a readme file list of gratuitous > restrictions, so I can remove it from my systems without losing too much > sleep over why it was there in the first place. > -- > David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com > 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com > Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 > Those who make good products sell products; those who don't, sell solutions. > > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 15:22:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25988 for freebsd-security-outgoing; Thu, 16 Apr 1998 15:22:50 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from set.spradley.tmi.net (set.spradley.tmi.net [207.170.107.99]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA25943; Thu, 16 Apr 1998 22:22:12 GMT (envelope-from tsprad@set.spradley.tmi.net) Received: from localhost (set.spradley.tmi.net) [127.0.0.1] by set.spradley.tmi.net with esmtp (Exim 1.82 #2) id 0yPx1m-0005qz-00; Thu, 16 Apr 1998 17:21:06 -0500 X-Mailer: exmh version 2.0zeta 7/24/97 To: dima@best.net cc: tweten@frihet.com, louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Thu, 16 Apr 1998 14:06:30 PDT." <199804162106.OAA09190@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Apr 1998 17:21:06 -0500 From: Ted Spradley Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > David E. Tweten writes: > > dima@best.net said: > > >Normal users *do not need* to have an read acces to the kernel. > > >They simply don't. > > > > I'm sorry, but this one finally pinched my corn. System administrators who > > believe users must prove that they need a service or resource before they > > will be permitted access to it have always annoyed me. When they get the > > upper hand, such administrators destroy user productivity by forcing the more > > numerous class of "users" to waste time proving when they should be using. > > When I have the opportunity, I try to challenge such *administrators* to > > prove that no users have a need before clamping down. > > Excuse me? What are they (users) going to do with kernel name list > besides attempting to hack your machine? No, you've missed Mr. Tweten's point. You don't get to ask. *You* have to prove that there's *nothing* else they could get from reading the kernel. Furthermore, it's not obvious to me what they could get from reading it that would allow them to "hack your machine". > They can't really use it anyway. It would be a nuisance to me if I had to su root to do the "strings /kernel | grep '^___' " thing. If you have such an adversarial relationship with these 'users' then by all means, change your file permissions on your system any way you like, but don't impose your changes on the rest of us. BTW, you can make your system more secure by disconnecting the network cable, and even more secure by disconnecting the power cable. > > "Prove to my you need it" is not the Unix way as I understand it. To quote > > from the forward of the original Bell System Technical Journal introducing > > Unix [volume 57, number 6, part 2], "He [Ken Thompson] and the others who > > soon joined him had one overriding objective: to create a computing > > environment where they themselves could comfortably and effectively pursue > > their own work ..." What resulted was a system that presumed openness, and > > restricted users only when there was a compelling need to do so. > > > > So, my challenge to you is, "Show me how the current kernel permissions can > > be used to crack FreeBSD." If you can't, please don't restrict them. If you > > This is totally wrong. If we will be closing only a security *holes*, > we won't go anywhere. Thre's such a thing called *potential* problem. > This one was one of potential problems as well. > > > must, please put mention of this change on a readme file list of gratuitous > > restrictions, so I can remove it from my systems without losing too much > > sleep over why it was there in the first place. > > -- > > David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com > > 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com > > Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 > > Those who make good products sell products; those who don't, sell solutions. > > > > > > -- dima > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 16:08:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06639 for freebsd-security-outgoing; Thu, 16 Apr 1998 16:08:04 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA06555; Thu, 16 Apr 1998 23:07:29 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id QAA10457; (8.8.8/RDY) Thu, 16 Apr 1998 16:07:11 -0700 (PDT) Message-Id: <199804162307.QAA10457@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: from Ted Spradley at "Apr 16, 98 05:21:06 pm" To: tsprad@set.spradley.tmi.net (Ted Spradley) Date: Thu, 16 Apr 1998 16:07:11 -0700 (PDT) Cc: dima@best.net, tweten@frihet.com, louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Ted Spradley writes: > > Excuse me? What are they (users) going to do with kernel name list > > besides attempting to hack your machine? > > No, you've missed Mr. Tweten's point. You don't get to ask. *You* have > to prove that there's *nothing* else they could get from reading the > kernel. How can I prove that there's nothing else they can get from reading my kernel, if I'm trying to prove opposite? > Furthermore, it's not obvious to me what they could get from reading it > that would allow them to "hack your machine". For example, some time ago it would have been possible to read N bytes from the terminal buffer under SunOS with ``netstat'' command if you happen to have an access to the kernel namelist. > > They can't really use it anyway. > > It would be a nuisance to me if I had to su root to do the "strings > /kernel | grep '^___' " thing. How often do you do that? > If you have such an adversarial relationship with these 'users' then by > all means, change your file permissions on your system any way you like, > but don't impose your changes on the rest of us. > > BTW, you can make your system more secure by disconnecting the network > cable, and even more secure by disconnecting the power cable. Smart suggestion indeed. > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 16:08:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06849 for freebsd-security-outgoing; Thu, 16 Apr 1998 16:08:35 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA06733; Thu, 16 Apr 1998 23:08:13 GMT (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.8/8.8.8) id BAA15315; Fri, 17 Apr 1998 01:02:22 +0200 (CEST) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199804162302.BAA15315@ocean.campus.luth.se> Subject: Re: kernel permissions In-Reply-To: from Ted Spradley at "Apr 16, 98 05:21:06 pm" To: tsprad@set.spradley.tmi.net (Ted Spradley) Date: Fri, 17 Apr 1998 01:02:22 +0200 (CEST) Cc: stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk According to Ted Spradley: > > Excuse me? What are they (users) going to do with kernel name list > > besides attempting to hack your machine? > > No, you've missed Mr. Tweten's point. You don't get to ask. *You* have > to prove that there's *nothing* else they could get from reading the > kernel. > > Furthermore, it's not obvious to me what they could get from reading it > that would allow them to "hack your machine". > > > They can't really use it anyway. > > It would be a nuisance to me if I had to su root to do the "strings > /kernel | grep '^___' " thing. You don't have to, just chmod it once. Quite frankly, why don't you all spend your energys doing something sane instead of going on and on about this? And I have to agree with Dima, the more secure the better. Wanna hear a reall good argument? It's easy to forget to frob all the 1000 small knobs that "you can frob on YOUR machine if you want it secure". It's however quite easy to remember to chmod it when you or one of your users gets annoyed at not being able to read it. It annoys you the first time, but you su, chmod, and exit. Nothing more to it. You simply will not forget to, because it will not let you. I definitely don't mind a change that doesn't affect any programs negatively, if it has a chance of making the system at least a bit more secure. /Mikael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 16:21:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11218 for freebsd-security-outgoing; Thu, 16 Apr 1998 16:21:37 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA10976 for ; Thu, 16 Apr 1998 23:20:55 GMT (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id QAA26329; Thu, 16 Apr 1998 16:20:10 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id QAA20464; Thu, 16 Apr 1998 16:20:08 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA00669; Thu, 16 Apr 1998 16:20:06 -0700 (PDT) From: Don Lewis Message-Id: <199804162320.QAA00669@salsa.gv.tsc.tdk.com> Date: Thu, 16 Apr 1998 16:20:06 -0700 In-Reply-To: Niall Smart "Re: securelevels and more liberal use of schg on system files (fwd)" (Apr 16, 3:29pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: rotel@indigo.ie, Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: securelevels and more liberal use of schg on system files (fwd) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 16, 3:29pm, Niall Smart wrote: } Subject: Re: securelevels and more liberal use of schg on system files (fw } The default protections applied by make installworld seem to be } rather half hearted alright. :) Well that's bettern than if you install a release from CD or across the net, because in that situation, nothing gets the schg bit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 19:37:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA23507 for freebsd-security-outgoing; Thu, 16 Apr 1998 19:37:52 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from set.spradley.tmi.net (set.spradley.tmi.net [207.170.107.99]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA23286; Fri, 17 Apr 1998 02:36:48 GMT (envelope-from tsprad@set.spradley.tmi.net) Received: from localhost (set.spradley.tmi.net) [127.0.0.1] by set.spradley.tmi.net with esmtp (Exim 1.82 #2) id 0yQ0zz-000653-00; Thu, 16 Apr 1998 21:35:31 -0500 X-Mailer: exmh version 2.0zeta 7/24/97 To: dima@best.net cc: tweten@frihet.com, louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Thu, 16 Apr 1998 16:07:11 PDT." <199804162307.QAA10457@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Apr 1998 21:35:31 -0500 From: Ted Spradley Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Ted Spradley writes: > > > Excuse me? What are they (users) going to do with kernel name list > > > besides attempting to hack your machine? > > > > No, you've missed Mr. Tweten's point. You don't get to ask. *You* have > > to prove that there's *nothing* else they could get from reading the > > kernel. > > How can I prove that there's nothing else they can get from reading my kernel, > if I'm trying to prove opposite? You have to prove that there is nothing else besides attempting to hack your machine that these users could possibly get from reading the kernel. That is, you have to prove your assertion that there is nothing useful that users could get from reading the kernel. I just wanted to clarify my wording. I've had quite enough of this subject. We've already wasted far more effort on the discussion than I was attempting to save by preventing a gratuitous change. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 20:40:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA04831 for freebsd-security-outgoing; Thu, 16 Apr 1998 20:40:52 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA04797; Fri, 17 Apr 1998 03:40:37 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id UAA12029; (8.8.8/RDY) Thu, 16 Apr 1998 20:40:22 -0700 (PDT) Message-Id: <199804170340.UAA12029@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: from Ted Spradley at "Apr 16, 98 09:35:31 pm" To: tsprad@set.spradley.tmi.net (Ted Spradley) Date: Thu, 16 Apr 1998 20:40:22 -0700 (PDT) Cc: dima@best.net, tweten@frihet.com, louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Ted Spradley writes: > > Ted Spradley writes: > > > > Excuse me? What are they (users) going to do with kernel name list > > > > besides attempting to hack your machine? > > > > > > No, you've missed Mr. Tweten's point. You don't get to ask. *You* have > > > to prove that there's *nothing* else they could get from reading the > > > kernel. > > > > How can I prove that there's nothing else they can get from reading my kernel, > > if I'm trying to prove opposite? > > You have to prove that there is nothing else besides attempting to hack > your machine that these users could possibly get from reading the kernel. > That is, you have to prove your assertion that there is nothing useful > that users could get from reading the kernel. Ahh, sorry. It was probably problem with my English. Okay. What can user get from being able to read kernel. 1. Debugging symbols and symbol table - user doesn't need that. 2. Possible kernel configuration - questionable. 3. Kernel namelist - user doesn't need that. 4. Kernel copy with possible commercial stuff - user doesn't need that. 5. Kernel copy with possible restricted/crypto - user doesn't need that. stuff. I believe, this is about it, or at least I can't think of anything else. Everything else user can get using standard commands. All of such a commands have sgid on kmem. (This includes netstat/dmesg/systat/nfsstat/w/ps/etc, etc, etc.) > > I just wanted to clarify my wording. I've had quite enough of this subject. We've already wasted far more effort on the discussion than I was attempting to save by preventing a gratuitous change. > Me too. Honestly, I didn't expect any objections on this subject and was quite surprised after receiving so much responces (mostly from you :-) > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 21:54:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA17087 for freebsd-security-outgoing; Thu, 16 Apr 1998 21:54:42 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mph124.rh.psu.edu (mph@MPH124.rh.psu.edu [128.118.126.83]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA17070; Fri, 17 Apr 1998 04:54:34 GMT (envelope-from mph@mph124.rh.psu.edu) Received: (from mph@localhost) by mph124.rh.psu.edu (8.8.8/8.8.8) id AAA06016; Fri, 17 Apr 1998 00:54:09 -0400 (EDT) (envelope-from mph) Message-ID: <19980417005408.08278@mph124.rh.psu.edu> Date: Fri, 17 Apr 1998 00:54:08 -0400 From: Matthew Hunt To: dima@best.net Cc: stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions Mail-Followup-To: dima@best.net, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG References: <199804170340.UAA12029@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199804170340.UAA12029@burka.rdy.com>; from Dima Ruban on Thu, Apr 16, 1998 at 08:40:22PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Thu, Apr 16, 1998 at 08:40:22PM -0700, Dima Ruban wrote: > 1. Debugging symbols and symbol table - user doesn't need that. > 2. Possible kernel configuration - questionable. > 3. Kernel namelist - user doesn't need that. > 4. Kernel copy with possible commercial stuff - user doesn't need that. > 5. Kernel copy with possible restricted/crypto - user doesn't need that. My complaint, and I think the general complaint of people disagreeing with you, is that you are not setting policy at your site, you are setting policy on all FreeBSD boxes, as-shipped. Why are you in a position to decide what users, at thousands of sites besides your own, do or do not need to know? Many of the arguments you have made could be applied to making /bin/ls mode 111 as well, since nobody *needs* to look at that. There is a heritage, or intertia, that says we should keep things like they are, unless there is a clear reason to do otherwise. You, therefore, are the one in the position to justify the change, and it does not seem to me like you have done so. My $0.02. -- Matthew Hunt * Stay close to the Vorlon. http://mph124.rh.psu.edu/~mph/pgp.key for PGP public key 0x67203349. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 22:19:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA20750 for freebsd-security-outgoing; Thu, 16 Apr 1998 22:19:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA20745; Fri, 17 Apr 1998 05:19:22 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id WAA12540; (8.8.8/RDY) Thu, 16 Apr 1998 22:19:21 -0700 (PDT) Message-Id: <199804170519.WAA12540@burka.rdy.com> Subject: Re: kernel permissions In-Reply-To: <19980417005408.08278@mph124.rh.psu.edu> from Matthew Hunt at "Apr 17, 98 00:54:08 am" To: mph@pobox.com (Matthew Hunt) Date: Thu, 16 Apr 1998 22:19:21 -0700 (PDT) Cc: dima@best.net, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Matthew Hunt writes: > On Thu, Apr 16, 1998 at 08:40:22PM -0700, Dima Ruban wrote: > > > 1. Debugging symbols and symbol table - user doesn't need that. > > 2. Possible kernel configuration - questionable. > > 3. Kernel namelist - user doesn't need that. > > 4. Kernel copy with possible commercial stuff - user doesn't need that. > > 5. Kernel copy with possible restricted/crypto - user doesn't need that. > > My complaint, and I think the general complaint of people disagreeing > with you, is that you are not setting policy at your site, you are > setting policy on all FreeBSD boxes, as-shipped. It's not about setting policy. It's about being reasonable. > Why are you in a position to decide what users, at thousands of sites > besides your own, do or do not need to know? Many of the arguments > you have made could be applied to making /bin/ls mode 111 as well, > since nobody *needs* to look at that. Right. The only difference is - no harm could be done with being able to read /bin/ls (or possible bad things) > There is a heritage, or intertia, that says we should keep things like > they are, unless there is a clear reason to do otherwise. You, What heritage? You mean the amount of people what don't want this change? I can tell you that more people agreed with me in either private email or responding to the mailing list than disagree. > therefore, are the one in the position to justify the change, and it > does not seem to me like you have done so. Again. There's a difference between "potential problem" and "security hole". This is not a security hole, but a potential problem (theoretically possible even). If this doesn't break anything, why in the hell shouldn't we have it? "Don't fix that ain't broke" is not an answer. > > My $0.02. I think, I've already went over 10 bucks :-) > > -- > Matthew Hunt * Stay close to the Vorlon. > http://mph124.rh.psu.edu/~mph/pgp.key for PGP public key 0x67203349. > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 22:43:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA26075 for freebsd-security-outgoing; Thu, 16 Apr 1998 22:43:27 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA26035; Fri, 17 Apr 1998 05:43:07 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id BAA22191; Fri, 17 Apr 1998 01:42:46 -0400 (EDT) Date: Fri, 17 Apr 1998 01:45:29 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Dima Ruban cc: Matthew Hunt , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <199804170519.WAA12540@burka.rdy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk So, With all this discussion of various things that might or might not improve the security of a FreeBSD system, I'd like to propose the FreeBSD Hardening Project. What I have in mind is a port in the ports collection that would "harden" the default FreeBSD base installation. It would apply schg flags, remove unnecessary read/write/etc access from standard binaries and config files, disable most daemons and inetd.conf entries, install a more-than-minimal ipfw config, perhaps enable some kernel settings, etc. The goal would be to move from an "open" system to one that might be more appropriate for a router or firewall machine in a less friendly network environment. For the paranoid, of course, it would be appropriate for every-day use :). The system would then be in what many would consider an unusable state -- the administrator could optionally reenable features as they saw fit (i.e., incoming telnet, ftp, finger, incoming icmp, packet forwarding, smtp, and so on). Does this seem like an interesting or useful proposal? When setting up a proxy server, I really want a minimal feature set enabled, although having the standard toolset available is always useful. The proxy user, however, should not even be able to send packets on irregular ports, and would be restricted by ipfw. Similarly, use of secure levels would allow us to significantly reduce the effects of any kind of compromise. Some other thoughts I had were instructions for rolling a custom system CD + possibly a boot disk to create read-only machines for use as proxy servers or routers. Swap + MFS would be the only writable areas of the system, and neither of those would persist over boot. On my multi-user machines, I know directly or indirectly many of the users. But in the real world, contrary to the suggestions of many, one cannot trust Joe User. Either because they don't take precautions necessary to secure their own accounts, or because of the scale of the environment. A number of the large scale UNIX machines I have seen go so far as to disable all setuid utilities (other than su) to prevent unauthorized use of the system. Including utilities such as ping. No one debates the usefulness of remote login -- something that NT has as yet been unable to provide at any reasonable cost. But in a less trusted environment, it may be our undoing :). Anyhow, if there is sufficient interest in the project, I'd like to try and get it off the ground. Presumably, some changes might work their way back into the default distribution. If we lose no significant functionality, it cannot hurt to restrict priveledges. It may help us when those unpredicted vulnerabilities do turn up. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 22:50:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA28778 for freebsd-security-outgoing; Thu, 16 Apr 1998 22:50:52 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA28656; Fri, 17 Apr 1998 05:50:22 GMT (envelope-from asami@vader.cs.berkeley.edu) Received: from silvia.HIP.Berkeley.EDU (ala-ca34-10.ix.netcom.com [207.93.143.138]) by vader.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id WAA02023; Thu, 16 Apr 1998 22:50:13 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.8/8.6.9) id WAA11577; Thu, 16 Apr 1998 22:50:05 -0700 (PDT) Date: Thu, 16 Apr 1998 22:50:05 -0700 (PDT) Message-Id: <199804170550.WAA11577@silvia.HIP.Berkeley.EDU> To: dima@best.net CC: mph@pobox.com, dima@best.net, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-reply-to: <199804170519.WAA12540@burka.rdy.com> (dima@best.net) Subject: Re: kernel permissions From: asami@FreeBSD.ORG (Satoshi Asami) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk * From: dima@best.net (Dima Ruban) * What heritage? You mean the amount of people what don't want this change? * I can tell you that more people agreed with me in either private email * or responding to the mailing list than disagree. Really? I didn't say anything because I didn't want to contribute to this (seemingly unimportant) argument, but let me state for the record that I don't agree with you. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 22:56:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00749 for freebsd-security-outgoing; Thu, 16 Apr 1998 22:56:05 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mph124.rh.psu.edu (mph@MPH124.rh.psu.edu [128.118.126.83]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA00532; Fri, 17 Apr 1998 05:55:17 GMT (envelope-from mph@mph124.rh.psu.edu) Received: (from mph@localhost) by mph124.rh.psu.edu (8.8.8/8.8.8) id BAA06596; Fri, 17 Apr 1998 01:55:06 -0400 (EDT) (envelope-from mph) Message-ID: <19980417015505.15073@mph124.rh.psu.edu> Date: Fri, 17 Apr 1998 01:55:05 -0400 From: Matthew Hunt To: Robert Watson , Dima Ruban Cc: stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions Mail-Followup-To: Robert Watson , Dima Ruban , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG References: <199804170519.WAA12540@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Robert Watson on Fri, Apr 17, 1998 at 01:45:29AM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, Apr 17, 1998 at 01:45:29AM -0400, Robert Watson wrote: > Anyhow, if there is sufficient interest in the project, I'd like to try > and get it off the ground. Presumably, some changes might work their way > back into the default distribution. If we lose no significant > functionality, it cannot hurt to restrict priveledges. It may help us > when those unpredicted vulnerabilities do turn up. It sounds to me like a wothwhile project, even though I would be unlikely to use it myself. I do question the idea of making it part of the ports system, because the idea of ports modifying the base system seems like a considerable departure from the rest of the ports collection. I can't be persuaded that a world-readable kernel can ever present a problem (the real problem would have to be in some other software) and Dima is unlikely to be persuaded to my point of view. I see a pattern in my future: "make install", forget to change the perms to 444, reboot, kick myself (since I run with securelevel=1), swear to remember next time, and repeat the cycle. :-) -- Matthew Hunt * Stay close to the Vorlon. http://mph124.rh.psu.edu/~mph/pgp.key for PGP public key 0x67203349. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 23:44:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13507 for freebsd-security-outgoing; Thu, 16 Apr 1998 23:44:33 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mailhub.NetMan.SE (mailhub.netman.se [194.52.54.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA13428; Fri, 17 Apr 1998 06:44:21 GMT (envelope-from allard@NetMan.SE) Received: (from uucp@localhost) by mailhub.NetMan.SE (8.8.5/8.8.5) id IAA23639; Fri, 17 Apr 1998 08:50:37 +0200 (CEST) Received: from localhost(127.0.0.1) by mailhub.NetMan.SE via smap (V2.0) id xma023636; Fri, 17 Apr 98 08:50:11 +0200 Date: Fri, 17 Apr 1998 08:50:11 +0200 (CEST) From: Johan Allard To: Robert Watson cc: Dima Ruban , Matthew Hunt , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Indeed something to work on. An excellent suggestion. On the whish list I would like to add support for IPsec. It must be possible to port the code from OpenBSD. Since OpenBSD is exported from Canada it is possible to use it with strong encryptions even here in Europe. If it is possible to import the OpenBSD code with regular patches using ports it would be possible to include it in FreeBSD and use it worldwide. The world indeed be a better place if we could use IPsec with FreeBSD. //johan allard > So, > > With all this discussion of various things that might or might not improve > the security of a FreeBSD system, I'd like to propose the FreeBSD > Hardening Project. What I have in mind is a port in the ports collection > that would "harden" the default FreeBSD base installation. It would apply > schg flags, remove unnecessary read/write/etc access from standard > binaries and config files, disable most daemons and inetd.conf entries, > install a more-than-minimal ipfw config, perhaps enable some kernel > settings, etc. The goal would be to move from an "open" system to one > that might be more appropriate for a router or firewall machine in a less > friendly network environment. For the paranoid, of course, it would be > appropriate for every-day use :). > > The system would then be in what many would consider an unusable state -- > the administrator could optionally reenable features as they saw fit > (i.e., incoming telnet, ftp, finger, incoming icmp, packet forwarding, > smtp, and so on). > > Does this seem like an interesting or useful proposal? When setting up a > proxy server, I really want a minimal feature set enabled, although having > the standard toolset available is always useful. The proxy user, however, > should not even be able to send packets on irregular ports, and would be > restricted by ipfw. Similarly, use of secure levels would allow us to > significantly reduce the effects of any kind of compromise. > > Some other thoughts I had were instructions for rolling a custom system CD > + possibly a boot disk to create read-only machines for use as proxy > servers or routers. Swap + MFS would be the only writable areas of the > system, and neither of those would persist over boot. > > On my multi-user machines, I know directly or indirectly many of the > users. But in the real world, contrary to the suggestions of many, one > cannot trust Joe User. Either because they don't take precautions > necessary to secure their own accounts, or because of the scale of the > environment. A number of the large scale UNIX machines I have seen go so > far as to disable all setuid utilities (other than su) to prevent > unauthorized use of the system. Including utilities such as ping. No one > debates the usefulness of remote login -- something that NT has as yet > been unable to provide at any reasonable cost. But in a less trusted > environment, it may be our undoing :). > > Anyhow, if there is sufficient interest in the project, I'd like to try > and get it off the ground. Presumably, some changes might work their way > back into the default distribution. If we lose no significant > functionality, it cannot hurt to restrict priveledges. It may help us > when those unpredicted vulnerabilities do turn up. > > Robert N Watson > > > ---- > Carnegie Mellon University http://www.cmu.edu/ > Trusted Information Systems http://www.tis.com/ > SafePort Network Services http://www.safeport.com/ > robert@fledge.watson.org http://www.watson.org/~robert/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 23:45:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13903 for freebsd-security-outgoing; Thu, 16 Apr 1998 23:45:37 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA13888; Fri, 17 Apr 1998 06:45:31 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id XAA13015; (8.8.8/RDY) Thu, 16 Apr 1998 23:45:26 -0700 (PDT) Message-Id: <199804170645.XAA13015@burka.rdy.com> Subject: Re: kernel permissions (part II) In-Reply-To: <19980417015505.15073@mph124.rh.psu.edu> from Matthew Hunt at "Apr 17, 98 01:55:05 am" To: mph@pobox.com (Matthew Hunt) Date: Thu, 16 Apr 1998 23:45:26 -0700 (PDT) Cc: robert+freebsd@cyrus.watson.org, dima@best.net, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Matthew Hunt writes: > On Fri, Apr 17, 1998 at 01:45:29AM -0400, Robert Watson wrote: > > > Anyhow, if there is sufficient interest in the project, I'd like to try > > and get it off the ground. Presumably, some changes might work their way > > back into the default distribution. If we lose no significant > > functionality, it cannot hurt to restrict priveledges. It may help us > > when those unpredicted vulnerabilities do turn up. > > It sounds to me like a wothwhile project, even though I would be > unlikely to use it myself. I do question the idea of making it It actually depends on what are you using FreeBSD for. Of course you don't really need it if you use you machine as a desktop, or in one/few user production enviroment. (No need to argue, it's just a basic point) > part of the ports system, because the idea of ports modifying the > base system seems like a considerable departure from the rest of > the ports collection. About having this in ports - I don't think so, and I doubt Satoshi will disagree with me. > I can't be persuaded that a world-readable kernel can ever present > a problem (the real problem would have to be in some other software) Absolutely. That's why I've called it a "potential problem" > and Dima is unlikely to be persuaded to my point of view. I see > a pattern in my future: "make install", forget to change the perms > to 444, reboot, kick myself (since I run with securelevel=1), swear > to remember next time, and repeat the cycle. :-) :-) I don't see a good way of adjusting this. That why I was pointing that this change ton't break anything. Speaking about improving security. How about change like this (I didn't implement it yet, but it's not be a big deal). Right now we have a mount flag "nosuid". It serves it's mission, but I'd love to have some flexibility on this. Example is ISP enviroment (again :-). You want to allow users to have suid to them programs, but at the same time you feel bad about having suid programs for uids less than something (let's say 100). How about to implement this? Via mount options or something else? Let's say, one wants to allow users to have suid programs, if uid on suid program is greater than N and less than M. How does it sound? > > -- > Matthew Hunt * Stay close to the Vorlon. > http://mph124.rh.psu.edu/~mph/pgp.key for PGP public key 0x67203349. > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 16 23:55:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17554 for freebsd-security-outgoing; Thu, 16 Apr 1998 23:55:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17429; Fri, 17 Apr 1998 06:55:29 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id OAA27954; Fri, 17 Apr 1998 14:52:55 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804170652.OAA27954@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Hunt cc: Robert Watson , Dima Ruban , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Fri, 17 Apr 1998 01:55:05 -0400." <19980417015505.15073@mph124.rh.psu.edu> Date: Fri, 17 Apr 1998 14:52:54 +0800 From: Peter Wemm Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Matthew Hunt wrote: [..] > I can't be persuaded that a world-readable kernel can ever present > a problem (the real problem would have to be in some other software) > and Dima is unlikely to be persuaded to my point of view. I see > a pattern in my future: "make install", forget to change the perms > to 444, reboot, kick myself (since I run with securelevel=1), swear > to remember next time, and repeat the cycle. :-) For what it's worth, I strongly disagree with making it 440 as well. It serves no purpose other than inconveniencing people. I mean, the majority of the systems would stil have /usr/src/sys/compile/SYSNAME/* readable. What's next? enforcing restricted permissions on /usr/src? chmod 751 /dev? How many places do we describe 'nm -p /kernel | sort | more' as part of the standard procedure for people mailing bug reports? This is rare enough as it is, and since it's more inconvenient it'll become rarer still. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 01:57:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA11239 for freebsd-security-outgoing; Fri, 17 Apr 1998 01:57:28 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA11233 for ; Fri, 17 Apr 1998 08:57:25 GMT (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id MAA06829; Fri, 17 Apr 1998 12:53:05 +0200 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id LAA17452; Fri, 17 Apr 1998 11:15:07 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id KAA12109; Fri, 17 Apr 1998 10:55:57 +0200 (CEST) Message-ID: <19980417105557.59439@deepo.prosa.dk> Date: Fri, 17 Apr 1998 10:55:57 +0200 From: Philippe Regnauld To: Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions References: <199804170519.WAA12540@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: ; from Robert Watson on Fri, Apr 17, 1998 at 01:45:29AM -0400 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Robert Watson writes: > Hardening Project. What I have in mind is a port in the ports collection > that would "harden" the default FreeBSD base installation. It would apply > schg flags, remove unnecessary read/write/etc access from standard > binaries and config files, disable most daemons and inetd.conf entries, > install a more-than-minimal ipfw config, perhaps enable some kernel > settings, etc. I'm all for this, and would be willing to test it. While you're at it: - include the hardening to _removing_ certain syscalls from the kernel (see below) - you could use the "ugly" dialog lib. to make a nice menu selection (like the GS port) to enable/disable features: [ ] Standard (definition) [ ] Paranoid (definition) [ ] X-Files [X] Custom [ ] Make kernel unreadable to world :-) [X] Append-only /var ? [...] > The goal would be to move from an "open" system to one > that might be more appropriate for a router or firewall machine in a less > friendly network environment. For the paranoid, of course, it would be > appropriate for every-day use :). Yep. > Does this seem like an interesting or useful proposal? When setting up a > proxy server, I really want a minimal feature set enabled, although having > the standard toolset available is always useful. The proxy user, however, > should not even be able to send packets on irregular ports, and would be > restricted by ipfw. Similarly, use of secure levels would allow us to > significantly reduce the effects of any kind of compromise. Suggestion: how difficult would it be to have ipfw(8) respect the securelevel to, for example, refuse to flush / alter the ipfw list ? i.e.: all mods have to be tested before the securelevel is raised, and once it is, only rebooting into single user on the console allows you to change the filters. > Some other thoughts I had were instructions for rolling a custom system CD > + possibly a boot disk to create read-only machines for use as proxy > servers or routers. Swap + MFS would be the only writable areas of the > system, and neither of those would persist over boot. We need write-protect notch on the hard-disks :-) > environment. A number of the large scale UNIX machines I have seen go so > far as to disable all setuid utilities (other than su) to prevent > unauthorized use of the system. Some off-the-shelf firewall packages, like BorderWare (based on BSDi) uses a dual-kernel approach: - an operational, network-aware kernel stripped of suspect system calls (particularly the *id stuff) - a fully functional "single-user" kernel with NO networking to do the maintenance. This is a tad straight-jacketed, but you get the idea (I hope). > Anyhow, if there is sufficient interest in the project, I'd like to try > and get it off the ground. Presumably, some changes might work their way > back into the default distribution. If we lose no significant > functionality, it cannot hurt to restrict priveledges. It may help us > when those unpredicted vulnerabilities do turn up. Better than a port: a separate set of tarballs in the dist: harden.aa harden.ab ... ? Anti-bloatists oblige. -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle, ("MYTHOLOGY", in Marutukku distrib) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 02:30:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA15021 for freebsd-security-outgoing; Fri, 17 Apr 1998 02:30:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from crox.tesco-stores.cz (crox.tesco-stores.cz [194.228.14.140]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA14997 for ; Fri, 17 Apr 1998 09:30:16 GMT (envelope-from frf@crox.tesco-stores.cz) Received: (from frf@localhost) by crox.tesco-stores.cz (8.8.8/8.8.8) id LAA07183 for freebsd-security@FreeBSD.ORG; Fri, 17 Apr 1998 11:30:11 +0200 (CEST) (envelope-from frf) From: frf Message-Id: <199804170930.LAA07183@crox.tesco-stores.cz> Subject: IPSec (was Re: kernel permissions) To: freebsd-security@FreeBSD.ORG Date: Fri, 17 Apr 1998 11:30:11 +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 => On the whish list I would like to add support for IPsec. It must be => possible to port the code from OpenBSD. Since OpenBSD is exported from => Canada it is possible to use it with strong encryptions even here in => Europe. If it is possible to import the OpenBSD code with regular patches => using ports it would be possible to include it in FreeBSD and use it => worldwide. Has anyone looked at the FreeS/WAN project? It's currently only under development on linux kernels, but this is *only* because of a 'GPL vs. Berkeley' license issue. http://www.xs4all.nl/~freeswan Robert -- frf at xocolatl dot com frf at tesco dash stores dot cz finger frf@crux.tesco-stores.cz for public key. "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, _Historical_Review_of_Pennsylvania_, 1759. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 04:08:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA01585 for freebsd-security-outgoing; Fri, 17 Apr 1998 04:08:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from server-a.cs.interbusiness.it (mail.cs.interbusiness.it [151.99.250.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01383 for ; Fri, 17 Apr 1998 11:07:42 GMT (envelope-from Nicola.Marinelli@tlsoft.it) From: Nicola.Marinelli@tlsoft.it Received: from gwnet.tlsoft.it (gwnet.tlsoft.it [193.76.148.71]) by server-a.cs.interbusiness.it (8.8.8/8.8.8) with SMTP id NAA11474 for ; Fri, 17 Apr 1998 13:04:47 +0200 (MET DST) Received: from nn5002.napoli.tlsoft.it by gwnet.tlsoft.it (SMI-8.6/SMI-SVR4-Telesoft-300197) id NAA17268; Fri, 17 Apr 1998 13:06:42 +0200 Received: by nn5002.napoli.tlsoft.it (5.x/dn-051996); id AA17004; Fri, 17 Apr 1998 13:06:41 +0200 Date: Fri, 17 Apr 98 13:03:57 +0100 To: freebsd-security@FreeBSD.ORG X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk unsubscribe freebsd-security -------------------------------------------------------- Name: Nicola Marinelli E-mail: Nicola.Marinelli@tlsoft.it Date: 04/17/98 Time: 13:03:58 ------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 08:58:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16376 for freebsd-security-outgoing; Fri, 17 Apr 1998 08:58:48 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA16233; Fri, 17 Apr 1998 15:58:27 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id IAA11842; Fri, 17 Apr 1998 08:57:44 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Johan Allard cc: Robert Watson , Dima Ruban , Matthew Hunt , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Fri, 17 Apr 1998 08:50:11 +0200." Date: Fri, 17 Apr 1998 08:57:44 -0700 Message-ID: <11838.892828664@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > On the whish list I would like to add support for IPsec. It must be The WIDE project folks have already implemented both IPsec and IPv6 - we just need to incorporate their stuff without hopefully pissing off any of the 1,473 different other IPv6 implementors out there .: -) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 09:16:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA21115 for freebsd-security-outgoing; Fri, 17 Apr 1998 09:16:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA21045; Fri, 17 Apr 1998 16:16:08 GMT (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id MAA11623; Fri, 17 Apr 1998 12:15:57 -0400 (EDT) (envelope-from wollman) Date: Fri, 17 Apr 1998 12:15:57 -0400 (EDT) From: Garrett Wollman Message-Id: <199804171615.MAA11623@khavrinen.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: Johan Allard , Robert Watson , Dima Ruban , Matthew Hunt , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <11838.892828664@time.cdrom.com> References: <11838.892828664@time.cdrom.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk < said: >> On the whish list I would like to add support for IPsec. It must be > The WIDE project folks have already implemented both IPsec and > IPv6 - we just need to incorporate their stuff without hopefully > pissing off any of the 1,473 different other IPv6 implementors out > there .: -) If we could just get the WIDE people and the INRIA people (and the NRL people) to all coalesce around a single solution, we'd have a clear winner. -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 security" in the body of the message From owner-freebsd-security Fri Apr 17 09:39:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA25273 for freebsd-security-outgoing; Fri, 17 Apr 1998 09:39:14 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from coconut.itojun.org (itojun@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA25223; Fri, 17 Apr 1998 16:39:07 GMT (envelope-from itojun@itojun.org) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W/smtpfeed 0.59) with ESMTP id BAA27912; Sat, 18 Apr 1998 01:38:44 +0900 (JST) To: Garrett Wollman cc: "Jordan K. Hubbard" , Johan Allard , Robert Watson , Dima Ruban , Matthew Hunt , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-reply-to: wollman's message of Fri, 17 Apr 1998 12:15:57 -0400. <199804171615.MAA11623@khavrinen.lcs.mit.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: kernel permissions From: Jun-ichiro itojun Itoh Date: Sat, 18 Apr 1998 01:38:44 +0900 Message-ID: <27908.892831124@coconut.itojun.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk >If we could just get the WIDE people and the INRIA people (and the NRL >people) to all coalesce around a single solution, we'd have a clear >winner. Though I'm very happy to try a joint effort, I think it is a "hard one". There's no standardized way of dealing with bunch of details of IPv6. WIDE/INRIA/NRL/others are quite different from each other. (believe me I ported INRIA/NRL from *BSD to *BSD several times, for some snapshots) Just imagine the differences in {Net,Free,Open}BSD{/OS} sys/net{,inet} code, and imagine why they can't be the same. You'll see what I'm saying. For WIDE IPv6/IPsec code: We're going to work on WIDE IPv6 stack in a full-time manner, so we'll be able to release WIDE IPv6/IPsec for FreeBSD 3.0 (maybe SNAP-98xxxx) in some weeks, hopefully. ftp://ftp.itojun.org/pub/ipv6 has weekly snapshot, as always. Jun-ichiro itojun Itoh itojun@{itojun.org,iij.ad.jp,kame.net} one of WIDE people To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 10:05:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA01922 for freebsd-security-outgoing; Fri, 17 Apr 1998 10:05:20 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA01911 for ; Fri, 17 Apr 1998 17:05:10 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id KAA12448; Fri, 17 Apr 1998 10:04:07 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Garrett Wollman cc: Johan Allard , Robert Watson , Dima Ruban , Matthew Hunt , freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Fri, 17 Apr 1998 12:15:57 EDT." <199804171615.MAA11623@khavrinen.lcs.mit.edu> Date: Fri, 17 Apr 1998 10:04:07 -0700 Message-ID: <12444.892832647@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > If we could just get the WIDE people and the INRIA people (and the NRL > people) to all coalesce around a single solution, we'd have a clear > winner. Of course, the odds of that ever happening are probably equivalent to that of the moon suddenly flying out of its orbit, so what would you propose instead? We just can't keep sitting on the fence and doing nothing about this forever, can we? Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 11:06:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA14336 for freebsd-security-outgoing; Fri, 17 Apr 1998 11:06:17 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA14226 for ; Fri, 17 Apr 1998 18:06:01 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id OAA01034; Fri, 17 Apr 1998 14:05:50 -0400 (EDT) Date: Fri, 17 Apr 1998 14:08:30 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Philippe Regnauld cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <19980417105557.59439@deepo.prosa.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, 17 Apr 1998, Philippe Regnauld wrote: > > Hardening Project. What I have in mind is a port in the ports collection > > that would "harden" the default FreeBSD base installation. It would apply > > schg flags, remove unnecessary read/write/etc access from standard > > binaries and config files, disable most daemons and inetd.conf entries, > > install a more-than-minimal ipfw config, perhaps enable some kernel > > settings, etc. > > I'm all for this, and would be willing to test it. > While you're at it: > > - include the hardening to _removing_ certain syscalls from the kernel > (see below) ... > > Suggestion: how difficult would it be to have ipfw(8) respect > the securelevel to, for example, refuse to flush / alter > the ipfw list ? > > i.e.: all mods have to be tested before the securelevel is raised, > and once it is, only rebooting into single user on the console > allows you to change the filters. I had been thinking along similar lines also. Either in terms of a new securelevel (3?) with much tighter restrictions than currently in place, or through the hardening of existing securelevels. It might be desirable to have a fairly multi-stage boot: (secure level -1) (networking completely disabled) check, mount file systems (non-network) configure ipfw (do not enable it yet) (secure level +1) start common daemons that require append log file access (syslog) (secure level +2) start highest level daemons, but that might require a pid file (secure level +3) system is locked down, and network is enabled I have not thought this out in detail yet. However, ipfw modifications + ifconfig modifications could only be made at secure level -1 or +1 or such. At +3, networking could be enabled and disabled as a whole through ifconfig (interface) up or via ipfw, but no policy or configuration could be modified. Other thoughts: /var/run on mfs /tmp, /var/tmp on mfs Disable drive mounting/unmounting/remounting at +2 and above? Also, are there any conclusions about how to lower the securelevel? Some systems have an arrangement whereby when you run level goes down (i.e., shutdown to single user mode), you can regain lower securelevels without rebooting. I had concerns about the killing of processes at shutdown not working right, or that there might be ways around this, so was thinking for myself that only rebooting would lower the securelevel. Perhaps we should be assembling a wish-list somewhere as there does seem to be a great deal of interest. Unless someone feels moved to have it on www.freebsd.org, I'll go ahead and stick up all the suggestions I've received so far on my own server and post a URL later today. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 11:10:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA16060 for freebsd-security-outgoing; Fri, 17 Apr 1998 11:10:34 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA15906; Fri, 17 Apr 1998 18:10:06 GMT (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id OAA06694; Fri, 17 Apr 1998 14:09:55 -0400 (EDT) Date: Fri, 17 Apr 1998 14:09:55 -0400 (EDT) From: "Matthew N. Dodd" To: Matthew Hunt cc: dima@best.net, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <19980417005408.08278@mph124.rh.psu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, 17 Apr 1998, Matthew Hunt wrote: > My complaint, and I think the general complaint of people disagreeing > with you, is that you are not setting policy at your site, you are > setting policy on all FreeBSD boxes, as-shipped. You have to have some sort of baseline. Look at /etc/login.conf. If that doesn't set policy for the entire set of all FreeBSD boxes I don't know what does. Why you didn't fuss about that as much when it went in I'm not sure. I detect an 'information wants to be free' additude though. Maybe its just me... /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 11:18:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA18811 for freebsd-security-outgoing; Fri, 17 Apr 1998 11:18:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from set.spradley.tmi.net (set.spradley.tmi.net [207.170.107.99]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA18621; Fri, 17 Apr 1998 18:17:57 GMT (envelope-from tsprad@set.spradley.tmi.net) Received: from localhost (set.spradley.tmi.net) [127.0.0.1] by set.spradley.tmi.net with esmtp (Exim 1.82 #2) id 0yQFh3-00071V-00; Fri, 17 Apr 1998 13:16:57 -0500 X-Mailer: exmh version 2.0zeta 7/24/97 To: Robert Watson cc: Dima Ruban , Matthew Hunt , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Fri, 17 Apr 1998 01:45:29 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Apr 1998 13:16:56 -0500 From: Ted Spradley Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Robert Watson writes: > With all this discussion of various things that might or might not improve > the security of a FreeBSD system, I'd like to propose the FreeBSD > Hardening Project. Good idea. [...] > Some other thoughts I had were instructions for rolling a custom system CD > + possibly a boot disk to create read-only machines for use as proxy > servers or routers. Swap + MFS would be the only writable areas of the > system, and neither of those would persist over boot. I think this is a *particularly* good idea. Much less to worry about if most if the important stuff is read-only or write-once-read-many. [...] > Robert N Watson > > > ---- > Carnegie Mellon University http://www.cmu.edu/ > Trusted Information Systems http://www.tis.com/ > SafePort Network Services http://www.safeport.com/ > robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 11:26:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21428 for freebsd-security-outgoing; Fri, 17 Apr 1998 11:26:31 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA21226; Fri, 17 Apr 1998 18:25:32 GMT (envelope-from handy@sag.space.lockheed.com) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA28759; Fri, 17 Apr 1998 11:23:41 -0700 Date: Fri, 17 Apr 1998 11:23:41 -0700 (PDT) From: Brian Handy To: "Matthew N. Dodd" Cc: Matthew Hunt , dima@best.net, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: Message-Id: X-Files: The truth is out there Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, 17 Apr 1998, Matthew N. Dodd wrote: >On Fri, 17 Apr 1998, Matthew Hunt wrote: >> My complaint, and I think the general complaint of people disagreeing >> with you, is that you are not setting policy at your site, you are >> setting policy on all FreeBSD boxes, as-shipped. > >You have to have some sort of baseline. > >Look at /etc/login.conf. Yep, and I maintain that for 99% of us, this was a *HUGE* step backwards. Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 11:41:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26277 for freebsd-security-outgoing; Fri, 17 Apr 1998 11:41:26 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mph124.rh.psu.edu (mph@MPH124.rh.psu.edu [128.118.126.83]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA26147; Fri, 17 Apr 1998 18:40:58 GMT (envelope-from mph@mph124.rh.psu.edu) Received: (from mph@localhost) by mph124.rh.psu.edu (8.8.8/8.8.8) id OAA25457; Fri, 17 Apr 1998 14:40:48 -0400 (EDT) (envelope-from mph) Message-ID: <19980417144046.41055@mph124.rh.psu.edu> Date: Fri, 17 Apr 1998 14:40:46 -0400 From: Matthew Hunt To: "Matthew N. Dodd" Cc: dima@best.net, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions Mail-Followup-To: "Matthew N. Dodd" , dima@best.net, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG References: <19980417005408.08278@mph124.rh.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Matthew N. Dodd on Fri, Apr 17, 1998 at 02:09:55PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, Apr 17, 1998 at 02:09:55PM -0400, Matthew N. Dodd wrote: > Look at /etc/login.conf. If that doesn't set policy for the entire set of > all FreeBSD boxes I don't know what does. Why you didn't fuss about that > as much when it went in I'm not sure. (I think this discussion is out of proportion, so I will just address these issues and be done with it.) Two reasons: (a) login.conf resources limits address a genuine security issue, that of DoS attacks by resource exhaustion. I cannot see how reading the kernel can possibly be a security problem in and of itself. (b) I can change login.conf on my machine, and it will stay changed. If Makefile.i386 changes, changes I make will be destroyed by cvsup, so I have to change the Makefile whenever I build a kernel, or change the permissions right after "make install". > I detect an 'information wants to be free' additude though. Maybe its > just me... Yes, that's exactly it. I do not agree with hiding information unnecessarily. The belief that this change improves security seems like a "security by obscurity" approach. Hope this clarifies my opinions. -- Matthew Hunt * Stay close to the Vorlon. http://mph124.rh.psu.edu/~mph/pgp.key for PGP public key 0x67203349. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 12:06:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03594 for freebsd-security-outgoing; Fri, 17 Apr 1998 12:06:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from shamash.org (shamash.org [207.240.86.25]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA03499 for ; Fri, 17 Apr 1998 19:06:24 GMT (envelope-from k@yt.to) Received: (qmail 17112 invoked from network); 17 Apr 1998 19:05:50 -0000 Received: from ren.camb.opengroup.org (130.105.3.129) by yt.to with SMTP; 17 Apr 1998 19:05:50 -0000 Received: (qmail 10012 invoked by uid 12573); 17 Apr 1998 19:04:53 -0000 Message-ID: <19980417150453.H3352@yt.to> Date: Fri, 17 Apr 1998 15:04:53 -0400 From: Louis Theran To: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <19980417005408.08278@mph124.rh.psu.edu> <19980417144046.41055@mph124.rh.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19980417144046.41055@mph124.rh.psu.edu>; from Matthew Hunt on Fri, Apr 17, 1998 at 02:40:46PM -0400 X-No-Archive: Yes Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, Apr 17, 1998 at 02:40:46PM -0400, Matthew Hunt wrote: > Yes, that's exactly it. I do not agree with hiding information > unnecessarily. The belief that this change improves security seems > like a "security by obscurity" approach. While security by obscurity by itself is not too useful, as long as it does not pervent real security measures from being used, it generally does not hurt. ^L -- Louis Theran -- Carjacker on the Information Superhighway "Te occidere possunt, sed te edere non possunt nefas quo est." PGP welcome; key at: k-pgpkey@yt.to To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 12:30:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA08834 for freebsd-security-outgoing; Fri, 17 Apr 1998 12:30:22 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA08800 for ; Fri, 17 Apr 1998 19:30:09 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id PAA02177 for ; Fri, 17 Apr 1998 15:30:02 -0400 (EDT) Date: Fri, 17 Apr 1998 15:32:41 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: freebsd-security@FreeBSD.ORG Subject: As promised, a quicky Hardening Project writeup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk I've stuck together the beginnings of a wishlist + goals at: http://www.watson.org/fbsd-hardening/ I invite any comments, suggestions, additions, etc. At this point, I am assuming nothing is final (even the project :), but I think this would be an interesting (and useful) path to follow. Presumably, discussion of this should remain on freebsd-security. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 12:46:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA13159 for freebsd-security-outgoing; Fri, 17 Apr 1998 12:46:58 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA13146 for ; Fri, 17 Apr 1998 19:46:46 GMT (envelope-from fullermd@futuresouth.com) Received: from localhost (fullermd@localhost) by shell.futuresouth.com (8.8.8/8.8.8) with SMTP id OAA28918; Fri, 17 Apr 1998 14:46:26 -0500 (CDT) Date: Fri, 17 Apr 1998 14:46:26 -0500 (CDT) From: "Matthew D. Fuller" To: "Jordan K. Hubbard" cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <12444.892832647@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [trim trim trim on cc] On Fri, 17 Apr 1998, Jordan K. Hubbard wrote: > > If we could just get the WIDE people and the INRIA people (and the NRL > > people) to all coalesce around a single solution, we'd have a clear > > winner. > > Of course, the odds of that ever happening are probably equivalent to > that of the moon suddenly flying out of its orbit, so what would you > propose instead? We just can't keep sitting on the fence and doing > nothing about this forever, can we? Heck, that's easy. Just go with the highest bidder (who'll pay us the most to use theirs ;) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 13:42:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22570 for freebsd-security-outgoing; Fri, 17 Apr 1998 13:42:36 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA22487 for ; Fri, 17 Apr 1998 20:41:58 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id QAA03110 for ; Fri, 17 Apr 1998 16:41:51 -0400 (EDT) Date: Fri, 17 Apr 1998 16:44:29 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: freebsd-security@FreeBSD.ORG Subject: Proposal: remove existing schg flags from make buildworld Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Currently, the use of schg flags can be a major hassle for those trying to build secure systems. Performing a build world generates a set of schg files that are hard to deal with in a secure environment (after all, they are schg :). Rather than imposing the schg flags during the build, it might be more appropriate to apply them only during the install. Even blowing away my object tree is made difficult: fledge:/home/fbsd-stable/src# rm -Rf ../obj/* rm: ../obj/home/fbsd-stable/src/tmp/usr/lib/libcipher.so.2.0: Operation not permitted rm: ../obj/home/fbsd-stable/src/tmp/usr/lib/libc.so.3.1: Operation not permitted rm: ../obj/home/fbsd-stable/src/tmp/usr/lib/libdescrypt.so.2.0: Operation not permitted rm: ../obj/home/fbsd-stable/src/tmp/usr/lib: Directory not empty rm: ../obj/home/fbsd-stable/src/tmp/usr/libexec/ld.so: Operation not permitted rm: ../obj/home/fbsd-stable/src/tmp/usr/libexec: Directory not empty rm: ../obj/home/fbsd-stable/src/tmp/usr: Directory not empty rm: ../obj/home/fbsd-stable/src/tmp: Directory not empty (up-to-date version of -stable -- I assume this also happens in -current?) There is nothing gained by doing this -- the source is not protected, and neither is the compiler :). Clearly on an install, it is useful to apply schg (although previous discussion suggests that this is not the case with the current arrangement :), but not during the build process. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 14:30:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA01204 for freebsd-security-outgoing; Fri, 17 Apr 1998 14:30:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA01155; Fri, 17 Apr 1998 21:30:36 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id RAA01029; Fri, 17 Apr 1998 17:30:22 -0400 (EDT) Date: Fri, 17 Apr 1998 17:33:00 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Dima Ruban cc: Matthew Hunt , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions (part II) In-Reply-To: <199804170645.XAA13015@burka.rdy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Thu, 16 Apr 1998, Dima Ruban wrote: > How about change like this (I didn't implement it yet, but it's not be a big > deal). > Right now we have a mount flag "nosuid". It serves it's mission, > but I'd love to have some flexibility on this. > Example is ISP enviroment (again :-). You want to allow users to have > suid to them programs, but at the same time you feel bad about having > suid programs for uids less than something (let's say 100). > > How about to implement this? Via mount options or something else? > Let's say, one wants to allow users to have suid programs, if uid on suid > program is greater than N and less than M. I was playing with this idea at one point, but still am not sure it is the best solution. One thing that might be nice to see (if layering support gets fixed) would be a POSIX capabilities layer to reduce the number of setuid programs needed. In an ISP environment, what setuid programs do you have in mind that users would use? I have never tried the setuid cgi wrapper I've heard described in the context of apache, for example. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 15:41:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22977 for freebsd-security-outgoing; Fri, 17 Apr 1998 15:41:34 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail-01.cdsnet.net (mail-01.cdsnet.net [206.107.16.35]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA22926 for ; Fri, 17 Apr 1998 22:41:22 GMT (envelope-from mrcpu@internetcds.com) Received: (qmail 19870 invoked from network); 17 Apr 1998 22:41:18 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail-01.cdsnet.net with SMTP; 17 Apr 1998 22:41:18 -0000 Date: Fri, 17 Apr 1998 15:41:18 -0700 (PDT) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: Robert Watson cc: freebsd-security@FreeBSD.ORG Subject: Re: Proposal: remove existing schg flags from make buildworld In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Amen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 15:56:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26626 for freebsd-security-outgoing; Fri, 17 Apr 1998 15:56:47 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA26533 for ; Fri, 17 Apr 1998 22:56:21 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id PAA14150; Fri, 17 Apr 1998 15:55:44 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Brian Handy cc: "Matthew N. Dodd" , Matthew Hunt , dima@best.net, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Fri, 17 Apr 1998 11:23:41 PDT." Date: Fri, 17 Apr 1998 15:55:44 -0700 Message-ID: <14147.892853744@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [Can we get this thread the ^&%@!$#!! out of -stable now please?] > Yep, and I maintain that for 99% of us, this was a *HUGE* step backwards. What would you have done instead? Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 16:01:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA27849 for freebsd-security-outgoing; Fri, 17 Apr 1998 16:01:34 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27736 for ; Fri, 17 Apr 1998 23:01:04 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id QAA14236; Fri, 17 Apr 1998 16:00:42 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Robert Watson cc: freebsd-security@FreeBSD.ORG Subject: Re: As promised, a quicky Hardening Project writeup In-reply-to: Your message of "Fri, 17 Apr 1998 15:32:41 EDT." Date: Fri, 17 Apr 1998 16:00:42 -0700 Message-ID: <14232.892854042@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Presumably, discussion of this should remain on freebsd-security. Yes, but not -stable. Please watch your cc's on this folks! Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 16:04:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA28930 for freebsd-security-outgoing; Fri, 17 Apr 1998 16:04:15 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA28823 for ; Fri, 17 Apr 1998 23:04:02 GMT (envelope-from handy@sag.space.lockheed.com) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA19755; Fri, 17 Apr 1998 16:03:50 -0700 Date: Fri, 17 Apr 1998 16:03:50 -0700 (PDT) From: Brian Handy To: "Jordan K. Hubbard" Cc: "Matthew N. Dodd" , Matthew Hunt , dima@best.net, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <14147.892853744@time.cdrom.com> Message-Id: X-Files: The truth is out there Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk >[Can we get this thread the ^&%@!$#!! out of -stable now please?] > >> Yep, and I maintain that for 99% of us, this was a *HUGE* step backwards. > >What would you have done instead? [Brian checks we're out of -stable, though this rant isn't a -security topic] Nothing? For ISP's and people running servers, I'm sure it's great! For the Rest of Us, the unwashed masses, the people who just buy a PC and try to do data analysis and write theses and run netscape and compile big programs, *all* this ever does is jam up the works. How many emails have you seen on the lists where somebody said "I can't get this to work, waaaah" and LOTS of times the answer is "Oh, you have to relax the limits in login.conf for that to work!"????? Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 17 17:32:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA22241 for freebsd-security-outgoing; Fri, 17 Apr 1998 17:32:32 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from d183-205.uoregon.edu (d183-205.uoregon.edu [128.223.183.205]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA22222 for ; Sat, 18 Apr 1998 00:32:23 GMT (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by d183-205.uoregon.edu (8.8.7/8.8.7) id RAA15248; Fri, 17 Apr 1998 17:32:20 -0700 (PDT) Message-ID: <19980417173220.12782@hydrogen.nike.efn.org> Date: Fri, 17 Apr 1998 17:32:20 -0700 From: John-Mark Gurney To: Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Re: Proposal: remove existing schg flags from make buildworld References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Robert Watson on Fri, Apr 17, 1998 at 04:44:29PM -0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-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 Robert Watson scribbled this message on Apr 17: > Currently, the use of schg flags can be a major hassle for those trying to > build secure systems. Performing a build world generates a set of schg > files that are hard to deal with in a secure environment (after all, they > are schg :). Rather than imposing the schg flags during the build, it > might be more appropriate to apply them only during the install. Even > blowing away my object tree is made difficult: just buildworld as a normal user... I've been doing this for close to a half year now.. and if this is such a secure environment, why are you doing this as root?? [...] > There is nothing gained by doing this -- the source is not protected, and > neither is the compiler :). Clearly on an install, it is useful to apply > schg (although previous discussion suggests that this is not the case with > the current arrangement :), but not during the build process. -- John-Mark Gurney Modem Rev/FAX: +1 541 346 9237 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 18 07:25:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA17164 for freebsd-security-outgoing; Sat, 18 Apr 1998 07:25:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from euthyphro.uchicago.edu (euthyphro.uchicago.edu [128.135.21.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA17158 for ; Sat, 18 Apr 1998 14:25:53 GMT (envelope-from sfarrell@phaedrus.uchicago.edu) Received: from phaedrus.uchicago.edu (phaedrus [128.135.21.10]) by euthyphro.uchicago.edu (8.8.6/8.8.4) with ESMTP id JAA09371; Sat, 18 Apr 1998 09:25:30 -0500 (CDT) Received: (from sfarrell@localhost) by phaedrus.uchicago.edu (8.8.8/8.8.5) id JAA15862; Sat, 18 Apr 1998 09:25:25 -0500 (CDT) To: "Jordan K. Hubbard" Cc: Brian Handy , "Matthew N. Dodd" , Matthew Hunt , dima@best.net, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions References: <14147.892853744@time.cdrom.com> From: stephen farrell Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 18 Apr 1998 09:25:25 -0500 In-Reply-To: "Jordan K. Hubbard"'s message of "Fri, 17 Apr 1998 15:55:44 -0700" Message-ID: <87iuo7ky0a.fsf@phaedrus.uchicago.edu> Lines: 20 X-Mailer: Gnus v5.6.3/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk "Jordan K. Hubbard" writes: > [Can we get this thread the ^&%@!$#!! out of -stable now please?] > > > Yep, and I maintain that for 99% of us, this was a *HUGE* step backwards. > > What would you have done instead? Add a question to the system installation procedure that asks whether login based restrictions should be employed. Explain that this is useful for multi-user sites mostly, and can be configured with the login.conf file. If this is a mostly a single user machine, or you are not concerned with others hogging resources, then choose "NO" now. -- Steve Farrell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 18 07:44:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA19709 for freebsd-security-outgoing; Sat, 18 Apr 1998 07:44:50 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from throne.rau.lv (mg@throne.rau.lv [159.148.112.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA19688 for ; Sat, 18 Apr 1998 14:44:39 GMT (envelope-from mg@throne.rau.lv) Received: from localhost (mg@localhost) by throne.rau.lv with SMTP id RAA25396 for ; Sat, 18 Apr 1998 17:50:47 +0300 (EEST) Posted-Date: Sat, 18 Apr 1998 17:50:47 +0300 (EEST) Date: Sat, 18 Apr 1998 17:50:46 +0300 (EEST) From: Michael Gulyaev To: freebsd-security@FreeBSD.ORG In-Reply-To: <87iuo7ky0a.fsf@phaedrus.uchicago.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk unsubscribe security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 18 09:15:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA05723 for freebsd-security-outgoing; Sat, 18 Apr 1998 09:15:34 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from uriela.in-berlin.de (uriela.in-berlin.de [192.109.42.147]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA05687 for ; Sat, 18 Apr 1998 16:15:25 GMT (envelope-from nortobor.nostromo.in-berlin.de!ripley@never.mind.de) Received: by uriela.in-berlin.de (/\oo/\ Smail3.1.29.1 #29.8) from never.never.mind.de (193.101.72.4) with smtp id m0yQaGs-000LuAC; Sat, 18 Apr 98 18:15 MET DST Received: by never.never.mind.de (linux Smail3.1.28.1 #1) id m0yQaGq-000ExyC; Sat, 18 Apr 98 18:15 MET DST Received: (from ripley@localhost) by nortobor.nostromo.in-berlin.de (8.8.7/8.8.7) id WAA06535; Fri, 17 Apr 1998 22:40:15 +0200 (CEST) (envelope-from ripley) Message-ID: <19980417224014.65058@nostromo.in-berlin.de> Date: Fri, 17 Apr 1998 22:40:14 +0200 From: "H. Eckert" To: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions References: <199804162302.BAA15315@ocean.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199804162302.BAA15315@ocean.campus.luth.se>; from Mikael Karpberg on Fri, Apr 17, 1998 at 01:02:22AM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, Apr 17, 1998 at 01:02:22AM +0200, Mikael Karpberg wrote: > It's easy to forget to frob all the 1000 small knobs that "you can frob > on YOUR machine if you want it secure". It's however quite easy to remember > to chmod it when you or one of your users gets annoyed at not being able to > read it. It annoys you the first time, but you su, chmod, and exit. Nothing > more to it. You simply will not forget to, because it will not let you. I agree that the "1000 small knobs" of customization is something to be avoided. So let's think on how we can centralize this kind of stuff in a friendly way so a concerned admin can easily browse through a security setup to have lots of knobs activated by doing something like "network=secure" in the config file. Think of the /etc/rc.conf that handles a lot of things. If we can have a friendly frontend program as has already been suggested that's even better. Greetings, Ripley -- http://www.in-berlin.de/User/nostromo/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 18 09:15:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA05768 for freebsd-security-outgoing; Sat, 18 Apr 1998 09:15:39 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from uriela.in-berlin.de (uriela.in-berlin.de [192.109.42.147]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA05736 for ; Sat, 18 Apr 1998 16:15:35 GMT (envelope-from nortobor.nostromo.in-berlin.de!ripley@never.mind.de) Received: by uriela.in-berlin.de (/\oo/\ Smail3.1.29.1 #29.8) from never.never.mind.de (193.101.72.4) with smtp id m0yQaGs-000LuHC; Sat, 18 Apr 98 18:15 MET DST Received: by never.never.mind.de (linux Smail3.1.28.1 #1) id m0yQaGr-000ExzC; Sat, 18 Apr 98 18:15 MET DST Received: (from ripley@localhost) by nortobor.nostromo.in-berlin.de (8.8.7/8.8.7) id WAA06547; Fri, 17 Apr 1998 22:47:17 +0200 (CEST) (envelope-from ripley) Message-ID: <19980417224716.41173@nostromo.in-berlin.de> Date: Fri, 17 Apr 1998 22:47:16 +0200 From: "H. Eckert" To: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions References: <199804170519.WAA12540@burka.rdy.com> <19980417105557.59439@deepo.prosa.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <19980417105557.59439@deepo.prosa.dk>; from Philippe Regnauld on Fri, Apr 17, 1998 at 10:55:57AM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, Apr 17, 1998 at 10:55:57AM +0200, Philippe Regnauld wrote: > Suggestion: how difficult would it be to have ipfw(8) respect > the securelevel to, for example, refuse to flush / alter > the ipfw list ? > > i.e.: all mods have to be tested before the securelevel is raised, > and once it is, only rebooting into single user on the console > allows you to change the filters. Actually I like the dynamically adaptable ipfw scheme a lot more than ipfilterd.conf on an Irix machine we have at work. This is a matter of flexibility. > We need write-protect notch on the hard-disks :-) There have been times where harddrives had this. But somehow a real switch seems to be out of fashion. ZipDisks have only the software write-protection... Since I started using 90mm floppies I trained myself to protect them immediately when ejecting a disk I don't want to write to again a few moments later. Greetings, Ripley -- http://www.in-berlin.de/User/nostromo/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 18 09:19:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06736 for freebsd-security-outgoing; Sat, 18 Apr 1998 09:19:09 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06715 for ; Sat, 18 Apr 1998 16:19:05 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA04012 for ; Sat, 18 Apr 1998 12:19:03 -0400 (EDT) Date: Sat, 18 Apr 1998 12:18:57 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: freebsd-security@FreeBSD.ORG Subject: suid/sgid programs Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-691075835-892916337=:15725" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk 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-691075835-892916337=:15725 Content-Type: TEXT/PLAIN; charset=US-ASCII One possible option for a security configuration program would be to allow the user to selectively enable/disable setuid programs on their machine. I have attached a list of suid and sgid programs found on a fairly default looking -stable machine from last night, roughly categorized into common sets. We note that it is particularly important that programs that are hard links of one another be in the same category, if the user is trying to enable/disable them :). My thoughts on choices for setuid were: 1) Disable setuid 2) Enable setuid, but restrict execution to wheel 3) Enable setuid for all In some cases (shutdown), option (2) is already the current arrangement. Depending on the system, policy for each set of binaries might vary. One thing I'd like to see in the final version is a distinction between "definition of policy" and "application of policy". I.e., The user runs one program to define their policy. This generates a config file that can now be applied to the machine (or other mahines). Someone suggested Dialog as an interface for doing this. This seems reasonable to me -- dialog does not look particularly hard to use :). Requiring X is clearly not the correct course of action. For sgid, it is not clear whether the two options aren't just 'enable' and 'disable', as we can't really change the group on them to limit use :). Also, there are a few suid/sgid programs that probably don't have to be -- ncrcontrol, for example. Most *control programs are not suid/sgid, and require the user to be uid0 to run them. Is there a reason for this difference here? We note also that a fairly large chunk of suid/sgid programs are UUCP programs -- something that a majority of FreeBSD users (I would guess?) do not use. In terms of reducing risk, disabling suid/sgid on these programs as part of a hardening process, if they are not needed, would be a great boon. The suid and sgid lists are formatted as follows: category:binary,binary... If I've missed any, please let me know. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ --0-691075835-892916337=:15725 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=suid Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Y3U6L3Vzci9iaW4vY3UNCm1hbjovdXNyL2Jpbi9tYW4NCnV1Y3A6L3Vzci9i aW4vdXVjcCwvdXNyL2Jpbi91dW5hbWUsL3Vzci9iaW4vdXVzdGF0LC91c3Iv YmluL3V1eCwvdXNyL2xpYmV4ZWMvdXVjcC91dWNpY28sL3Vzci9saWJleGVj L3V1Y3AvdXV4cXQNCnBlcmw6L3Vzci9iaW4vc3VpZHBlcmwsL3Vzci9iaW4v c3Blcmw0LjAzNg0KYXQ6L3Vzci9iaW4vYXQsL3Vzci9iaW4vYXRxLC91c3Iv YmluL2F0cm0sL3Vzci9iaW4vYmF0Y2gNCnBhc3N3ZDovdXNyL2Jpbi9jaHBh c3MsL3Vzci9iaW4vY2hmbiwvdXNyL2Jpbi9jaHNoLC91c3IvYmluL3lwY2hw YXNzLC91c3IvYmluL3lwY2hmbiwvdXNyL2Jpbi95cGNoc2gsL3Vzci9iaW4v bG9jaywvdXNyL2Jpbi9wYXNzd2QsL3Vzci9iaW4veXBwYXNzd2QNCnNrZXk6 L3Vzci9iaW4va2V5aW5mbywvdXNyL2Jpbi9rZXlpbml0DQpsb2dpbjovdXNy L2Jpbi9sb2dpbg0KcXVvdGE6L3Vzci9iaW4vcXVvdGENCnJzaDovdXNyL2Jp bi9ybG9naW4sL3Vzci9iaW4vcnNoLC9iaW4vcmNwDQpjcm9udGFiOi91c3Iv YmluL2Nyb250YWINCnN1Oi91c3IvYmluL3N1DQpscHI6L3Vzci9iaW4vbHBx LC91c3IvYmluL2xwciwvdXNyL2Jpbi9scHJtDQpzZW5kbWFpbDovdXNyL2Jp bi9uZXdhbGlhc2VzLC91c3IvYmluL21haWxxLC91c3IvYmluL2hvc3RzdGF0 LC91c3IvbGliZXhlYy9tYWlsLmxvY2FsLC91c3Ivc2Jpbi9zZW5kbWFpbCwv dXNyL3NiaW4vcHVyZ2VzdGF0DQprZXJiZXJvczovdXNyL2Jpbi9yZWdpc3Rl cg0KbXVsdGljYXN0Oi91c3Ivc2Jpbi9tcmluZm8sL3Vzci9zYmluL210cmFj ZQ0KcHBwc2xpcDovdXNyL3NiaW4vcHBwLC91c3Ivc2Jpbi9wcHBkLC91c3Iv c2Jpbi9zbGlwbG9naW4NCnRpbWVkOi91c3Ivc2Jpbi90aW1lZGMNCnBpbmc6 L3Vzci9zYmluL3RyYWNlcm91dGUsL3NiaW4vcGluZw0Kcm91dGU6L3NiaW4v cm91dGUNCnNodXRkb3duOi9zYmluL3NodXRkb3duDQoNCg== --0-691075835-892916337=:15725 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=sgid Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Y3U6L3Vzci9iaW4vY3UNCnV1Y3A6L3Vzci9iaW4vdXVzdGF0LC91c3IvbGli ZXhlYy91dWNwL3V1Y2ljbw0KZGY6L2Jpbi9kZg0Ka21lbTovYmluL3BzLC9z YmluL2NjZGNvbmZpZywvc2Jpbi9kbWVzZywvdXNyL2Jpbi9mc3RhdCwvdXNy L2Jpbi9pcGNzLC91c3IvYmluL25ldHN0YXQsL3Vzci9iaW4vbmZzc3RhdCwv dXNyL2Jpbi9zeXN0YXQsL3Vzci9iaW4vdG9wLC91c3IvYmluL3VwdGltZSwv dXNyL2Jpbi92bXN0YXQsL3Vzci9iaW4vdywvdXNyL3NiaW4vaW9zdGF0LC91 c3Ivc2Jpbi9uY3Jjb250cm9sLC91c3Ivc2Jpbi9wc3RhdCwvdXNyL3NiaW4v c3dhcGluZm8sL3Vzci9zYmluL3RycHQNCnR0eTovc2Jpbi9kdW1wLC9zYmlu L3JkdW1wLC9zYmluL3Jlc3RvcmUsL3NiaW4vcnJlc3RvcmUsL3Vzci9iaW4v d2FsbCwvdXNyL2Jpbi93cml0ZQ0KbHByOi91c3IvYmluL2xwcSwvdXNyL2Jp bi9scHIsL3Vzci9iaW4vbHBybSwvdXNyL3NiaW4vbHBjDQpnYW1lczovdXNy L2dhbWVzL2RtDQoNCg== --0-691075835-892916337=:15725-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 18 10:19:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21866 for freebsd-security-outgoing; Sat, 18 Apr 1998 10:19:15 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA21830 for ; Sat, 18 Apr 1998 17:19:04 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id NAA04751; Sat, 18 Apr 1998 13:19:00 -0400 (EDT) Date: Sat, 18 Apr 1998 13:18:54 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Philippe Regnauld cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <19980417105557.59439@deepo.prosa.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, 17 Apr 1998, Philippe Regnauld wrote: > Suggestion: how difficult would it be to have ipfw(8) respect > the securelevel to, for example, refuse to flush / alter > the ipfw list ? > > i.e.: all mods have to be tested before the securelevel is raised, > and once it is, only rebooting into single user on the console > allows you to change the filters. Having just browsed the kernel source a little, it looks like indeed this is currently implemented. The comment is a little obscure: /* only allow get calls if secure mode > 2 */ if (securelevel > 2) { if (m) (void)m_free(m); return(EPERM); But what it actually means is, only allow non-get calls if securemode > 2. The following indeed does restrict ipfw writing: thithle:/etc# sysctl -w kern.securelevel=50 kern.securelevel: -1 -> 50 thithle:/etc# thithle:/etc# ipfw list ... thithle:/etc# ipfw flush Are you sure? [yn] y ipfw: setsockopt(IP_FW_FLUSH): Operation not permitted thithle:/etc# ipfw add 01001 allow ip from any to any via lo0 01001 allow ip from any to any via lo0 ipfw: setsockopt(IP_FW_ADD): Operation not permitted The behavior seems to be correct already. One problem I'm seeing in a few places is a lack of clarity as to what various securelevels should imply. Part of the problem seems to be that it is a one-dimmensional name space. One thing that might be nice to see is a file flag that allows writes/etc at some securelevels, but not at others. Currently, the behavior seems to be that schg can be set at lower securelevels, but must be removed before writes can occur. At high levels, it simply can't be removed. A new flag might be desirable that allows changes at a lower securelevel, but prohibits them at a high one. This could be applied to config files, for example, allowing reconfiguration at securelevels 0, -1, but preventing configuration of certain key files (/etc/fstab?) when the system is actually running. Have I missed an existing flag that already works this way? :) Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 18 10:54:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA27364 for freebsd-security-outgoing; Sat, 18 Apr 1998 10:54:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA27346 for ; Sat, 18 Apr 1998 17:54:14 GMT (envelope-from patl@phoenix.volant.org) From: patl@phoenix.volant.org Received: from asimov.phoenix.volant.org [205.179.79.65] by phoenix.volant.org with smtp (Exim 1.62 #1) id 0yQboc-00061z-00; Sat, 18 Apr 1998 10:54:14 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id KAA11721; Sat, 18 Apr 1998 10:52:24 -0700 Date: Sat, 18 Apr 1998 10:52:24 -0700 (PDT) Reply-To: patl@phoenix.volant.org Subject: Re: kernel permissions To: "H. Eckert" cc: freebsd-security@FreeBSD.ORG In-Reply-To: <19980417224716.41173@nostromo.in-berlin.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > We need write-protect notch on the hard-disks :-) > > There have been times where harddrives had this. But somehow a > real switch seems to be out of fashion. ... I can remember the Good Old Days when disk drives had write protect switches. That't one of the few places where I believe the industry took a giant step backwards. BUT the good news is that there are some modern drives that still support this. I just bought a Micropolis 3391S (9GB, 7200 RPM, Fast SCSI/SCA. $495 at Disk Drive Depot/CSC) I was happily surprised to discover that it has a Write Protect jumper that could easily be connected to an external switch. We now return you to your regularly scheduled topic... -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 18 11:14:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00477 for freebsd-security-outgoing; Sat, 18 Apr 1998 11:14:27 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA00469 for ; Sat, 18 Apr 1998 18:14:19 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id OAA05407; Sat, 18 Apr 1998 14:13:35 -0400 (EDT) Date: Sat, 18 Apr 1998 14:13:29 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Mike Smith cc: freebsd-security@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. In-Reply-To: <199804180553.WAA00781@antipodes.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, 17 Apr 1998, Mike Smith wrote: > > On Thu, 16 Apr 1998, Mike Smith wrote: > > > Actually, what I want is a stub version of the LDAP client library that > > > can be linked into a few of the items that run early on (init, mount, > > > fsck, dhclient, etc), before the network is up. Once the net is up, > > > everything parametric ought to be indirected through a generic "get me > > > a parameter" API. > > > > See, so the reason I find this concerning is that it stores the > > configuration information (presumably) in a single repository, and the > > kernel enforcement of the security on this repository can't be made finer > > grained. > > The kernel has little or nothing of a say in the matter. If you stop a > moment and realise that the information in question may not even be > local to the system in question, you'll realise that access controls > have to be a part of the parameter store itself. > > Fortunately for your peace of mind, LDAP supports ACL controls. This may be the case for a DHCP-configured diskless client, but if I have a hard-configured web server running user CGI applications, I am far more interested in preventing any changes to key config files when the securelevel is >0. For example, I don't want key system binaries, the fstab file, etc, to be changed in a high securelevel, where a root compromise could affect them. The alternative I would accept would be the /etc portalfs daemon (to pick a paradigm for implementing this) to run "special" like init -- i.e., not allow debuggers to be attached after securelevel++, etc. Securelevels provide the kernel with the ability to protect itself, in an appropriately configured system. It's the whole supervisor-mode kernel vs. uid 0 difference. > > If the two approaches can be made compatible, I am all for a more sane > > configuration system :). If not, then I see problems. > > If we can't come up with an acceptable compromise, then naturally it's > not going to be accepted. One thing at a time - make it happen at all > first. 8) I think it is very much in the interest of FreeBSD to provide a consistent, clean, distributed configuration system. On the other hand, I don't want to see our chances of creating a secure firewall system shot either. :) A central configuration storage utility running in userland opens another opportunity for potential security problems. Perhaps if the database, when running locally, backed onto two different database files? One protected against write in a high securelevel, the other writable in the high securelevel? Fstab information, if stored locally in the unwritable file, would be retrieved before less secure local configs, or remote configs. And during boot, the securelevel-protected data would be first hit in a search for the data (which would, optionally, pass into less-secure and netdb modes). Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 18 16:11:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA22783 for freebsd-security-outgoing; Sat, 18 Apr 1998 16:11:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from nash.pr.mcs.net (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA22751 for ; Sat, 18 Apr 1998 23:11:12 GMT (envelope-from alex@nash.pr.mcs.net) Received: (from alex@localhost) by nash.pr.mcs.net (8.8.8/8.8.7) id SAA03638; Sat, 18 Apr 1998 18:10:07 -0500 (CDT) (envelope-from alex) Message-Id: <199804182310.SAA03638@nash.pr.mcs.net> Date: Sat, 18 Apr 1998 18:10:06 -0500 (CDT) From: Alex Nash Subject: Re: kernel permissions To: robert+freebsd@cyrus.watson.org cc: regnauld@deepo.prosa.dk, freebsd-security@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On 18 Apr, Robert Watson wrote: > On Fri, 17 Apr 1998, Philippe Regnauld wrote: > >> Suggestion: how difficult would it be to have ipfw(8) respect >> the securelevel to, for example, refuse to flush / alter >> the ipfw list ? >> >> i.e.: all mods have to be tested before the securelevel is raised, >> and once it is, only rebooting into single user on the console >> allows you to change the filters. We've had this for about two years now. > Having just browsed the kernel source a little, it looks like indeed this > is currently implemented. The comment is a little obscure: > > /* only allow get calls if secure mode > 2 */ > if (securelevel > 2) { > if (m) (void)m_free(m); > return(EPERM); > > But what it actually means is, only allow non-get calls if securemode > 2. Huh? It means what it says: only allow get calls if securelevel > 2. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 18 16:24:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA25045 for freebsd-security-outgoing; Sat, 18 Apr 1998 16:24:55 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA25036 for ; Sat, 18 Apr 1998 23:24:51 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id TAA10055; Sat, 18 Apr 1998 19:24:46 -0400 (EDT) Date: Sat, 18 Apr 1998 19:24:38 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Alex Nash cc: regnauld@deepo.prosa.dk, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <199804182310.SAA03638@nash.pr.mcs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sat, 18 Apr 1998, Alex Nash wrote: > > Having just browsed the kernel source a little, it looks like indeed this > > is currently implemented. The comment is a little obscure: > > > > /* only allow get calls if secure mode > 2 */ > > if (securelevel > 2) { > > if (m) (void)m_free(m); > > return(EPERM); > > > > But what it actually means is, only allow non-get calls if securemode > 2. > > Huh? It means what it says: only allow get calls if securelevel > 2. Ugh. Combination of two problems. First, I interpretted the comment to mean that get calls would only be allowed if the securelevel was > 2, rather than the coded only get calls being allowed if securelevel was > 2. I then promptly typed in the wrong thing in my "but what this actually means", and meant to type, "But what it actually means is, only allow non-get calls if securemove < 2". The comment I believe can be interpretted both ways (I asked a few people here to come read the comment and tell me which they thought it was). On the otherhand, my typo is clearly incorrect. Either way, who cares, the code is right. Logically ambiguous language :). Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message