From owner-freebsd-security Sun Oct 17 0:28: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from sonet.crimea.ua (OTC-sl3-FLY.CRIS.NET [212.110.136.71]) by hub.freebsd.org (Postfix) with ESMTP id 8B9C714D39 for ; Sun, 17 Oct 1999 00:27:08 -0700 (PDT) (envelope-from phantom@scorpion.crimea.ua) Received: (from uucp@localhost) by sonet.crimea.ua (8.8.8/8.8.8) with UUCP id KAA28334; Sun, 17 Oct 1999 10:28:08 +0400 (MSD) (envelope-from phantom@scorpion.crimea.ua) Received: (from phantom@localhost) by scorpion.crimea.ua (8.8.8/8.8.5+ssl+keepalive) id KAA18371; Sun, 17 Oct 1999 10:05:27 +0400 (MSD) Date: Sun, 17 Oct 1999 10:05:27 +0400 From: Alexey Zelkin To: Sue Blake Cc: freebsd-security@FreeBSD.ORG Subject: Re: allowing telnet from locked terminal Message-ID: <19991017100527.B14344@scorpion.crimea.ua> References: <19991017070610.E12725@welearn.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: <19991017070610.E12725@welearn.com.au> X-Operating-System: FreeBSD 2.2.7-RELEASE i386 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi, On Sun, Oct 17, 1999 at 07:06:12AM +1000, Sue Blake wrote: > Is there some quick way to remove convenient access to all but one > virtual console whenever I leave the room? man 5 login.access ? -- /* Alexey Zelkin && phantom@cris.net */ /* Tavric National University && phantom@crimea.edu */ /* http://www.ccssu.crimea.ua/~phantom && phantom@FreeBSD.org */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 10:39:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id 3F3A414F1D for ; Sun, 17 Oct 1999 10:39:28 -0700 (PDT) (envelope-from danderse@faith.cs.utah.edu) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id LAA21629; Sun, 17 Oct 1999 11:39:10 -0600 (MDT) From: David G Andersen Message-Id: <199910171739.LAA21629@faith.cs.utah.edu> Subject: Re: FreeSSH To: jdn@acp.qiv.com (Jay Nelson) Date: Sun, 17 Oct 1999 11:39:10 -0600 (MDT) Cc: Cy.Schubert@uumail.gov.bc.ca, jwyatt@rwsystems.net, glewis@trc.adelaide.edu.au, freebsd-security@FreeBSD.ORG In-Reply-To: from "Jay Nelson" at Oct 16, 99 07:19:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Given that it may take a lot of re-engineering to change the build process to not install the packages in the first place, what if we changed the installation to create a "virtual" package entry for them, so that an interested sysadmin could then use pkg_delete to nuke the components of the package? It would be easy enough to generate the packing list at compile time, and then stuff it in a known location at build time. This wouldn't save download time or initial space, but it *would* help make the security goal easier, from my point of view. -Dave Lo and behold, Jay Nelson once said: > > On Sat, 16 Oct 1999, Cy Schubert - ITSD Open Systems Group wrote: > > [snip] > > >... I think that > >the bloat caused by UUCP, YP, NFS, and Sendmail is small. For example > > I heartily agree. The nice thing about a "standard" system is that > there are features you can count on. Many are not used on the typical > installation, yet I rarely remove them unless there is a compelling > reason -- things change over time. > > Hell -- if we're going to get rid of "bloat", let's get rid of grep > and sed, since very few newbies understand regular expressions -- or > the man pages -- few read them and they take up a _huge_ amount of > space;) > > (Only my 2 bits) > > -- Jay > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 11: 7: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from megaweapon.zigg.com (megaweapon.zigg.com [206.114.60.8]) by hub.freebsd.org (Postfix) with ESMTP id 1206014A2C for ; Sun, 17 Oct 1999 11:06:55 -0700 (PDT) (envelope-from matt@zigg.com) Received: from localhost (matt@localhost) by megaweapon.zigg.com (8.9.3/8.9.3) with ESMTP id OAA10673; Sun, 17 Oct 1999 14:06:33 -0400 (EDT) (envelope-from matt@zigg.com) Date: Sun, 17 Oct 1999 14:06:32 -0400 (EDT) From: Matt Behrens To: David G Andersen Cc: Jay Nelson , Cy.Schubert@uumail.gov.bc.ca, jwyatt@rwsystems.net, glewis@trc.adelaide.edu.au, freebsd-security@FreeBSD.ORG Subject: Re: FreeSSH In-Reply-To: <199910171739.LAA21629@faith.cs.utah.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 17 Oct 1999, David G Andersen wrote: : Given that it may take a lot of re-engineering to change the build process : to not install the packages in the first place, what if we changed the : installation to create a "virtual" package entry for them, so that : an interested sysadmin could then use pkg_delete to nuke the components of : the package? It would be easy enough to generate the packing list at : compile time, and then stuff it in a known location at build time. : : This wouldn't save download time or initial space, but it *would* : help make the security goal easier, from my point of view. That would probably do pretty well for the initial install, but it unfortunately doesn't address the problem of how to stop make world from happily replacing all of the newly-missing components. It is a neat idea, though. Matt Behrens Owner/Administrator, zigg.com Chief Engineer, Nameless IRC Network To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 12: 9: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from dt050n71.san.rr.com (dt050n71.san.rr.com [204.210.31.113]) by hub.freebsd.org (Postfix) with ESMTP id 265FD14BD3 for ; Sun, 17 Oct 1999 12:08:41 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt050n71.san.rr.com (8.9.3/8.8.8) with ESMTP id MAA09819; Sun, 17 Oct 1999 12:06:21 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <380A1E2C.CCA326F5@gorean.org> Date: Sun, 17 Oct 1999 12:06:20 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT-0927 i386) X-Accept-Language: en MIME-Version: 1.0 To: Justin Wells Cc: Antoine Beaupre , Mike Nowlin , "Rashid N. Achilov" , freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin Wells wrote: > The problem with securelevel, in my mind, is that an attacker who > got root would simply write stuff into the /etc/rc scripts and then > force the machine to reboot. > > It would be very difficult to set the schg flag on every possible > file that gets run as root during bootup. > > Does anyone have any clever solutions? Mount / read only. Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 12:52:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from pogo.caustic.org (pogo.caustic.org [216.69.69.123]) by hub.freebsd.org (Postfix) with ESMTP id 5F58A14A2D for ; Sun, 17 Oct 1999 12:52:14 -0700 (PDT) (envelope-from jan@caustic.org) Received: from localhost (jan@localhost) by pogo.caustic.org (8.9.3/ignatz) with ESMTP id MAA05800; Sun, 17 Oct 1999 12:51:19 -0700 (PDT) Date: Sun, 17 Oct 1999 12:51:19 -0700 (PDT) From: "f.johan.beisser" To: Alex Charalabidis Cc: tom brown , freebsd-security@FreeBSD.ORG Subject: Re: General securiy of vanilla install WAS [FreeSSH] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -- on inetd -- actually, i think that most experienced freebsd folks would just vi /etc/rc.conf and add the line 'inetd_enable="NO"'. yes, there should be a simple option to have this enabled or disabled from /stand/sysinstall. perhaps a simple check menu for each of the services in a row.. and at the top something for the inetd? -- vanilla install security -- in general, disabling everything in a vanilla install might be counter productive for the average user, since most folks who install freebsd don't use it as a workstation. they tend to use it as a server (this is my own bias, since 80% of the FreeBSD boxen that i build are servers anyway), and need most of the services from the inetd. the first installs i do are: ssh (we have a happy tarball already made, and has all the configurations there), shells we might need, edit down the inetd.conf (or dissable it). it doesn't take me much more than 30 minutes per machine for specific installs, or about 15 minutes for a general install. on workstation installs, i dissable the inetd completely, then do the standard installs from there. X and such adds to the time it takes to get the install done. of course, this is just my stupid $0.02 worth on this. on another note, has anyone considered replacing sendmail in the base dist of FBSD? see ya all at the con, -- jan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 13:35:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id 23AFA14C88 for ; Sun, 17 Oct 1999 13:35:51 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id PAA14102; Sun, 17 Oct 1999 15:35:49 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from dial-217.tnt1.rac.cyberlynk.net(209.224.182.217) by peak.mountin.net via smap (V1.3) id sma014100; Sun Oct 17 15:35:39 1999 Message-Id: <3.0.3.32.19991017152906.00aa7100@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 17 Oct 1999 15:29:06 -0500 To: Alex Charalabidis From: "Jeffrey J. Mountin" Subject: Re: General securiy of vanilla install WAS [FreeSSH] Cc: freebsd-security@FreeBSD.ORG In-Reply-To: References: <19991017043046.5909.rocketmail@web115.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:11 AM 10/17/99 -0500, Alex Charalabidis wrote: >On Sat, 16 Oct 1999, tom brown wrote: > >> I think we've lost the direction here somewhere. >> This started as a conversation about >> 'security'options. >> >> But something should be done to allow the less >> experienced users roll out a box that can sit >> unprotected on the net. Personal experience has >> demonstrated that many insecure installs are out there >> running in production enviroments. People often seem >> to have the impression that unix is secure, but they >> don't understand what they need to do to make it that >> way. >> >This ought to be addressed in future releases. I don't remember off-hand >which services are enabled by default on a stock installation but I do >remember always having to shut down a few on every new machine I install >FreeBSD on (which means most machines that hit my desk). Can almost guess that any commiter is going to address this by stating that less experience users (or admins) *should* know better. Anyone expecting to just install and drop it off the wire should get what they deserve for their minimal effort. To be fair, we could have a firewall distrubution, but even so it would be a compromize and still require a certain level of knowledge to do right. >Somewhere in this thread, someone mentioned installing tcsh/bash and ssh >as the first tasks on a new box. Wrong. The first thing we do is vi >inetd.conf and shut down unneeded services. Those who don't know enough to >do so are SOL. Sure, they need to learn but letting them learn by having >their machines cracked is counterproductive. Not wrong. Why connect to the network before the system is ready. ;) >Granted, it is by far not as bad as it is with certain eponymous Linux >distributions that come so service-happy it's scary, but there are >concerns about new FreeBSD installations too. New users don't need the >services (and shouldn't be running them), experienced users would >rather enable what they need themselves. It's better than it used to be. Either services in inetd.conf should *all* be commented or inetd should not be started in rc.conf, along with sendmail. AFAICR, sendmail is on since it is so commonly used and to avoid newbies asking about it, but then they will ask anyways and so we have these little discussions from time to time. >Sounds very reasonable. Though maybe "run services" should be off by >default. Trouble is new users. All more experienced types know what they (don't) want, so where things are is more of a compromize. The main reason for some pushing for UUCP as an option is the world writable directory. If logins or ftp are allowed on a *stock* system then there's a nice little place that everyone can access. A more granulated distribution means less to worry about and a minimalist approach can be taken. New users could just opt for a "basic/complete" package list. my .02 Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 13:41:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id 57A5F14E78 for ; Sun, 17 Oct 1999 13:41:30 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id PAA14149; Sun, 17 Oct 1999 15:41:21 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from dial-217.tnt1.rac.cyberlynk.net(209.224.182.217) by peak.mountin.net via smap (V1.3) id sma014147; Sun Oct 17 15:40:59 1999 Message-Id: <3.0.3.32.19991017153426.00b8d410@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 17 Oct 1999 15:34:26 -0500 To: Matt Behrens From: "Jeffrey J. Mountin" Subject: Re: FreeSSH Cc: freebsd-security@FreeBSD.ORG In-Reply-To: References: <199910171739.LAA21629@faith.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:06 PM 10/17/99 -0400, Matt Behrens wrote: >That would probably do pretty well for the initial install, but it >unfortunately doesn't address the problem of how to stop make world >from happily replacing all of the newly-missing components. Then 'make installworld' would have to check and honor what is/isn't in /var/db/pkg/system (seems like a good place). >It is a neat idea, though. Yeah, and I still think it should be done from the building side first and not the install, as my prior post to the this thread suggested. Should that prove difficult, then going the other way means we just do what we have been doing and deal with them after installworld is done. Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 15: 1:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from fever.semiotek.com (H253.C225.tor.velocet.net [216.126.82.253]) by hub.freebsd.org (Postfix) with ESMTP id 76B7F14C8C for ; Sun, 17 Oct 1999 15:01:42 -0700 (PDT) (envelope-from jread@fever.semiotek.com) Received: (from jread@localhost) by fever.semiotek.com (8.9.3/8.9.3) id SAA10070; Sun, 17 Oct 1999 18:02:25 -0400 (EDT) (envelope-from jread) Date: Sun, 17 Oct 1999 18:02:25 -0400 From: Justin Wells To: "Jeffrey J. Mountin" Cc: Alex Charalabidis , freebsd-security@FreeBSD.ORG Subject: Re: General securiy of vanilla install WAS [FreeSSH] Message-ID: <19991017180225.A9804@semiotek.com> References: <19991017043046.5909.rocketmail@web115.yahoomail.com> <3.0.3.32.19991017152906.00aa7100@207.227.119.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <3.0.3.32.19991017152906.00aa7100@207.227.119.2> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Oct 17, 1999 at 03:29:06PM -0500, Jeffrey J. Mountin wrote: > Anyone expecting to just install and drop it off the wire should get what > they deserve for their minimal effort. > To be fair, we could have a firewall distrubution, but even so it would be > a compromize and still require a certain level of knowledge to do right. A simple firewall would go a long way. By default allow everything outbound and nothing inbound. Or allow only inbound www, ssh, identd, passive ftp, and smtp--so people don't ask why they aren't allowed on IRC, can't FTP the dists, can't see their website, and don't get their mail. The firewall configuration file should be well commented, and there should be a loud message in the install explaining that it's there. > >Somewhere in this thread, someone mentioned installing tcsh/bash and ssh > >as the first tasks on a new box. Wrong. The first thing we do is vi > >inetd.conf and shut down unneeded services. Those who don't know enough to > >do so are SOL. Sure, they need to learn but letting them learn by having > >their machines cracked is counterproductive. > > Not wrong. Why connect to the network before the system is ready. ;) The first thing I do is bring up the firewall :-) The first thing I install is "screen" so that I can poke around in the background while "make world" is running in single user mode. > It's better than it used to be. Either services in inetd.conf should *all* > be commented or inetd should not be started in rc.conf, along with > sendmail. AFAICR, sendmail is on since it is so commonly used and to avoid > newbies asking about it, but then they will ask anyways and so we have > these little discussions from time to time. I love those old Slackware systems that used to install with 'ps' and 'netstat' running out of inetd. > Trouble is new users. All more experienced types know what they (don't) > want, so where things are is more of a compromize. However, most new users think that they want to have telnetd installed, and since it is installed by default, they think it must be OK. If they had to turn it on, it might occur to them that cleartext protocols and public networks don't mix. Especially if a comment in inetd.conf said so :-) Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 16:55: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from fever.semiotek.com (H253.C225.tor.velocet.net [216.126.82.253]) by hub.freebsd.org (Postfix) with ESMTP id B1C9914CC7; Sun, 17 Oct 1999 16:54:57 -0700 (PDT) (envelope-from jread@fever.semiotek.com) Received: (from jread@localhost) by fever.semiotek.com (8.9.3/8.9.3) id TAA11109; Sun, 17 Oct 1999 19:56:06 -0400 (EDT) (envelope-from jread) Date: Sun, 17 Oct 1999 19:56:06 -0400 From: Justin Wells To: freebsd-security@freebsd.org Cc: freebsd-stable@freebsd.org Subject: cannot buildworld under securelevel Message-ID: <19991017195606.A11040@semiotek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, I decided to play with some FreeBSD security stuff, so the other day I set my system to run in a securelevel. After I got that working OK, I decided to give "jail" a try, so I went and grabbed the patches for stable, applied them to my source tree, and did a "make buildworld". Guess what? It failed. The temporary object files in /usr/obj/usr/src/tmp/usr/lib have been marked schg, so buildworld fails. I wouldn't expect to be able to do a "make installworld" running under a securelevel--in fact, I would expect I'd have to be in single user mode. But I don't want to take my system down to single user mode for the duration of the entire "make world" compilation. I want to do the compile, drop to single user, install the new world, and reboot. It really bugs me that I have to take my system down for a long time in order to build the world. These temporary files should not be schg. Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 19:47:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id A860514EAA for ; Sun, 17 Oct 1999 19:47:24 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id VAA15595; Sun, 17 Oct 1999 21:47:22 -0500 (CDT) (envelope-from jeff-ml@mountin.net) Received: from dial-224.tnt1.rac.cyberlynk.net(209.224.182.224) by peak.mountin.net via smap (V1.3) id sma015592; Sun Oct 17 21:46:52 1999 Message-Id: <3.0.3.32.19991017213959.016c1be0@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 17 Oct 1999 21:39:59 -0500 To: Justin Wells From: "Jeffrey J. Mountin" Subject: Re: General securiy of vanilla install WAS [FreeSSH] Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <19991017180225.A9804@semiotek.com> References: <3.0.3.32.19991017152906.00aa7100@207.227.119.2> <19991017043046.5909.rocketmail@web115.yahoomail.com> <3.0.3.32.19991017152906.00aa7100@207.227.119.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 06:02 PM 10/17/99 -0400, Justin Wells wrote: >A simple firewall would go a long way. By default allow everything >outbound and nothing inbound. Or allow only inbound www, ssh, identd, >passive ftp, and smtp--so people don't ask why they aren't allowed >on IRC, can't FTP the dists, can't see their website, and don't get >their mail. > >The firewall configuration file should be well commented, and there >should be a loud message in the install explaining that it's there. But then any comments documentation need to be *read* in the first place to be useful. >The first thing I do is bring up the firewall :-) The first thing I >install is "screen" so that I can poke around in the background while >"make world" is running in single user mode. The first thing I do is crosslink to my development server. No need to build and is current or -stable in this case. ;) >I love those old Slackware systems that used to install with 'ps' >and 'netstat' running out of inetd. No comment. Tinkered with Slackware in '94 last and haven't since. >However, most new users think that they want to have telnetd installed, >and since it is installed by default, they think it must be OK. If they >had to turn it on, it might occur to them that cleartext protocols and >public networks don't mix. Especially if a comment in inetd.conf said >so :-) Frankly they should read a book, man pages, documentation, etc. Explaining with comments is not the way, IMO. You are are talking about an end user, possibly at home, that isn't likely to be deploying a production server and might not even know about inetd.conf at all or man . In this case that "firewall distribution" that doesn't allow incoming connections would be a Good Thing for them. Think less time should be spent on what we want and don't want, but rather some mechanisms (or ideas for them) that allow for a finer granularity for initial installs and builds. Would be nice if buildworld would skip making things that aren't going to be installed, but that is a bit more of a problem and might cost some flexibility. Consider that one system could build everything, then is used to install only what is desired to other systems. Makes sense. Not building everything would speed up the build process. Then again this means that some flags would need to be honored by installworld and not buildworld. More complexity. Think I'll shut up and dig around a bit, but looks pretty much beyond me at this point. Ugly hacks don't count. Some way of moving all the files needed for say NIS to their own subdir under /usr/src might work. Makes for more clutter. With UUCP there is mtree needing changes to the input files. Create the files on the fly then. Then there are depandancies, etc, etc, etc... making for a big project. Somehow I just don't this happening any time soon. Would appreciate any "how" input. No "what" or "why" unless the person *really* knows the build process. Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 20:38:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id 9DF3714C25; Sun, 17 Oct 1999 20:38:36 -0700 (PDT) (envelope-from cdf.lists@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1016) id 6C2EC9B22; Sun, 17 Oct 1999 20:06:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id 5FB77BA1C; Sun, 17 Oct 1999 20:06:41 -0400 (EDT) Date: Sun, 17 Oct 1999 20:06:41 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: cdf.lists@pawn.primelocation.net To: Justin Wells Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: cannot buildworld under securelevel In-Reply-To: <19991017195606.A11040@semiotek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 17 Oct 1999, Justin Wells wrote: > It really bugs me that I have to take my system down for a long time > in order to build the world. These temporary files should not be schg. > You might consider making use of MAKEOBJDIRPREFIX to specify a directory other than /usr/obj to use...and you can always remove everything else in /usr/obj if you need the room. Also, -current doesn't schg anything in /usr/obj (if it's any consolation). ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Oct 17 23:48: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from fever.semiotek.com (H253.C225.tor.velocet.net [216.126.82.253]) by hub.freebsd.org (Postfix) with ESMTP id 3951014A2A for ; Sun, 17 Oct 1999 23:47:51 -0700 (PDT) (envelope-from jread@fever.semiotek.com) Received: (from jread@localhost) by fever.semiotek.com (8.9.3/8.9.3) id CAA00790; Mon, 18 Oct 1999 02:47:05 -0400 (EDT) (envelope-from jread) Date: Mon, 18 Oct 1999 02:47:05 -0400 From: Justin Wells To: Doug Cc: Justin Wells , Antoine Beaupre , Mike Nowlin , "Rashid N. Achilov" , freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X Message-ID: <19991018024704.A512@semiotek.com> References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <380A1E2C.CCA326F5@gorean.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Oct 17, 1999 at 12:06:20PM -0700, Doug wrote: > > The problem with securelevel, in my mind, is that an attacker who > > got root would simply write stuff into the /etc/rc scripts and then > > force the machine to reboot. ... > > Does anyone have any clever solutions? > > Mount / read only. That is clever. I even thought it was work, and tried it. However, there are a couple of problems: 1) securelevel does not stop root from remounting / read-write, since mount is specifically excepted (I tried it too, I was able to do a "mount -u -o rw /" at securelevel 3 as root) 2) mounting / read only is nasty anyway, since you lose the ability to chown /dev/tty* which makes some things act very weird (many programs expect you will own your tty or else they get angry) So, any more clever suggestions? Maybe at securelevel 3 you should not be allowed to change the mount table either (no mounting and no umounting, period). That and a solution to the tty problem would make things fairly secure. Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 0:55:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 016D614C18 for ; Mon, 18 Oct 1999 00:55:45 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id JAA43151; Mon, 18 Oct 1999 09:55:33 +0200 (CEST) (envelope-from des) To: Justin Wells Cc: Doug , Antoine Beaupre , Mike Nowlin , "Rashid N. Achilov" , freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> From: Dag-Erling Smorgrav Date: 18 Oct 1999 09:55:32 +0200 In-Reply-To: Justin Wells's message of "Mon, 18 Oct 1999 02:47:05 -0400" Message-ID: Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin Wells writes: > 1) securelevel does not stop root from remounting / read-write, > since mount is specifically excepted (I tried it too, I was > able to do a "mount -u -o rw /" at securelevel 3 as root) Well, then, fix mount(8) so it won't run at high securelevels. You know where to find the source code. > 2) mounting / read only is nasty anyway, since you lose the > ability to chown /dev/tty* which makes some things act > very weird (many programs expect you will own your tty > or else they get angry) Use DEVFS, or union-mount an MFS on top of /dev. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 1:31: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from fever.semiotek.com (H253.C225.tor.velocet.net [216.126.82.253]) by hub.freebsd.org (Postfix) with ESMTP id 8B0AE14DDC for ; Mon, 18 Oct 1999 01:31:07 -0700 (PDT) (envelope-from jread@fever.semiotek.com) Received: (from jread@localhost) by fever.semiotek.com (8.9.3/8.9.3) id EAA01852; Mon, 18 Oct 1999 04:30:39 -0400 (EDT) (envelope-from jread) Date: Mon, 18 Oct 1999 04:30:39 -0400 From: Justin Wells To: Dag-Erling Smorgrav Cc: Justin Wells , Doug , Antoine Beaupre , Mike Nowlin , "Rashid N. Achilov" , freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X Message-ID: <19991018043039.B1711@semiotek.com> References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Oct 18, 1999 at 09:55:32AM +0200, Dag-Erling Smorgrav wrote: > Justin Wells writes: > > 1) securelevel does not stop root from remounting / read-write, > > since mount is specifically excepted (I tried it too, I was > > able to do a "mount -u -o rw /" at securelevel 3 as root) > > Well, then, fix mount(8) so it won't run at high securelevels. You > know where to find the source code. It's mount(2) that has to be fixed. I suppose I could go and look at it, but I'm not confident that I understand all the different implications of the securelevel stuff at that level. Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 1:57:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 97AD714CB5 for ; Mon, 18 Oct 1999 01:57:10 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA43413; Mon, 18 Oct 1999 10:56:51 +0200 (CEST) (envelope-from des) To: Justin Wells Cc: Doug , Antoine Beaupre , Mike Nowlin , "Rashid N. Achilov" , freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> From: Dag-Erling Smorgrav Date: 18 Oct 1999 10:56:51 +0200 In-Reply-To: Justin Wells's message of "Mon, 18 Oct 1999 04:30:39 -0400" Message-ID: Lines: 47 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin Wells writes: > On Mon, Oct 18, 1999 at 09:55:32AM +0200, Dag-Erling Smorgrav wrote: > > Well, then, fix mount(8) so it won't run at high securelevels. You > > know where to find the source code. > It's mount(2) that has to be fixed. I suppose I could go and look at > it, but I'm not confident that I understand all the different > implications of the securelevel stuff at that level. Here's an untested patch for -CURRENT which will make mount(2) fail with EPERM if running at securelevel 4 or higher. Took me all of three minutes to throw together. Index: vfs_syscalls.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.138 diff -u -r1.138 vfs_syscalls.c --- vfs_syscalls.c 1999/10/03 12:18:14 1.138 +++ vfs_syscalls.c 1999/10/18 08:52:56 @@ -123,6 +123,8 @@ if (usermount == 0 && (error = suser(p))) return (error); + if (securelevel > 3) + return (EPERM); /* * Do not allow NFS export by non-root users. */ I'm starting to think that secure levels should be implemented as bitmasks, with one bit for each operation or group of operation to be allowed or denied (0 = allow, 1 = deny). The if statement above could be rewritten as: if (securemask & SEC_MOUNT) return (EPERM); Using a simple bitmask might be too simple though (it would restrict us to 32 or 64 distinct operations), so we might want to hide the actual implementation behind a function call or macro: if (!sec_permitted(SEC_MOUNT)) return (EPERM); DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 2: 9:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B6EFC14BC3; Mon, 18 Oct 1999 02:09:23 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA43443; Mon, 18 Oct 1999 11:09:10 +0200 (CEST) (envelope-from des) To: Justin Wells Cc: freebsd-arch@FreeBSD.ORG Subject: Re: kern.securelevel and X References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> From: Dag-Erling Smorgrav Date: 18 Oct 1999 11:09:09 +0200 In-Reply-To: Dag-Erling Smorgrav's message of "18 Oct 1999 10:56:51 +0200" Message-ID: Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dag-Erling Smorgrav writes: > I'm starting to think that secure levels should be implemented as > bitmasks, with one bit for each operation or group of operation to be > allowed or denied (0 = allow, 1 = deny). The if statement above could > be rewritten as: > > if (securemask & SEC_MOUNT) > return (EPERM); > > Using a simple bitmask might be too simple though (it would restrict > us to 32 or 64 distinct operations), so we might want to hide the > actual implementation behind a function call or macro: > > if (!sec_permitted(SEC_MOUNT)) > return (EPERM); I'm thinking this might be -arch material. Do we want to do this? I think it can be done rather painlessly, and backwards compatibility with kern.securelevel should be easy to provide. The same mechanism can be used to implement process- or user-level capabilities, maybe leading us to merge (the hypothetical) sec_permitted() with suser(). After all, they're just two different ways of asking "is this ol' joe even *allowed* to do this?" DES (patches... must... write... patches...) -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 7: 6:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id C4647150D8 for ; Mon, 18 Oct 1999 07:06:43 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from bone.nectar.com (bone.nectar.com [10.0.0.105]) by gw.nectar.com (Postfix) with ESMTP id 0FC34C008; Mon, 18 Oct 1999 09:06:38 -0500 (CDT) Received: from bone.nectar.com (localhost [127.0.0.1]) by bone.nectar.com (Postfix) with ESMTP id E32831DA3; Mon, 18 Oct 1999 09:06:40 -0500 (CDT) X-Mailer: exmh version 2.1.0 09/18/1999 X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-rsa.txt X-PGP-DSSfprint: AB2F 8D71 A4F4 467D 352E 8A41 5D79 22E4 71A2 8C73 X-PGP-DHfprint: 2D50 12E5 AB38 60BA AF4B 0778 7242 4460 1C32 F6B1 X-PGP-DH-DSSkey: http://www.nectar.com/nectar-dh-dss.txt From: Jacques Vidrine To: Dag-Erling Smorgrav Cc: freebsd-security@FreeBSD.ORG In-reply-to: References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> Subject: Re: kern.securelevel and X Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Oct 1999 09:06:40 -0500 Message-Id: <19991018140640.E32831DA3@bone.nectar.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 18 October 1999 at 10:56, Dag-Erling Smorgrav wrote: [snip] > I'm starting to think that secure levels should be implemented as > bitmasks, with one bit for each operation or group of operation to be > allowed or denied (0 = allow, 1 = deny). The if statement above could > be rewritten as: > > if (securemask & SEC_MOUNT) > return (EPERM); > > Using a simple bitmask might be too simple though (it would restrict > us to 32 or 64 distinct operations), so we might want to hide the > actual implementation behind a function call or macro: > > if (!sec_permitted(SEC_MOUNT)) > return (EPERM); I've been thinking about something similar for suser, so that all uses of superuser privileges can be audited. For example, some hypothetical suser2 API that takes as one argument a constant specifying the category: int setuid(...) { ... error = suser2(p, SUSER_CREDS) ... } only for this to be truly useful, all calls to suser would have to be changed to suser2. This is the same kind of thing that DES is demonstrating above with the hypothetical sec_permitted. Chatting with DES on IRC, it seems to me that all this stuff (jail, auditing, securelevel) needs to fit together. Further, I feel like most (all) calls to suser or what have you in the top of the kernel could be covered if we made the granularity == syscall. This would break some abstraction, but if our hypothetical new suser or sec_permitted ``knew'' it was being called in the top of the kernel and ``knew'' what the current syscall was, our operations could just be table lookups. And especially for suser, we could tweak securelevel and jail stuff without having to modify the call to suser. -- Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 7:22:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 700EE14A16 for ; Mon, 18 Oct 1999 07:22:10 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA44285; Mon, 18 Oct 1999 16:21:52 +0200 (CEST) (envelope-from des) To: Jacques Vidrine Cc: freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> <19991018140640.E32831DA3@bone.nectar.com> From: Dag-Erling Smorgrav Date: 18 Oct 1999 16:21:51 +0200 In-Reply-To: Jacques Vidrine's message of "Mon, 18 Oct 1999 09:06:40 -0500" Message-ID: Lines: 8 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jacques Vidrine writes: > I've been thinking about something similar for suser, [...] Please move this to -arch. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 8: 2:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from fever.semiotek.com (H253.C225.tor.velocet.net [216.126.82.253]) by hub.freebsd.org (Postfix) with ESMTP id 4778F14BC2 for ; Mon, 18 Oct 1999 08:02:14 -0700 (PDT) (envelope-from jread@fever.semiotek.com) Received: (from jread@localhost) by fever.semiotek.com (8.9.3/8.9.3) id LAA03931; Mon, 18 Oct 1999 11:01:13 -0400 (EDT) (envelope-from jread) Date: Mon, 18 Oct 1999 11:01:13 -0400 From: Justin Wells To: Dag-Erling Smorgrav Cc: Justin Wells , Doug , Antoine Beaupre , Mike Nowlin , "Rashid N. Achilov" , freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X Message-ID: <19991018110113.A3888@semiotek.com> References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OK... but why was mount excepted in the first place? What I meant by "not confident that I understand all the different implications" is that I don't know what the reason for excluding mount was in the first place. Justin On Mon, Oct 18, 1999 at 10:56:51AM +0200, Dag-Erling Smorgrav wrote: > Justin Wells writes: > > On Mon, Oct 18, 1999 at 09:55:32AM +0200, Dag-Erling Smorgrav wrote: > > > Well, then, fix mount(8) so it won't run at high securelevels. You > > > know where to find the source code. > > It's mount(2) that has to be fixed. I suppose I could go and look at > > it, but I'm not confident that I understand all the different > > implications of the securelevel stuff at that level. > > Here's an untested patch for -CURRENT which will make mount(2) fail > with EPERM if running at securelevel 4 or higher. Took me all of three > minutes to throw together. > > Index: vfs_syscalls.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v > retrieving revision 1.138 > diff -u -r1.138 vfs_syscalls.c > --- vfs_syscalls.c 1999/10/03 12:18:14 1.138 > +++ vfs_syscalls.c 1999/10/18 08:52:56 > @@ -123,6 +123,8 @@ > > if (usermount == 0 && (error = suser(p))) > return (error); > + if (securelevel > 3) > + return (EPERM); > /* > * Do not allow NFS export by non-root users. > */ > > I'm starting to think that secure levels should be implemented as > bitmasks, with one bit for each operation or group of operation to be > allowed or denied (0 = allow, 1 = deny). The if statement above could > be rewritten as: > > if (securemask & SEC_MOUNT) > return (EPERM); > > Using a simple bitmask might be too simple though (it would restrict > us to 32 or 64 distinct operations), so we might want to hide the > actual implementation behind a function call or macro: > > if (!sec_permitted(SEC_MOUNT)) > return (EPERM); > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 9: 3: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id AEB3214CA1 for ; Mon, 18 Oct 1999 09:02:54 -0700 (PDT) (envelope-from hart@iserver.com) Received: by gatekeeper.veriohosting.com; Mon, 18 Oct 1999 10:02:51 -0600 (MDT) Received: from unknown(192.168.1.109) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma019264; Mon, 18 Oct 99 10:02:47 -0600 Received: (hart@localhost) by anchovy.orem.iserver.com (8.9.3) id KAA50106; Mon, 18 Oct 1999 10:01:22 -0600 (MDT) Date: Mon, 18 Oct 1999 10:01:22 -0600 (MDT) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com To: tom brown Cc: freebsd-security@FreeBSD.ORG Subject: Re: General securiy of vanilla install WAS [FreeSSH] In-Reply-To: <19991017043046.5909.rocketmail@web115.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 16 Oct 1999, tom brown wrote: > It's a mean world out there, and FreeBSD is a good contender as > security goes, but not straight out of the box! I think this borders more on hyperbole. What is it "straight out of the box" that strikes you as so insecure? When was the last time that a daemon considered "part of FreeBSD" (i.e. not one of the ports) had a remote root vulnerability? And what about local root vulnerabilities? The fts-bug-and-core-dumping-follows-symbolic-links hole was the last one in recent memory, but how would restricting what gets installed at installation time have affected that in any way? Just saying something like "I have X number of SUID/SGID programs installed or Y number of daemons running from inetd on my fresh vanilla install so I am insecure" makes it sound scary, but how many exploits do you have for each of those? And if you're advanced enough to be reading this list, then you'd be advanced enough to turn off services you don't need (which is always a good idea). I feel that the vanilla install strikes a delicate balance between security and usability. Inexperienced users will have enough running to see how FreeBSD works without undue exposure, and experienced users have only a few things to turn off if they're worried about them. Paul Hart -- Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. hart@iserver.com ><8> ><8> ><8> http://www.iserver.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 10: 0:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from s8-37-26.student.washington.edu (S8-37-26.student.washington.edu [128.208.37.26]) by hub.freebsd.org (Postfix) with ESMTP id 9BDE614F31 for ; Mon, 18 Oct 1999 10:00:10 -0700 (PDT) (envelope-from jcwells@u.washington.edu) Received: from localhost (jcw@localhost) by s8-37-26.student.washington.edu (8.9.3/8.9.3) with ESMTP id VAA82229; Mon, 18 Oct 1999 21:56:52 GMT (envelope-from jcwells@u.washington.edu) X-Authentication-Warning: s8-37-26.student.washington.edu: jcw owned process doing -bs Date: Mon, 18 Oct 1999 21:56:52 +0000 (GMT) From: "Jason C. Wells" X-Sender: jcw@s8-37-26.student.washington.edu Reply-To: "Jason C. Wells" To: Paul Hart Cc: freebsd-security@FreeBSD.ORG Subject: Re: General securiy of vanilla install WAS [FreeSSH] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 18 Oct 1999, Paul Hart wrote: >I feel that the vanilla install strikes a delicate balance between >security and usability. Inexperienced users will have enough running to >see how FreeBSD works without undue exposure, and experienced users have >only a few things to turn off if they're worried about them. I agree with Paul. Compare FreeBSD's approach to OpenBSD and Redhat. OpenBSD is nothing on by default. Redhat has the entire free software universe on by default. I happen to like FreeBSD's approach but so what? In all three cases, it takes me a few minutes to return each system to the correct configuration for my use. Certainly the number of services running can be used as a first look metric when securing a system. How many are turned on by default from "out of the box" is pretty meaningless. :%s/^/# / can secure inetd on any box really quick. :) Thank You, | http://students.washington.edu/jcwells Jason Wells | "Those who would trade freedom for security deserve neither | freedom nor security." - Benjamin Franklin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 11:20:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id C8FE515130 for ; Mon, 18 Oct 1999 11:20:44 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id LAA31980; Mon, 18 Oct 1999 11:20:38 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda31978; Mon Oct 18 11:20:36 1999 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id LAA07462; Mon, 18 Oct 1999 11:20:35 -0700 (PDT) Message-Id: <199910181820.LAA07462@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdhc7454; Mon Oct 18 11:20:31 1999 X-Mailer: exmh version 2.1.0 09/18/1999 Reply-To: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cschuber To: David G Andersen Cc: jdn@acp.qiv.com (Jay Nelson), Cy.Schubert@uumail.gov.bc.ca, jwyatt@rwsystems.net, glewis@trc.adelaide.edu.au, freebsd-security@FreeBSD.ORG Subject: Re: FreeSSH In-reply-to: Your message of "Sun, 17 Oct 1999 11:39:10 MDT." <199910171739.LAA21629@faith.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Oct 1999 11:20:31 -0700 From: Cy Schubert Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199910171739.LAA21629@faith.cs.utah.edu>, David G Andersen writes: > Given that it may take a lot of re-engineering to change the build process > to not install the packages in the first place, what if we changed the > installation to create a "virtual" package entry for them, so that > an interested sysadmin could then use pkg_delete to nuke the components of > the package? It would be easy enough to generate the packing list at > compile time, and then stuff it in a known location at build time. > > This wouldn't save download time or initial space, but it *would* > help make the security goal easier, from my point of view. In other words do what ports do currently. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 12:40:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail2.gmx.net (mail2.gmx.net [194.221.183.62]) by hub.freebsd.org (Postfix) with SMTP id 336D6150B7 for ; Mon, 18 Oct 1999 12:40:15 -0700 (PDT) (envelope-from Gerhard.Sittig@gmx.net) Received: (qmail 1451 invoked by uid 0); 18 Oct 1999 19:40:13 -0000 Received: from p3e9e7b89.dip.t-dialin.net (HELO speedy.gsinet) (62.158.123.137) by mail2.gmx.net with SMTP; 18 Oct 1999 19:40:13 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id UAA28746 for freebsd-security@FreeBSD.ORG; Mon, 18 Oct 1999 20:41:28 +0200 Message-ID: <19991018204128.G27109@speedy.gsinet> Date: Mon, 18 Oct 1999 20:41:28 +0200 From: Gerhard Sittig To: freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: ; from Dag-Erling Smorgrav on Mon, Oct 18, 1999 at 10:56:51AM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Oct 18, 1999 at 10:56 +0200, Dag-Erling Smorgrav wrote: > [ ... ] > > + if (securelevel > 3) > + return (EPERM); > > [ ... ] > > I'm starting to think that secure levels should be implemented as > bitmasks, with one bit for each operation or group of operation to be > allowed or denied (0 = allow, 1 = deny). The if statement above could > be rewritten as: > > if (securemask & SEC_MOUNT) > return (EPERM); ... which sounds to me very much like capabilities ... > Using a simple bitmask might be too simple though (it would restrict > us to 32 or 64 distinct operations), so we might want to hide the > actual implementation behind a function call or macro: > > if (!sec_permitted(SEC_MOUNT)) > return (EPERM); and this one does for sure :> I'm not that familiar with FBSD, but it sounds like one usually has a certain set of capabilities which reduces in a determined way when raising the securelevel. So on the way to a higher level one even might lose the ability to grant some privileges. virtually yours - Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 12:55:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from relay.veriguard.com (relay.securify.com [207.5.63.61]) by hub.freebsd.org (Postfix) with ESMTP id F3825150E9 for ; Mon, 18 Oct 1999 12:55:42 -0700 (PDT) (envelope-from tomb@cgf.net) Received: by relay.veriguard.com; id MAA17086; Mon, 18 Oct 1999 12:53:19 -0700 (PDT) Received: from unknown(10.5.63.100) by relay.veriguard.com via smap (4.1) id xma017038; Mon, 18 Oct 99 12:53:02 -0700 Message-ID: <380B7A9D.15295ED9@cgf.net> Date: Mon, 18 Oct 1999 12:53:01 -0700 From: tomb X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Suspect port... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I just ran nmap on myself to see what was open and this appeared. 1446 open tcp ora-lm I killed Netscape and it disappeared. Has anyone any idea what this is? Thanks -- Tom Brown --------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 13: 5:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id 20C4E14BD8 for ; Mon, 18 Oct 1999 13:04:51 -0700 (PDT) (envelope-from cdf.lists@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1016) id AC7759B22; Mon, 18 Oct 1999 16:04:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id A4594BA1C; Mon, 18 Oct 1999 16:04:48 -0400 (EDT) Date: Mon, 18 Oct 1999 16:04:48 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: cdf.lists@pawn.primelocation.net To: tomb Cc: freebsd-security@freebsd.org Subject: Re: Suspect port... In-Reply-To: <380B7A9D.15295ED9@cgf.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 18 Oct 1999, tomb wrote: > Hi, > I just ran nmap on myself to see what was open and this appeared. > > 1446 open tcp ora-lm > > I killed Netscape and it disappeared. Has anyone any idea what this is? > What version are you using. I have Communicator 4.6 (US) here and nmap isn't showing any open ports that can't be accounted for WRT my services. Also, what does sockstat show for the process using that port? ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 13:17: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from lanshark.lanminds.com (lanshark.lanminds.com [208.25.68.5]) by hub.freebsd.org (Postfix) with ESMTP id 76EB6151DB for ; Mon, 18 Oct 1999 13:16:58 -0700 (PDT) (envelope-from todd@lmi.net) Received: from drtboi.lanminds.com (drtboi.lmi.net [208.25.91.219]) by lanshark.lanminds.com (8.8.8/8.8.7) with ESMTP id NAA25736; Mon, 18 Oct 1999 13:16:28 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 18 Oct 1999 13:16:28 -0700 (PDT) Reply-To: todd@lmi.net Organization: LMI.net From: Todd Meister To: "Chris D. Faulhaber" Subject: Re: Suspect port... Cc: freebsd-security@FreeBSD.ORG, tomb Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 18-Oct-99 Chris D. Faulhaber wrote: > On Mon, 18 Oct 1999, tomb wrote: > >> Hi, >> I just ran nmap on myself to see what was open and this appeared. >> >> 1446 open tcp ora-lm >> >> I killed Netscape and it disappeared. Has anyone any idea what this is? >> I've noticed this kind of thing, myself. Usually, no ports but the expected are open on my box, but sometimes, ports associated with random services I know I'm not running will be open. I've come to the conclusion that the connections are either http or domain connections, though I could definitely be wrong. Does a netstat -f inet show anything? -Todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 14:58:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 054CF150ED for ; Mon, 18 Oct 1999 14:58:34 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id QAA05157; Mon, 18 Oct 1999 16:57:26 -0500 (CDT) Date: Mon, 18 Oct 1999 16:57:25 -0500 From: "Matthew D. Fuller" To: Matt Behrens Cc: David G Andersen , Jay Nelson , Cy.Schubert@uumail.gov.bc.ca, jwyatt@rwsystems.net, glewis@trc.adelaide.edu.au, freebsd-security@FreeBSD.ORG Subject: Re: FreeSSH Message-ID: <19991018165725.C29597@futuresouth.com> References: <199910171739.LAA21629@faith.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: X-OS: FreeBSD Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Oct 17, 1999 at 02:06:32PM -0400, a little birdie told me that Matt Behrens remarked > > That would probably do pretty well for the initial install, but it > unfortunately doesn't address the problem of how to stop make world > from happily replacing all of the newly-missing components. This is why I stick non-stock things in /usr/local. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 16:58:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from patachou.sti.com.br (patachou.sti.com.br [200.212.48.251]) by hub.freebsd.org (Postfix) with ESMTP id DAA5B152BE for ; Mon, 18 Oct 1999 16:58:07 -0700 (PDT) (envelope-from rromero@sti.com.br) Received: from sti.com.br (dial-lc01-60.sti.com.br [200.212.49.60]) by patachou.sti.com.br (8.9.3/8.9.3) with ESMTP id VAA06962 for ; Mon, 18 Oct 1999 21:58:38 -0200 Message-ID: <380BB327.D48839B5@sti.com.br> Date: Mon, 18 Oct 1999 21:54:15 -0200 From: Ricardo Romero X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 20:53:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from s8-37-26.student.washington.edu (S8-37-26.student.washington.edu [128.208.37.26]) by hub.freebsd.org (Postfix) with ESMTP id 01C3415BD3 for ; Mon, 18 Oct 1999 20:53:21 -0700 (PDT) (envelope-from jcwells@u.washington.edu) Received: from localhost (jcw@localhost) by s8-37-26.student.washington.edu (8.9.3/8.9.3) with ESMTP id IAA83690; Tue, 19 Oct 1999 08:49:59 GMT (envelope-from jcwells@u.washington.edu) X-Authentication-Warning: s8-37-26.student.washington.edu: jcw owned process doing -bs Date: Tue, 19 Oct 1999 08:49:59 +0000 (GMT) From: "Jason C. Wells" X-Sender: jcw@s8-37-26.student.washington.edu Reply-To: "Jason C. Wells" To: "Matthew D. Fuller" Cc: Matt Behrens , freebsd-security@FreeBSD.ORG Subject: Re: FreeSSH In-Reply-To: <19991018165725.C29597@futuresouth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 18 Oct 1999, Matthew D. Fuller wrote: >On Sun, Oct 17, 1999 at 02:06:32PM -0400, a little birdie told me >that Matt Behrens remarked >> >> That would probably do pretty well for the initial install, but it >> unfortunately doesn't address the problem of how to stop make world >> from happily replacing all of the newly-missing components. > >This is why I stick non-stock things in /usr/local. You can also use refuse files in cvsup to keep components from being fetched and then remove those sources. This is how I keep the "r" utilities from installing when I have krb5 versions in place. It might be hairbrained. We will see at my next make world. Thank You, | http://students.washington.edu/jcwells Jason Wells | "Those who would trade freedom for security deserve neither | freedom nor security." - Benjamin Franklin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 21:44: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from kearneys.ca (cr1003527-a.rct1.bc.wave.home.com [24.113.36.145]) by hub.freebsd.org (Postfix) with SMTP id 4C2D815D4A for ; Mon, 18 Oct 1999 21:43:58 -0700 (PDT) (envelope-from brent@kearneys.ca) Received: (qmail 33419 invoked by uid 1000); 19 Oct 1999 04:46:45 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Oct 1999 04:46:45 -0000 Date: Mon, 18 Oct 1999 21:46:45 -0700 (PDT) From: Brent To: security@freebsd.org Subject: PAM & cracklib Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Today I spent considerable time searching for the modules pam_cracklib and it's sidekick pam_pwdb (and libpwdb) that I could use with my FreeBSD-3.3 system. I found a lot of RPMs! :\ Are these modules secretly being ported somewhere? Is there an alternative, aside from analpasswd (which is brutal to set up), that can check "passwd" inputs against Alec Muffet's cracklib? Thanks for your help. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 22:42:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from jason.argos.org (a13b146.neo.rr.com [204.210.197.146]) by hub.freebsd.org (Postfix) with ESMTP id F177415E40 for ; Mon, 18 Oct 1999 22:42:09 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id BAA02766; Tue, 19 Oct 1999 01:41:11 -0400 Date: Tue, 19 Oct 1999 01:41:11 -0400 (EDT) From: Mike Nowlin To: Sue Blake Cc: freebsd-security@FreeBSD.ORG Subject: Re: allowing telnet from locked terminal In-Reply-To: <19991017070610.E12725@welearn.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > That's fine, but I don't want it to be easy for them to see/touch my > other work which they're not interested in anyway. The people are > trustworthy but will be unfamiliar with the machine and could press > random buttons when working in panic mode. Periods away include coffee > breaks, overnight, and weekends. I had a similar problem.... The machines that people needed to get to were all running Linux, so this program was written for that, but I imagine it could be ported over to FreeBSD pretty easily -- I'll take a look. Basically, it keeps track of the console idle times -- if they get to be more than ten minutes, or if the person types "lockup" from the shell, it will do the following: 1) Make a note of the current VC and (if applicable) the user logged in on it 2) Switch to VC 10 (no getty normally running on that one) 3) Send the IOCTL to the kernel that disables VC switching 4) Print "Locked - Password: ", turn off echo, and get a password 5) If the PW matched either root's or the person from step #1, re-enable VC switching and switch back to the VC from step #1, else scan /etc/passwd for a matching one -- if it found one, keep VC switching off, but give a one-time login prompt on VC 10. It has some problems in the total logic of it (there are some "features" that I never bothered to fix), but in the physically restricted environment that these machines are in, it allows people to get in who need to..... --mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Oct 18 23:17:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 2FA6A15ED4 for ; Mon, 18 Oct 1999 23:17:12 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11dSZz-0004sj-00; Tue, 19 Oct 1999 00:17:04 -0600 Message-ID: <380C0CDE.7F70EB71@softweyr.com> Date: Tue, 19 Oct 1999 00:17:02 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Nowlin Cc: Sue Blake , freebsd-security@FreeBSD.ORG Subject: Re: allowing telnet from locked terminal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Nowlin wrote: > > > That's fine, but I don't want it to be easy for them to see/touch my > > other work which they're not interested in anyway. The people are > > trustworthy but will be unfamiliar with the machine and could press > > random buttons when working in panic mode. Periods away include coffee > > breaks, overnight, and weekends. > > I had a similar problem.... The machines that people needed to get to > were all running Linux, so this program was written for that, but I > imagine it could be ported over to FreeBSD pretty easily -- I'll take a > look. > > Basically, it keeps track of the console idle times -- if they get to be > more than ten minutes, or if the person types "lockup" from the shell, it > will do the following: > > 1) Make a note of the current VC and (if applicable) the user logged in > on it > 2) Switch to VC 10 (no getty normally running on that one) This part blows up if you don't have 10 virtual consoles configured. > 3) Send the IOCTL to the kernel that disables VC switching > 4) Print "Locked - Password: ", turn off echo, and get a password > 5) If the PW matched either root's or the person from step #1, re-enable > VC switching and switch back to the VC from step #1, else scan /etc/passwd > for a matching one -- if it found one, keep VC switching off, but give a > one-time login prompt on VC 10. > > It has some problems in the total logic of it (there are some "features" > that I never bothered to fix), but in the physically restricted > environment that these machines are in, it allows people to get in who > need to..... Programmatically su'ing to the user and running 'lock -p -n' on the idle session will do admirably. If the idle session is running an X server, substitute xlock. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Oct 19 5:37: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from megaweapon.zigg.com (megaweapon.zigg.com [206.114.60.8]) by hub.freebsd.org (Postfix) with ESMTP id 3CCDB16DA4 for ; Tue, 19 Oct 1999 05:37:00 -0700 (PDT) (envelope-from matt@zigg.com) Received: from localhost (matt@localhost) by megaweapon.zigg.com (8.9.3/8.9.3) with ESMTP id IAA13922; Tue, 19 Oct 1999 08:36:17 -0400 (EDT) (envelope-from matt@zigg.com) Date: Tue, 19 Oct 1999 08:36:16 -0400 (EDT) From: Matt Behrens To: "Matthew D. Fuller" Cc: David G Andersen , Jay Nelson , Cy.Schubert@uumail.gov.bc.ca, jwyatt@rwsystems.net, glewis@trc.adelaide.edu.au, freebsd-security@FreeBSD.ORG Subject: Re: FreeSSH In-Reply-To: <19991018165725.C29597@futuresouth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 18 Oct 1999, Matthew D. Fuller wrote: : On Sun, Oct 17, 1999 at 02:06:32PM -0400, a little birdie told me : that Matt Behrens remarked : > : > That would probably do pretty well for the initial install, but it : > unfortunately doesn't address the problem of how to stop make world : > from happily replacing all of the newly-missing components. : : This is why I stick non-stock things in /usr/local. Yes, but we're referring to now-"stock" things that will, for one reason or another, end up totally nonexistent on the system. For example, a system without any UUCP stuff would suddenly become a system *with* UUCP stuff after make world. Matt Behrens Owner/Administrator, zigg.com Chief Engineer, Nameless IRC Network To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Oct 19 6:58: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EBF1015066 for ; Tue, 19 Oct 1999 06:57:59 -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.9.3/8.9.3) with SMTP id JAA33559 for ; Tue, 19 Oct 1999 09:57:59 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Tue, 19 Oct 1999 09:57:59 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-security@freebsd.org Subject: Kerberos tickets in /tmp -- or somewhere else? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anyone know if there's a way to make our default-installed K4 move it's tickets somewhere other than /tmp without rebuilding? /tmp on my busy machines gets filled with ticket files (sometimes many for a particular user with different variations on the same name). On CMU's Andrew workstations, they make use of a /tkt with restrictive access rights for ticket files, which can be cleaned seperately from /tmp, and more importantly, in a different namespace. It sounds like the kind of thing that's hardcoded (and if I remember from my last source inspection, it is), but perhaps we could make it something configurable? I guess there is no tradition of a /etc/kerberosIV/krb.rc (.conf already taken) with a configuration namespace and names/values :-). This could also be used to configure other host-based policy--maximum ticket lifespans that the library should acquire, defaults for ticket-passing behavior once we get K5, etc. Installing a customer Kerberos on my machines to get a prettier /tmp sounds unfortunate, and definitely increases the time-to-make-useful on machine installs. Thanks, Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Oct 19 8: 7:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 684D0173A0 for ; Tue, 19 Oct 1999 08:07:12 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA02308; Tue, 19 Oct 1999 08:07:10 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda02306; Tue Oct 19 08:06:53 1999 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id IAA12249; Tue, 19 Oct 1999 08:06:52 -0700 (PDT) Message-Id: <199910191506.IAA12249@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdT12242; Tue Oct 19 08:06:02 1999 X-Mailer: exmh version 2.1.0 09/18/1999 Reply-To: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cschuber To: Matt Behrens Cc: "Matthew D. Fuller" , David G Andersen , Jay Nelson , Cy.Schubert@uumail.gov.bc.ca, jwyatt@rwsystems.net, glewis@trc.adelaide.edu.au, freebsd-security@FreeBSD.ORG Subject: Re: FreeSSH In-reply-to: Your message of "Tue, 19 Oct 1999 08:36:16 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Oct 1999 08:06:02 -0700 From: Cy Schubert Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Matt Behrens writes: > On Mon, 18 Oct 1999, Matthew D. Fuller wrote: > > : On Sun, Oct 17, 1999 at 02:06:32PM -0400, a little birdie told me > : that Matt Behrens remarked > : > > : > That would probably do pretty well for the initial install, but it > : > unfortunately doesn't address the problem of how to stop make world > : > from happily replacing all of the newly-missing components. > : > : This is why I stick non-stock things in /usr/local. > > Yes, but we're referring to now-"stock" things that will, for one > reason or another, end up totally nonexistent on the system. For > example, a system without any UUCP stuff would suddenly become a > system *with* UUCP stuff after make world. A previous posting of mine conveyed the idea of variables like NOUUCP=true, NOSENDMAIL, NONAMED, NOYP, SUID_BINARIES_root='/usr/bin/su ...' etc., in make.conf. Wouldn't this work? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Oct 19 9:23:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from megaweapon.zigg.com (megaweapon.zigg.com [206.114.60.8]) by hub.freebsd.org (Postfix) with ESMTP id 5FB8D1765F for ; Tue, 19 Oct 1999 09:23:19 -0700 (PDT) (envelope-from matt@zigg.com) Received: from localhost (matt@localhost) by megaweapon.zigg.com (8.9.3/8.9.3) with ESMTP id MAA14199; Tue, 19 Oct 1999 12:22:39 -0400 (EDT) (envelope-from matt@zigg.com) Date: Tue, 19 Oct 1999 12:22:38 -0400 (EDT) From: Matt Behrens To: Cy Schubert - ITSD Open Systems Group Cc: "Matthew D. Fuller" , David G Andersen , Jay Nelson , jwyatt@rwsystems.net, glewis@trc.adelaide.edu.au, freebsd-security@FreeBSD.ORG Subject: Re: FreeSSH In-Reply-To: <199910191506.IAA12249@passer.osg.gov.bc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 19 Oct 1999, Cy Schubert wrote: : In message , : Matt : Behrens writes: : > : > Yes, but we're referring to now-"stock" things that will, for one : > reason or another, end up totally nonexistent on the system. For : > example, a system without any UUCP stuff would suddenly become a : > system *with* UUCP stuff after make world. : : A previous posting of mine conveyed the idea of variables like : NOUUCP=true, NOSENDMAIL, NONAMED, NOYP, SUID_BINARIES_root='/usr/bin/su : ...' etc., in make.conf. Wouldn't this work? Yes, but the plan previously outlined way back when (make pseudo-packages for various pieces of the system) would not work this way, at least not without some hackery. Matt Behrens Owner/Administrator, zigg.com Chief Engineer, Nameless IRC Network To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Oct 19 10:23:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (Postfix) with ESMTP id 595BF1776E; Tue, 19 Oct 1999 10:23:12 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id NAA07180; Tue, 19 Oct 1999 13:23:09 -0400 (EDT) Message-Id: <3.0.5.32.19991019132216.014d8b60@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 19 Oct 1999 13:22:16 -0400 To: torstenb@FreeBSD.org From: Mike Tancsa Subject: SSH port request - logging password failures Cc: security@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, As the port maintainer, I was wondering if you could apply some or all of the following patches to the sshd 1.2.27 distribution. It would be nice to have it act in a similar fashion to other authentication services where password failures are logged. The main one that I think is important/worthwhile is the last one, @@ -2674,6 +2695,7 @@ break; } debug("Password authentication for %.100s failed.", user); + log_msg("Password LOGIN FAILURE for user: %.100s", user); memset(password, 0, strlen(password)); xfree(password); break; --- sshd.c.o2 Tue Oct 19 12:41:16 1999 +++ sshd.c Tue Oct 19 13:19:39 1999 @@ -1633,6 +1633,7 @@ if (account_is_locked) { debug("Account %.100s is locked.", user); + log_msg("Account %.100s is locked.", user); enduserdb(); return 0; } @@ -1640,6 +1641,8 @@ { debug("Remote logins to account %.100s not permitted by user profile.", user); + log_msg("Remote logins to account %.100s not permitted by user profile.", + user); enduserdb(); return 0; } @@ -1670,6 +1673,7 @@ if (strcmp(normalized, current_time) < 0) { debug("Account %.100s has expired - access denied.", user); + log_msg("Account %.100s has expired - access denied.", user); enduserdb(); return 0; } @@ -1721,6 +1725,7 @@ if (sp->sp_expire > 0 && today > sp->sp_expire) { debug("Account %.100s has expired - access denied.", user); + log_msg("Account %.100s has expired - access denied.", user); endspent(); return 0; } @@ -1822,6 +1827,7 @@ if (pwd->pw_expire && pwd->pw_expire <= currtime) { debug("Account %.100s has expired - access denied.", user); + log_msg("Account %.100s has expired - access denied.", user); return 0; } else @@ -1850,6 +1856,7 @@ if ( pr->uflg.fg_lock && pr->ufld.fd_lock ) { debug("Account %.100s is locked.",user); + log_msg("Account %.100s is locked.",user); packet_send_debug("\n\tAdministrative lock on account"); endprpwent(); return 0; @@ -1861,6 +1868,7 @@ if ( pr->uflg.fg_acct_expire && time(NULL) > pr->ufld.fd_acct_expire ) { debug("Account %.100s lifetime exceeded.", user); + log_msg("Account %.100s lifetime exceeded.", user); packet_send_debug("\n\tAccount lifetime exceeded"); endprpwent(); return 0; @@ -1913,6 +1921,7 @@ if ( time(NULL) > pr->ufld.fd_schange + expire ) { debug("Account %.100s passwd expired, requires change", user); + log_msg("Account %.100s passwd expired, requires change", user); if (options.forced_passwd_change) { forced_command = xmalloc(sizeof(PASSWD_PATH) + @@ -1960,6 +1969,8 @@ { debug("Account %.100s locked, too many unsuccessful login attempts", user); + log_msg("Account %.100s locked, too many unsuccessful login attempts", + user); packet_send_debug("\n\tToo many unsuccessful attempts"); endprpwent(); return 0; @@ -1981,6 +1992,7 @@ ) { debug("Account %.100s is locked.", user); + log_msg("Account %.100s is locked.", user); return 0; } } @@ -1999,6 +2011,7 @@ if (invalid) { debug("Account %.100s doesn't have valid shell", user); + log_msg("Account %.100s doesn't have valid shell", user); return 0; } } @@ -2267,7 +2280,6 @@ else { /* Indicate that authentication is needed. */ - packet_start(SSH_SMSG_FAILURE); packet_send(); packet_write_wait(); @@ -2351,6 +2363,8 @@ #endif /* KRB5 */ debug("Kerberos authentication failed for %.100s from %.200s", user, get_canonical_hostname()); + log_msg("Kerberos authentication failed for %.100s from %.200s", + user, get_canonical_hostname()); break; #endif /* KERBEROS */ @@ -2390,6 +2404,8 @@ } debug("Rhosts authentication failed for '%.100s', remote '%.100s', host '%.200s'.", user, client_user, get_canonical_hostname()); + log_msg("Rhosts authentication failed for '%.100s', remote '%.100s', host '%.200s'.", + user, client_user, get_canonical_hostname()); xfree(client_user); break; @@ -2451,6 +2467,8 @@ } debug("RhostsRSA authentication failed for '%.100s', remote '%.100s', host '%.200s'.", user, client_user, get_canonical_hostname()); + log_msg("RhostsRSA authentication failed for '%.100s', remote '%.100s', host '%.200s'.", + user, client_user, get_canonical_hostname()); xfree(client_user); mpz_clear(&client_host_key_e); mpz_clear(&client_host_key_n); @@ -2481,6 +2499,7 @@ } mpz_clear(&n); debug("RSA authentication for %.100s failed.", user); + log_msg("RSA authentication for %.100s failed.", user); } break; @@ -2586,6 +2605,7 @@ /* Unknown user */ auth_close(); debug("Unknown user from authentication server"); + log_msg("Unknown user from authentication server"); break; } } @@ -2614,6 +2634,7 @@ break; } else { debug("TIS authentication for %.100s failed",user); + log_msg("TIS authentication for %.100s failed",user); memset(password, 0, strlen(password)); xfree(password); break; @@ -2674,6 +2695,7 @@ break; } debug("Password authentication for %.100s failed.", user); + log_msg("Password LOGIN FAILURE for user: %.100s", user); memset(password, 0, strlen(password)); xfree(password); break; ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel 01.519.651.3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Oct 19 14:54:29 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 1020D17E0B; Tue, 19 Oct 1999 14:54:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 032B51CD907; Tue, 19 Oct 1999 14:54:27 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Tue, 19 Oct 1999 14:54:27 -0700 (PDT) From: Kris Kennaway To: Brent Cc: security@freebsd.org Subject: Re: PAM & cracklib In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 18 Oct 1999, Brent wrote: > Today I spent considerable time searching for the modules pam_cracklib and > it's sidekick pam_pwdb (and libpwdb) that I could use with my FreeBSD-3.3 > system. I found a lot of RPMs! :\ It's part of Linux-PAM itself. http://www.??.kernel.org/pub/linux/libs/pam/pre/library/ where ?? is your two-level country abbreviation. Kris ---- XOR for AES -- join the campaign! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Oct 19 21:35:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from web117.yahoomail.com (web117.yahoomail.com [205.180.60.91]) by hub.freebsd.org (Postfix) with SMTP id C519D17D11 for ; Tue, 19 Oct 1999 21:35:26 -0700 (PDT) (envelope-from bu553@yahoo.com) Message-ID: <19991020043630.11125.rocketmail@web117.yahoomail.com> Received: from [134.117.137.229] by web117.yahoomail.com; Tue, 19 Oct 1999 21:36:30 PDT Date: Tue, 19 Oct 1999 21:36:30 -0700 (PDT) From: Embedded Systems Subject: Software release for embedded systems design. To: freebsd-security@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We are pleased to offer to you a new software product, which will be of significant help in the area of logical circuit design. We have developed "ELMAS" which provides a full-featured set of development tools including a complete set of logic gates and microprocessors. To find out more about this advanced development tool for embedded systems, please visit our site at: http://www.tamik.com If you find this product useful for your company, we will be delighted to receive your comments. Sales Department Tamik Corporation ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Oct 19 21:37: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from web117.yahoomail.com (web117.yahoomail.com [205.180.60.91]) by hub.freebsd.org (Postfix) with SMTP id 766721A81F for ; Tue, 19 Oct 1999 21:37:04 -0700 (PDT) (envelope-from bu553@yahoo.com) Message-ID: <19991020043808.11362.rocketmail@web117.yahoomail.com> Received: from [134.117.137.229] by web117.yahoomail.com; Tue, 19 Oct 1999 21:38:08 PDT Date: Tue, 19 Oct 1999 21:38:08 -0700 (PDT) From: Embedded Systems Subject: Software release for embedded systems design. To: freebsd-security@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We are pleased to offer to you a new software product, which will be of significant help in the area of logical circuit design. We have developed "ELMAS" which provides a full-featured set of development tools including a complete set of logic gates and microprocessors. To find out more about this advanced development tool for embedded systems, please visit our site at: http://www.tamik.com If you find this product useful for your company, we will be delighted to receive your comments. Sales Department Tamik Corporation ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Oct 19 22:39:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from athserv.otenet.gr (athserv.otenet.gr [195.170.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9022518277 for ; Tue, 19 Oct 1999 22:39:45 -0700 (PDT) (envelope-from keramida@diogenis.ceid.upatras.gr) Received: from hades.hell.gr (patr530-a029.otenet.gr [195.167.115.29]) by athserv.otenet.gr (8.9.3/8.9.3) with SMTP id IAA18608 for ; Wed, 20 Oct 1999 08:39:41 +0300 (EET DST) Received: (qmail 721 invoked by uid 1001); 19 Oct 1999 09:39:15 -0000 To: freebsd-security@freebsd.org Subject: Re: allowing telnet from locked terminal References: From: Giorgos Keramidas Date: 19 Oct 1999 12:39:14 +0300 In-Reply-To: Mike Nowlin's message of "Tue, 19 Oct 1999 01:41:11 -0400 (EDT)" Message-ID: <86puybhepp.fsf@localhost.hell.gr> Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Nowlin writes: > 1) Make a note of the current VC and (if applicable) the user logged in > on it > 2) Switch to VC 10 (no getty normally running on that one) > 3) Send the IOCTL to the kernel that disables VC switching > 4) Print "Locked - Password: ", turn off echo, and get a password > 5) If the PW matched either root's or the person from step #1, re-enable > VC switching and switch back to the VC from step #1, else scan > /etc/passwd for a matching one -- if it found one, keep VC switching > off, but give a one-time login prompt on VC 10. All this sounds oh so familiar... I think that `screen' does something similar, but does not disable ALL the virtual consoles. It just makes access to a certain virtual console controlled by the one that run screen over there. A simple `C-a x' and off you're gone. Of course, if VC switching is not disabled there's always X11 on that Alt-F7 console, bliax. -- Giorgos Keramidas, "What we have to learn to do, we learn by doing." [Aristotle] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 6:25:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id E91AE1ACDD for ; Wed, 20 Oct 1999 06:25:28 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id HAA16399; Wed, 20 Oct 1999 07:25:22 -0600 (MDT) Message-Id: <4.2.0.58.19991020072331.00c31150@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 20 Oct 1999 07:25:03 -0600 To: Embedded Systems , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: Software release for embedded systems design. In-Reply-To: <19991020043808.11362.rocketmail@web117.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Not only does this have nothing to do with security, but it's a bloody WINDOWS program. Spam. --Brett At 09:38 PM 10/19/1999 -0700, Embedded Systems wrote: >We are pleased to offer to you a new software product, >which will be of significant help in the area of >logical circuit design. We have developed "ELMAS" >which provides a full-featured set of development >tools including a complete set of logic gates and >microprocessors. > >To find out more about this advanced development tool >for embedded systems, please visit our site at: > >http://www.tamik.com > >If you find this product useful for your company, we >will be delighted to receive your comments. > > > >Sales Department >Tamik Corporation > > > > >===== > >__________________________________________________ >Do You Yahoo!? >Bid and sell for free at http://auctions.yahoo.com > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message My feeling is, in a competitive environment, there will always be someone who's the biggest and therefore a threat. So long as the sum of all the other players is greater than that one, it will make sense for that (dominant player) to toe the line and be standards-compatible. --Tim Berners-Lee, inventor of the World Wide Web To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 7:33:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from modemcable156.106-200-24.mtl.mc.videotron.net (modemcable156.106-200-24.mtl.mc.videotron.net [24.200.106.156]) by hub.freebsd.org (Postfix) with SMTP id E07861BA68 for ; Wed, 20 Oct 1999 07:33:11 -0700 (PDT) (envelope-from patrick@mindstep.com) Received: (qmail 534 invoked from network); 20 Oct 1999 14:33:05 -0000 Received: from unknown (HELO patrak) (192.168.10.25) by jacuzzi.local.mindstep.com with SMTP; 20 Oct 1999 14:33:05 -0000 Message-ID: <009001bf1b08$05ad6040$190aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: "matt" , References: <19991020104749.B17206@relay.ucb.crimea.ua> Subject: Re: ipfw rule wrong in rc.firewall(?) Date: Wed, 20 Oct 1999 10:33:05 -0400 Organization: MindStep Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, From: matt > On Wed, 20 Oct 1999, Ruslan Ermilov wrote: > [...] > : Yes, src/etc/rc.firewall is incomplete, it misses two rules for incoming > : UDP queries. > > Well, I guess I was not *totally* wrong, which is a minor miricle. > > : # Allow access to our DNS > : allow tcp from any to ${oip} 53 setup # zone transfers > : allow udp from any to ${oip} 53 # incoming DNS queries (missing) > : allow udp from ${oip} 53 to any # answers to these queries (missing) > : > : # Allow DNS queries out in the world > : allow udp from ${oip} to any 53 # outgoing DNS queries > : allow udp from any 53 to ${oip} # answers to these queries Humm... As somebody mentioned earlier the last rule (allow udp from any 53 to ${oip}) is fairly weak. I would really love to see something along the lines of the TCP rules (allow tcp from any to any established) for UDP as well... I know that it is not possible to do that just by looking at the UDP header, however it would be possible to keep track of what connections have been established and allow or deny based on that (remember that a UDP packet from local ip/port 5555 to 1.2.3.4 port 53 has been sent 5 seconds ago, so let a packet from 1.2.3.4 port 53 reach local ip port 5555, anything else is bad...) I guess it would add a couple of keywords in the lines of: ipfw add allow udp from ${oip} to any 53 monitor 10 ipfw add allow udp from any to any established ipfw add deny udp from any to any where "monitor" indicates that we want to allow the return data flow, 10 is a time-out value (packets must be no more that 10 seconds apart from one another). If I have some time (in my dreams) I will look at implementing that scheme... In the meantime, I hope to get some comments on that idea... Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 7:53:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id C76BB1B648 for ; Wed, 20 Oct 1999 07:53:19 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA50157; Wed, 20 Oct 1999 16:53:04 +0200 (CEST) (envelope-from des) To: Cy Schubert - ITSD Open Systems Group Cc: Matt Behrens , "Matthew D. Fuller" , David G Andersen , Jay Nelson , jwyatt@rwsystems.net, glewis@trc.adelaide.edu.au, freebsd-security@FreeBSD.ORG Subject: Re: FreeSSH References: <199910191506.IAA12249@passer.osg.gov.bc.ca> From: Dag-Erling Smorgrav Date: 20 Oct 1999 16:53:03 +0200 In-Reply-To: Cy Schubert's message of "Tue, 19 Oct 1999 08:06:02 -0700" Message-ID: Lines: 10 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cy Schubert writes: > A previous posting of mine conveyed the idea of variables like > NOUUCP=true, NOSENDMAIL, NONAMED, NOYP, SUID_BINARIES_root='/usr/bin/su > ...' etc., in make.conf. Wouldn't this work? Read /usr/share/mk/bsd.subdir.mk. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 8: 8:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id AFEE41B235 for ; Wed, 20 Oct 1999 08:08:11 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id RAA50208; Wed, 20 Oct 1999 17:08:01 +0200 (CEST) (envelope-from des) To: "Patrick Bihan-Faou" Cc: "matt" , Subject: Re: ipfw rule wrong in rc.firewall(?) References: <19991020104749.B17206@relay.ucb.crimea.ua> <009001bf1b08$05ad6040$190aa8c0@local.mindstep.com> From: Dag-Erling Smorgrav Date: 20 Oct 1999 17:08:00 +0200 In-Reply-To: "Patrick Bihan-Faou"'s message of "Wed, 20 Oct 1999 10:33:05 -0400" Message-ID: Lines: 37 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Patrick Bihan-Faou" writes: > I guess it would add a couple of keywords in the lines of: > > ipfw add allow udp from ${oip} to any 53 monitor 10 > ipfw add allow udp from any to any established > ipfw add deny udp from any to any > > where "monitor" indicates that we want to allow the return data flow, 10 is > a time-out value (packets must be no more that 10 seconds apart from one > another). Sounds like a good idea, but you may want to do something a little bit more fancy than just accepting the packets unconditionally. If you teach ipfw the notion of temporary rules (add a ttl field to the rule structure, and remove the rule when the ttl reaches 0), the effect of a "monitor" rule would simply be to add a temporary rule with a preselected rule number. That way, you can view and delete automagic rules manually. You might also want to have those automagic rules be 'skipto' rules rather than 'allow' rules, so you can do arbitrarily complex processing of those packets. > If I have some time (in my dreams) I will look at implementing that > scheme... In the meantime, I hope to get some comments on that idea... I'll look into it this weekend, provided that I get the capabilities stuff done first and the ipfw kernel code isn't as ugly as the ipfw userland code. Hmm... now that I think of it, the userland code is so ugly I'm tempted to rewrite it, just on general principles *grin* Well, you got my comments, anyway. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 9:51:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from modemcable156.106-200-24.mtl.mc.videotron.net (modemcable156.106-200-24.mtl.mc.videotron.net [24.200.106.156]) by hub.freebsd.org (Postfix) with SMTP id 9C5D514A00 for ; Wed, 20 Oct 1999 09:51:18 -0700 (PDT) (envelope-from patrick@mindstep.com) Received: (qmail 672 invoked from network); 20 Oct 1999 16:51:15 -0000 Received: from unknown (HELO patrak) (192.168.10.25) by jacuzzi.local.mindstep.com with SMTP; 20 Oct 1999 16:51:15 -0000 Message-ID: <002001bf1b1b$52ea0a80$190aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: "Dag-Erling Smorgrav" Cc: "matt" , References: <19991020104749.B17206@relay.ucb.crimea.ua> <009001bf1b08$05ad6040$190aa8c0@local.mindstep.com> Subject: Re: ipfw rule wrong in rc.firewall(?) Date: Wed, 20 Oct 1999 12:51:15 -0400 Organization: MindStep Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, ----- Original Message ----- From: Dag-Erling Smorgrav > "Patrick Bihan-Faou" writes: > > I guess it would add a couple of keywords in the lines of: > > > > ipfw add allow udp from ${oip} to any 53 monitor 10 > > ipfw add allow udp from any to any established > > ipfw add deny udp from any to any > > > > where "monitor" indicates that we want to allow the return data flow, 10 is > > a time-out value (packets must be no more that 10 seconds apart from one > > another). > > Sounds like a good idea, but you may want to do something a little bit > more fancy than just accepting the packets unconditionally. > > If you teach ipfw the notion of temporary rules (add a ttl field to > the rule structure, and remove the rule when the ttl reaches 0), the > effect of a "monitor" rule would simply be to add a temporary rule > with a preselected rule number. That way, you can view and delete > automagic rules manually. You might also want to have those automagic > rules be 'skipto' rules rather than 'allow' rules, so you can do > arbitrarily complex processing of those packets. I was more thinking of something like: ipfw add monitored Here the keyword "monitored" (with a 'd'...) indicates where the packets matching the monitored connection list should be handled.... Sort of like the "established" keyword for TCP... This is why I wrote "established" for the UDP rule. Because in a way that feature extends the meaning of "established" beyond the scope of TCP sessions. Which is to say the keyword "established" indicates that ipfw can, by one mean or another, verify that the packet is part of a session. This leaves as much flexibility as one may want (or at least close enough), while not requiring major architecture changes in ipfw (sort of)... Of course the problem of removing "established/monitored" connections is not dealt with. Is it really a concern ? Now that I think of it, "monitored" might be a better word than "established" since the type of checking (which could be also applied to TCP connections) is somewhat stricter thant the "established" keyword for TCP (which relies on trust of the TCP header). As far as coding goes, I would find it fun to work on that. So if you do not have too much time to look at it, let me do some mods and submit them later (I am talking of a couple of weeks time frame). Patrick. -- Patrick Bihan-Faou MindStep Corporation www.mindstep.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 10: 1:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 269BF14A01 for ; Wed, 20 Oct 1999 10:01:39 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA02948; Wed, 20 Oct 1999 10:00:09 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199910201700.KAA02948@gndrsh.dnsmgr.net> Subject: Re: ipfw rule wrong in rc.firewall(?) In-Reply-To: <009001bf1b08$05ad6040$190aa8c0@local.mindstep.com> from Patrick Bihan-Faou at "Oct 20, 1999 10:33:05 am" To: patrick@mindstep.com (Patrick Bihan-Faou) Date: Wed, 20 Oct 1999 10:00:08 -0700 (PDT) Cc: matt@BabCom.ORG (matt), freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Charset iso-8859-1 unsupported, filtering to ASCII...] > Hi, > > From: matt > > > On Wed, 20 Oct 1999, Ruslan Ermilov wrote: > > [...] > > : Yes, src/etc/rc.firewall is incomplete, it misses two rules for incoming > > : UDP queries. > > > > Well, I guess I was not *totally* wrong, which is a minor miricle. > > > > : # Allow access to our DNS > > : allow tcp from any to ${oip} 53 setup # zone transfers > > : allow udp from any to ${oip} 53 # incoming DNS queries (missing) > > : allow udp from ${oip} 53 to any # answers to these queries (missing) > > : > > : # Allow DNS queries out in the world > > : allow udp from ${oip} to any 53 # outgoing DNS queries > > : allow udp from any 53 to ${oip} # answers to these queries > > Humm... > > As somebody mentioned earlier the last rule (allow udp from any 53 to > ${oip}) is fairly weak. I would really love to see something along the lines > of the TCP rules (allow tcp from any to any established) for UDP as well... First thing to do is stop using ``any'', you should not have that many internal nameservers that you can't explicity name them by IP address: 10539 235 10548 allow log tcp from any to any 53 40530 35051 3395489 allow udp from any to 205.238.40.1 53 40530 1608 306167 allow udp from any to 205.238.40.2 53 40530 52365 3549882 allow udp from any to 199.238.232.2 53 40530 0 0 allow udp from any to 199.238.232.3 53 40530 35250 6830449 allow udp from 205.238.40.1 53 to any 40530 1868 124384 allow udp from 205.238.40.2 53 to any 40530 51697 9134012 allow udp from 199.238.232.2 53 to any 40530 0 0 allow udp from 199.238.232.3 53 to any You should be running bind 8 behind any firewall, and set it up to use a src port of 53, thus allowing the above rules to just work. All internal queries should be directed to these name servers, and only they should talk to the internet. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 10:13:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 688F914A17 for ; Wed, 20 Oct 1999 10:13:28 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA05677; Wed, 20 Oct 1999 11:13:14 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA25715; Wed, 20 Oct 1999 11:13:12 -0600 Date: Wed, 20 Oct 1999 11:13:12 -0600 Message-Id: <199910201713.LAA25715@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Rodney W. Grimes" Cc: patrick@mindstep.com (Patrick Bihan-Faou), matt@BabCom.ORG (matt), freebsd-security@FreeBSD.ORG Subject: DNS security using IPFW (was Re: ipfw rule wrong in rc.firewall(?)) In-Reply-To: <199910201700.KAA02948@gndrsh.dnsmgr.net> References: <009001bf1b08$05ad6040$190aa8c0@local.mindstep.com> <199910201700.KAA02948@gndrsh.dnsmgr.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > First thing to do is stop using ``any'', you should not have that many > internal nameservers that you can't explicity name them by IP address: > > 10539 235 10548 allow log tcp from any to any 53 IMO, this rule should be *after* all of the other rules, otherwise you'll get hits for 'acceptable' use in your logs. It appears that this must be the case with the numbers, or else you've got specific rules for zone transfers that are not listed. Note, the use of TCP does not *necessarily* mean a zone transfer, since it may be the result of a large transfer that doesn't fit into a UDP packet, which can happen if you have large datasets. (The Bind FAQ deals with this in more detail.) > 40530 35051 3395489 allow udp from any to 205.238.40.1 53 > 40530 1608 306167 allow udp from any to 205.238.40.2 53 > 40530 52365 3549882 allow udp from any to 199.238.232.2 53 > 40530 0 0 allow udp from any to 199.238.232.3 53 > 40530 35250 6830449 allow udp from 205.238.40.1 53 to any > 40530 1868 124384 allow udp from 205.238.40.2 53 to any > 40530 51697 9134012 allow udp from 199.238.232.2 53 to any > 40530 0 0 allow udp from 199.238.232.3 53 to any > > You should be running bind 8 behind any firewall, and set it up > to use a src port of 53, thus allowing the above rules to just > work. By default, bind8 'binds' to port 53. owever, there is one issue when using a firewall, in that all queries and/or transfers are sent out using your external IP address, and generally speaking most 'external' addresses are assigned by your ISP. However, most of the time you want to publish the 'internal' address that your ISP assigned to your network, since you have greater control over the names/addresses. This means that zone transfers and such come from an IP/name in your ISP's namespace, which is annoying. It would be nice if bind8 allowed you to 'bind' zone transfers to a certain address, like it does with responses. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 10:31:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 69E0514BC4 for ; Wed, 20 Oct 1999 10:31:40 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA03016; Wed, 20 Oct 1999 10:29:41 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199910201729.KAA03016@gndrsh.dnsmgr.net> Subject: Re: DNS security using IPFW (was Re: ipfw rule wrong in rc.firewall(?)) In-Reply-To: <199910201713.LAA25715@mt.sri.com> from Nate Williams at "Oct 20, 1999 11:13:12 am" To: nate@mt.sri.com (Nate Williams) Date: Wed, 20 Oct 1999 10:29:41 -0700 (PDT) Cc: patrick@mindstep.com (Patrick Bihan-Faou), matt@BabCom.ORG (matt), freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > First thing to do is stop using ``any'', you should not have that many > > internal nameservers that you can't explicity name them by IP address: > > > > 10539 235 10548 allow log tcp from any to any 53 > > IMO, this rule should be *after* all of the other rules, otherwise > you'll get hits for 'acceptable' use in your logs. It appears that this > must be the case with the numbers, or else you've got specific rules for > zone transfers that are not listed. ooppppss.. I didn't even meen to grab the tcp related rules, grab one to many (grep produced this, my regex was bad, I should have hand edited the list produced). > > Note, the use of TCP does not *necessarily* mean a zone transfer, since > it may be the result of a large transfer that doesn't fit into a UDP > packet, which can happen if you have large datasets. (The Bind FAQ > deals with this in more detail.) > > > 40530 35051 3395489 allow udp from any to 205.238.40.1 53 > > 40530 1608 306167 allow udp from any to 205.238.40.2 53 > > 40530 52365 3549882 allow udp from any to 199.238.232.2 53 > > 40530 0 0 allow udp from any to 199.238.232.3 53 > > 40530 35250 6830449 allow udp from 205.238.40.1 53 to any > > 40530 1868 124384 allow udp from 205.238.40.2 53 to any > > 40530 51697 9134012 allow udp from 199.238.232.2 53 to any > > 40530 0 0 allow udp from 199.238.232.3 53 to any > > > > You should be running bind 8 behind any firewall, and set it up > > to use a src port of 53, thus allowing the above rules to just > > work. > > By default, bind8 'binds' to port 53. owever, there is one issue when > using a firewall, in that all queries and/or transfers are sent out > using your external IP address, and generally speaking most 'external' > addresses are assigned by your ISP. > > However, most of the time you want to publish the 'internal' address > that your ISP assigned to your network, since you have greater control > over the names/addresses. > > This means that zone transfers and such come from an IP/name in your > ISP's namespace, which is annoying. It would be nice if bind8 allowed > you to 'bind' zone transfers to a certain address, like it does with > responses. Yes. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 11:57:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from agora.neteze.com (agora.neteze.com [208.201.249.4]) by hub.freebsd.org (Postfix) with ESMTP id D460814A09 for ; Wed, 20 Oct 1999 11:57:14 -0700 (PDT) (envelope-from kc@neteze.com) Received: from admin1 ([208.201.249.51]) by agora.neteze.com (Post.Office MTA v3.5.3 release 223 ID# 0-62409U9000L900S0V35) with SMTP id com for ; Wed, 20 Oct 1999 12:01:39 -0700 Message-ID: <03ac01bf1b2d$3076e600$33f9c9d0@neteze.com> From: "Kelsey Cummings" To: Subject: CERT CA-99.13 Date: Wed, 20 Oct 1999 11:59:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is the WU-FTPD port in /ftp/wu-ftpd with makefile dated 09/03 vulnerable as described in the CERT notice? It wouldn't appear so since its dated later than august 30th but I wanted to double check. ----------------------------------------------------------------- Kelsey Cummings System Administrator NetEase, Inc. kc@neteze.com ----------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 12:41: 1 1999 Delivered-To: freebsd-security@freebsd.org Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (Postfix) with ESMTP id 9F4A514CF9; Wed, 20 Oct 1999 12:40:58 -0700 (PDT) (envelope-from ssamalin@ionet.net) Received: from ionet.net (sam.ops.best.com [205.149.163.53]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id MAA21162; Wed, 20 Oct 1999 12:36:16 -0700 (PDT) Message-ID: <380E19B5.71C5BE39@ionet.net> Date: Wed, 20 Oct 1999 15:36:21 -0400 From: Sam Samalin X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-isp , freebsd-ipf , freebsd-security , freebsd-net Subject: ipfw not alias to bind Class C to interface? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone done this? What are the pros/cons? We want to use ipfw instead of aliases with all our internet servers to bind Class Cs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 13:46: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from apse.cc.rtu.lv (apse.cc.rtu.lv [159.148.95.241]) by hub.freebsd.org (Postfix) with ESMTP id DE8E614D6A for ; Wed, 20 Oct 1999 13:45:50 -0700 (PDT) (envelope-from uldisk@cc.rtu.lv) Received: from cc.rtu.lv ([159.148.55.160]) by apse.cc.rtu.lv (8.9.0/8.9.0) with ESMTP id XAA16407 for ; Wed, 20 Oct 1999 23:42:36 +0300 (EET DST) Message-ID: <380E2AB9.4E8BB7D8@cc.rtu.lv> Date: Wed, 20 Oct 1999 23:48:58 +0300 From: Uldis K X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: sendmail 8.9.3 feature Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! Why Sendmail 8.9.3 doesn't support \user, "|/usr/sbin/vacation user" ? All messages what I send to this user, comes back with error 550 - ".. unsafe mail to programm .. " What can I do? regards, Uldis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 13:53:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from kerouac.deepwell.com (deepwell.com [209.63.174.12]) by hub.freebsd.org (Postfix) with SMTP id 4F55514C4B for ; Wed, 20 Oct 1999 13:53:27 -0700 (PDT) (envelope-from freebsd@deepwell.com) Received: (qmail 5254 invoked from network); 20 Oct 1999 21:41:35 -0000 Received: from proxy.dcomm.net (HELO terry) (209.63.175.10) by deepwell.com with SMTP; 20 Oct 1999 21:41:35 -0000 Message-Id: <4.2.0.58.19991020134505.03184960@mail1.dcomm.net> X-Sender: freebsd@mail.deepwell.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 20 Oct 1999 13:46:40 -0700 To: freebsd-security@freebsd.org From: Deepwell Internet Subject: Re: sendmail 8.9.3 feature In-Reply-To: <380E2AB9.4E8BB7D8@cc.rtu.lv> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I don't know. I'm still wondering myself why sendmail no longer supports 'rcpt from: |/malicious/program'. Go figure. At 11:48 PM 10/20/99 +0300, you wrote: >Hi! > > Why Sendmail 8.9.3 doesn't support \user, "|/usr/sbin/vacation >user" ? >All messages what I send to this user, comes back with >error 550 - ".. unsafe mail to programm .. " >What can I do? > >regards, Uldis > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 13:57: 1 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.desktop.com (mail.desktop.com [166.90.128.242]) by hub.freebsd.org (Postfix) with ESMTP id 59CF614C4B for ; Wed, 20 Oct 1999 13:56:54 -0700 (PDT) (envelope-from clark@desktop.com) Received: (from clark@localhost) by ns.desktop.com (8.9.2/8.9.2) id NAA21305; Wed, 20 Oct 1999 13:56:44 -0700 (PDT) (envelope-from clark) Date: Wed, 20 Oct 1999 13:56:43 -0700 From: Clark Shishido To: Uldis K Cc: freebsd-security@freebsd.org Subject: Re: sendmail 8.9.3 feature Message-ID: <19991020135643.A21155@desktop.com> References: <380E2AB9.4E8BB7D8@cc.rtu.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <380E2AB9.4E8BB7D8@cc.rtu.lv>; from Uldis K on Wed, Oct 20, 1999 at 11:48:58PM +0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 20, 1999 at 11:48:58PM +0300, Uldis K emailed: > > All messages what I send to this user, comes back with > error 550 - ".. unsafe mail to programm .. " > What can I do? > you're probably using smrsh to restrict which programs can be run. read the man page on smrsh, and then look in /usr/libexec/sm.bin --clark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 14: 7:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from erouter0.it-datacntr.louisville.edu (erouter0.it-datacntr.louisville.edu [136.165.1.36]) by hub.freebsd.org (Postfix) with ESMTP id 0C03A14C4B for ; Wed, 20 Oct 1999 14:07:22 -0700 (PDT) (envelope-from k.stevenson@louisville.edu) Received: from osaka.louisville.edu (osaka.louisville.edu [136.165.1.114]) by erouter0.it-datacntr.louisville.edu (Postfix) with ESMTP id 95A5424D03; Wed, 20 Oct 1999 17:07:16 -0400 (EDT) Received: by osaka.louisville.edu (Postfix, from userid 15) id 172DA18613; Wed, 20 Oct 1999 17:07:16 -0400 (EDT) Date: Wed, 20 Oct 1999 17:07:16 -0400 From: Keith Stevenson To: Kelsey Cummings Cc: freebsd-security@freebsd.org Subject: Re: CERT CA-99.13 Message-ID: <19991020170716.C23757@osaka.louisville.edu> References: <03ac01bf1b2d$3076e600$33f9c9d0@neteze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <03ac01bf1b2d$3076e600$33f9c9d0@neteze.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 20, 1999 at 11:59:08AM -0700, Kelsey Cummings wrote: > Is the WU-FTPD port in /ftp/wu-ftpd with makefile dated 09/03 vulnerable as > described in the CERT notice? It wouldn't appear so since its dated later > than august 30th but I wanted to double check. Probably, but the _safe_ thing would be to update your ports collection via cvsup just to make sure. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.stevenson@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 16:25:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 6665714D71 for ; Wed, 20 Oct 1999 16:25:42 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id QAA07043; Wed, 20 Oct 1999 16:25:41 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda07041; Wed Oct 20 16:25:38 1999 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id QAA58033; Wed, 20 Oct 1999 16:25:35 -0700 (PDT) Message-Id: <199910202325.QAA58033@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdX58027; Wed Oct 20 16:25:08 1999 X-Mailer: exmh version 2.1.0 09/18/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cy To: Uldis K Cc: security@FreeBSD.ORG Subject: Re: sendmail 8.9.3 feature In-reply-to: Your message of "Wed, 20 Oct 1999 23:48:58 +0300." <380E2AB9.4E8BB7D8@cc.rtu.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Oct 1999 16:25:06 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <380E2AB9.4E8BB7D8@cc.rtu.lv>, Uldis K writes: > Hi! > > Why Sendmail 8.9.3 doesn't support \user, "|/usr/sbin/vacation > user" ? > All messages what I send to this user, comes back with > error 550 - ".. unsafe mail to programm .. " > What can I do? You're running smrsh. Smrsh is a restricted shell listed in the Mprog line in sendmail.cf which will only run programs that are in /usr/libexec/sm.bin (on other platforms /var/adm/sm.bin). To fix, just copy vacation to /usr/libexec/sm.bin. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 17:13: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 491B514D8A; Wed, 20 Oct 1999 17:13:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 386511CD43B; Wed, 20 Oct 1999 17:13:04 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Wed, 20 Oct 1999 17:13:04 -0700 (PDT) From: Kris Kennaway To: Kelsey Cummings Cc: freebsd-security@FreeBSD.ORG Subject: Re: CERT CA-99.13 In-Reply-To: <03ac01bf1b2d$3076e600$33f9c9d0@neteze.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 20 Oct 1999, Kelsey Cummings wrote: > Is the WU-FTPD port in /ftp/wu-ftpd with makefile dated 09/03 vulnerable as > described in the CERT notice? It wouldn't appear so since its dated later > than august 30th but I wanted to double check. See the FreeBSD security advisory: http://www.freebsd.org/security/#adv Kris ---- XOR for AES -- join the campaign! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 18:22:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from quaggy.ursine.com (lambda.blueneptune.com [209.133.45.179]) by hub.freebsd.org (Postfix) with ESMTP id 6232714CAC; Wed, 20 Oct 1999 18:22:36 -0700 (PDT) (envelope-from fbsd-security@ursine.com) Received: from michael (lambda.ursine.com [209.133.45.69]) by quaggy.ursine.com (8.9.2/8.9.3) with ESMTP id SAA40410; Wed, 20 Oct 1999 18:22:31 -0700 (PDT) Message-ID: <199910201822360100.19F76012@quaggy.ursine.com> In-Reply-To: References: X-Mailer: Calypso Version 3.00.00.13 (2) Date: Wed, 20 Oct 1999 18:22:36 -0700 From: "Michael Bryan" To: freebsd-security@FreeBSD.ORG Subject: Re: CERT CA-99.13 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 10/20/99 at 5:13 PM Kris Kennaway wrote: >On Wed, 20 Oct 1999, Kelsey Cummings wrote: >> Is the WU-FTPD port in /ftp/wu-ftpd with makefile dated 09/03 vulnerable= as >> described in the CERT notice? It wouldn't appear so since its dated= later >> than august 30th but I wanted to double check. > >See the FreeBSD security advisory: > >http://www.freebsd.org/security/#adv That does not cover the latest CERT notice. There have been additional vulnerabilities found in all versions of wu-ftpd prior to 2.6.0, which was just released. The most recent CERT notice describes three vulnerabilities, only one of which is addressed in the FreeBSD advisory. The information in the CERT announcement (available at http://www.cert.org/advisories/CA-99-13-wuftpd.html) seems to be potentially wrong in regards to the FreeBSD information, for the following reason. Under the WU-FTPD section of the CERT announcement, it says the following regarding Vulnerabilities #2 and #3: Not vulnerable: wu-ftpd-2.6.0 Vulnerable: All versions of wuarchive-ftpd and wu-ftpd prior to version 2.6.0, from wustl.edu, academ.com, vr.net and wu-ftpd.org. BeroFTPD, all versions Yet the FreeBSD section says this: FreeBSD has updated its wuftpd and proftpd ports to correct this problem as of August 30, 1999. Users of these ports are encouraged to upgrade their installation to these newer versions of these ports as soon as possible. That information seems to apply to -only- Vulnerability #1 in the CERT announcement. I seriously doubt that the FreeBSD port of wuftpd was corrected on 8/30/99, since 2.6.0 was not out at that time. (Unless the port includes a patch for the other two problems, which I doubt.) If I'm correct, then the FreeBSD port is still vulnerable until such time that it's upgraded for wuftpd 2.6.0. The /pub/FreeBSD/ports/distfiles directory only has up to version 2.5.0. Can somebody with definite detailed knowledge of the wuftpd port confirm or deny my suspicions? Michael Bryan fbsd-security@ursine.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 19:14: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 039C414E6C; Wed, 20 Oct 1999 19:14:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E61421CD43B; Wed, 20 Oct 1999 19:14:03 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Wed, 20 Oct 1999 19:14:03 -0700 (PDT) From: Kris Kennaway To: Michael Bryan Cc: freebsd-security@FreeBSD.ORG, ache@freebsd.org Subject: Re: CERT CA-99.13 In-Reply-To: <199910201822360100.19F76012@quaggy.ursine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 20 Oct 1999, Michael Bryan wrote: > That does not cover the latest CERT notice. There have been > additional vulnerabilities found in all versions of wu-ftpd > prior to 2.6.0, which was just released. The most recent > CERT notice describes three vulnerabilities, only one of > which is addressed in the FreeBSD advisory. I wasn't aware there had been another advisory released - you'll have to contact the port maintainer (ache@FreeBSD.org, CC'ed) about the status of these holes - there have been so many I can't keep up any more :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Oct 20 20:45:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 63ABC14D93 for ; Wed, 20 Oct 1999 20:45:13 -0700 (PDT) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id UAA07590; Wed, 20 Oct 1999 20:45:07 -0700 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda07584; Wed Oct 20 20:44:52 1999 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id UAA41185; Wed, 20 Oct 1999 20:44:32 -0700 (PDT) Message-Id: <199910210344.UAA41185@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdT41178; Wed Oct 20 20:44:02 1999 X-Mailer: exmh version 2.1.0 09/18/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cy To: Allan Saddi Cc: Steve Reid , Antoine Beaupre , Mike Nowlin , "Rashid N. Achilov" , freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X In-reply-to: Your message of "Fri, 15 Oct 1999 14:34:57 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Oct 1999 20:44:01 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Allan Sa ddi writes: > On Fri, 15 Oct 1999, Steve Reid wrote: > > > But I don't think FreeBSD has that capability. I haven't seen any > > mention of a FreeBSD aperture driver, not even in vaporware form. > > Maybe people just don't realize such a thing is possible? > > I used to run X with high securelevels back in 2.2.x. I simply started > X/xdm before upping the securelevel. This seemed to work fine. I haven't > verified that it still works w/ 3.x, however. That was before the mmap security fix. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 1:33:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5746014BB8; Thu, 21 Oct 1999 01:33:44 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA52611; Thu, 21 Oct 1999 10:33:42 +0200 (CEST) (envelope-from des) To: hackers@freebsd.org Subject: Finer-grained securelevel: proof of concept From: Dag-Erling Smorgrav Date: 21 Oct 1999 10:33:41 +0200 Message-ID: Lines: 8 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Patches are available from http://www.freebsd.org/~des/. This is strictly proof-of-concept; the patches demonstrate that fine-grained security knobs can be implemented with minimal code impact. No documentation is provided, RTFS. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 5:42:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0899314E89; Thu, 21 Oct 1999 05:41:39 -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.9.3/8.9.3) with SMTP id IAA46897; Thu, 21 Oct 1999 08:41:28 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 21 Oct 1999 08:41:28 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Dag-Erling Smorgrav Cc: hackers@freebsd.org, security@freebsd.org Subject: Re: Finer-grained securelevel: proof of concept In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 21 Oct 1999, Dag-Erling Smorgrav wrote: > Patches are available from http://www.freebsd.org/~des/. This is > strictly proof-of-concept; the patches demonstrate that fine-grained > security knobs can be implemented with minimal code impact. No > documentation is provided, RTFS. Very clean, pretty, etc -- only one object: please call it something other than capabilities :-). I already have a POSIX.1e kern_cap in the wings, and POSIX.1e has a very specific definition and interface for capabilities that refers to specific sets of rights, and is a per-process kind of thing. Maybe this is fgsecurelevel or something. To merge the two a little, I'd modifiable IS_CAPABLE() to accept a process as well as a description of the desired action, and because most of the ones (if not all) you've looked at are fairly infrequent, I'd be tempted to follow Eilvind's string-based hierarchal capability naming -- "kern.vfs.ffs.mount", "kern.socket.bind.tcp.25", "kern.socket.listen.tcp.25", et al. I believe he posted a missive on the topic on -arch a while back so it should be in the archives. BTW, it seems like what we really want is not securelevels, but some sort of Biba-like MAC integrity policy. I.e., stuff used during boot has high integrity, and the resources that can influence the high integrity component of the system should not be modifiable by lower integrity components except through specific and carefully monitored channels. I.e., each runlevel drops the integrity level of the initiating process by one level, meaning that new processes can never recover the old level, and therefore are prohibited from affecting the old level due to MAC. Disk devices, etc, would be marked as high integrity files on disk, so they would only be modifiable by very high integrity processes (Fsck, etc). Attaching a debugger to Init would be prohibited for normal processes, et al. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 7:44:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C1DED14E23 for ; Thu, 21 Oct 1999 07:44:21 -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.9.3/8.9.3) with SMTP id KAA47465 for ; Thu, 21 Oct 1999 10:44:21 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 21 Oct 1999 10:44:21 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: security@freebsd.org Subject: Kerberos integration into ports--in particular, SSH Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It looks like many ports still don't use PAM for authentication. This is not something I have time to address, it's just a comment that it would be nice if now that we have PAM, things used PAM :-). Also, it's a little funky to have an /etc/auth.conf and a /etc/pam.conf -- auth.conf seems only to affect su? The real gist of my email is that I'd like to see the K4 patches incorporated into the SSH port when the user has K4 enabled into /etc/make.conf, or if they give a particular command line argument. The SSH K4 patches (with AFS, etc) are found at: http://www.monkey.org/~dugsong/ssh-afs/ The 1.2.27 patch applies cleanly and easily over 1.2.27, although it seems not to be compatible with our local patches in the ports tree--I assume just includes and weird things with the patches covering the same area, but I haven't checked. To enable K4 support, you just do --with-krb4 on configure, and it works. This adds support for authenticating logins using passed authenticators, ticket-passing with AFS, autologin using .klogin as with rsh, etc. Very convenient. :-) I suppose the ideal solution is we go to K5 sometime soon and then the support is built-in? Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 7:46:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C478614F41; Thu, 21 Oct 1999 07:46:12 -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.9.3/8.9.3) with SMTP id KAA47486; Thu, 21 Oct 1999 10:46:10 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 21 Oct 1999 10:46:10 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Dag-Erling Smorgrav Cc: hackers@freebsd.org, security@freebsd.org Subject: Re: Finer-grained securelevel: proof of concept In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Good grief, there are a lot of weird gramatical things in that email I sent. I guess that's what I get for not getting enough sleep and then expecting to generate cogent and comprehensible emails first thing in the morning.. The meaning of the email makes it across, though, I think :-) Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 8:20:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 478BE14D01; Thu, 21 Oct 1999 08:20:28 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id RAA53422; Thu, 21 Oct 1999 17:20:17 +0200 (CEST) (envelope-from des) To: Robert Watson Cc: hackers@freebsd.org, security@freebsd.org Subject: Re: Finer-grained securelevel: proof of concept References: From: Dag-Erling Smorgrav Date: 21 Oct 1999 17:20:17 +0200 In-Reply-To: Robert Watson's message of "Thu, 21 Oct 1999 08:41:28 -0400 (EDT)" Message-ID: Lines: 10 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson writes: > Very clean, pretty, etc -- only one object: please call it something other > than capabilities :-). [deletia] Please read the thread on -security and -arch that lead to these patches. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 8:54:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2582114D62; Thu, 21 Oct 1999 08:54:09 -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.9.3/8.9.3) with SMTP id LAA47948; Thu, 21 Oct 1999 11:54:03 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 21 Oct 1999 11:54:02 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Dag-Erling Smorgrav Cc: hackers@freebsd.org, security@freebsd.org Subject: Re: Finer-grained securelevel: proof of concept In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 21 Oct 1999, Dag-Erling Smorgrav wrote: > Robert Watson writes: > > Very clean, pretty, etc -- only one object: please call it something other > > than capabilities :-). [deletia] > > Please read the thread on -security and -arch that lead to these > patches. I did--hence my comments. My understanding was you did a proof-of-concept to show that doing a bitmasked enabling of system-wide features was feasible and not all that intrusive. And sure enough, it is true (not that I disagreed with you in the first place) I'm objecting to the use of the terminology "capability", and also suggesting that this should become a more general policy query with whatever policy backend you want--i.e., if (!policy_allow(curproc, "kern.socket....")) return(EPERM); The policy manager can then internally represent whatever definition of securelevel it chooses, paying or not paying attention to the passed credentials as it chooses. I'm also suggesting that what we really need is an integrity model and not just a set of feature switches. That is, that a security policy somewhere should describe these relationships between features and integrity of processes and files, and therefore be able to derive from that that certain events should not be allowed to take place--with some help, of course, from information about special files, etc, etc. MAC would be one way of going about doing this. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 8:56:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from s8-37-26.student.washington.edu (S8-37-26.student.washington.edu [128.208.37.26]) by hub.freebsd.org (Postfix) with ESMTP id DF8BB14EF5 for ; Thu, 21 Oct 1999 08:56:01 -0700 (PDT) (envelope-from jcwells@u.washington.edu) Received: from localhost (jcw@localhost) by s8-37-26.student.washington.edu (8.9.3/8.9.3) with ESMTP id UAA64396; Thu, 21 Oct 1999 20:53:04 GMT (envelope-from jcwells@u.washington.edu) X-Authentication-Warning: s8-37-26.student.washington.edu: jcw owned process doing -bs Date: Thu, 21 Oct 1999 20:53:03 +0000 (GMT) From: "Jason C. Wells" X-Sender: jcw@s8-37-26.student.washington.edu Reply-To: "Jason C. Wells" To: Robert Watson Cc: security@FreeBSD.ORG Subject: krb5 integration Was: Kerberos integration into ports--in particular, SSH In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 21 Oct 1999, Robert Watson wrote: >I suppose the ideal solution is we go to K5 sometime soon and then the >support is built-in? I have been monkeying with krb5 in order to get it to clobber FreeBSD binaries, libs, and includes and hence be "integrated" into the system. I am no programmer but things seem to be working. Also, I am not quite done yet. Is this something you guys would be interested in? Or is my approach too sophomoric for a real development effort? Thank You, | http://students.washington.edu/jcwells Jason Wells | "Those who would trade freedom for security deserve neither | freedom nor security." - Benjamin Franklin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 12:16: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 8096914CC4; Thu, 21 Oct 1999 12:16:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 62E231CD434; Thu, 21 Oct 1999 12:16:06 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Thu, 21 Oct 1999 12:16:06 -0700 (PDT) From: Kris Kennaway To: Robert Watson Cc: security@freebsd.org Subject: Re: Kerberos integration into ports--in particular, SSH In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 21 Oct 1999, Robert Watson wrote: > It looks like many ports still don't use PAM for authentication. This is > not something I have time to address, it's just a comment that it would be > nice if now that we have PAM, things used PAM :-). I agree. Do you have a (partial) list of ports which can support this? > Also, it's a little funky to have an /etc/auth.conf and a > /etc/pam.conf -- auth.conf seems only to affect su? /etc/auth.conf is vestigial, I think. auth_list seems to duplicate the function of /etc/pam.conf, and the commented-out auth_default line (which is no longer valid - the auth_default stuff was removed) should be replaced by a login capability. > The real gist of my email is that I'd like to see the K4 patches > incorporated into the SSH port when the user has K4 enabled into > /etc/make.conf, or if they give a particular command line argument. The > SSH K4 patches (with AFS, etc) are found at: Did you suggest this to the maintainer (torstenb@FreeBSD.org)? Seems like it can't hurt. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 12:18:32 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id B2F5714CE1; Thu, 21 Oct 1999 12:18:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A168E1CD436; Thu, 21 Oct 1999 12:18:31 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Thu, 21 Oct 1999 12:18:31 -0700 (PDT) From: Kris Kennaway To: "Jason C. Wells" Cc: Robert Watson , security@FreeBSD.ORG Subject: Re: krb5 integration Was: Kerberos integration into ports--in particular, SSH In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 21 Oct 1999, Jason C. Wells wrote: > On Thu, 21 Oct 1999, Robert Watson wrote: > > >I suppose the ideal solution is we go to K5 sometime soon and then the > >support is built-in? > > I have been monkeying with krb5 in order to get it to clobber FreeBSD > binaries, libs, and includes and hence be "integrated" into the system. I > am no programmer but things seem to be working. Also, I am not quite done > yet. > > Is this something you guys would be interested in? Or is my approach too > sophomoric for a real development effort? Mark Murray has been working on krb5 integration - in fact, I thought he'd already imported it into the crypto/ distribution. Kris ---- XOR for AES -- join the campaign! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 12:53:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from onizuka.vmunix.org (onizuka.vmunix.org [194.221.152.19]) by hub.freebsd.org (Postfix) with ESMTP id 5B53314A18 for ; Thu, 21 Oct 1999 12:53:34 -0700 (PDT) (envelope-from torstenb@vmunix.org) Received: from localhost (1123 bytes) by onizuka.vmunix.org via sendmail with stdio (sender: ) (ident using unix) id for ; Thu, 21 Oct 1999 21:53:40 +0200 (CEST) Message-Id: Date: Thu, 21 Oct 1999 21:53:40 +0200 (CEST) From: torstenb@vmunix.org (Torsten Blum) To: kris@hub.freebsd.org Cc: security@freebsd.org Subject: Re: Kerberos integration into ports--in particular, SSH References: X-Newsreader: NN version 6.5.3 (NOV) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In freebsd-security you wrote: >> The real gist of my email is that I'd like to see the K4 patches >> incorporated into the SSH port when the user has K4 enabled into >> /etc/make.conf, or if they give a particular command line argument. The >> SSH K4 patches (with AFS, etc) are found at: > >Did you suggest this to the maintainer (torstenb@FreeBSD.org)? Seems like >it can't hurt. I can't test the patches because I don't have access to a Kerberos environment - not to mention the lack of time to test those patches. And it won't ever be the default to include Kerberos in the ssh port - unless the ssh maintainers add it to their codebase. Lack of time and (continuously) test the Kerberos support is probably a problem most of the (port or original) maintainers have. -tb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 13: 7:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from gate.az.com (ip-216.145.8.235.az.com [216.145.8.235]) by hub.freebsd.org (Postfix) with ESMTP id 3564F14F55 for ; Thu, 21 Oct 1999 13:07:32 -0700 (PDT) (envelope-from yankee@gate.az.com) Received: (from yankee@localhost) by gate.az.com (8.8.5/8.8.5) id NAA14124; Thu, 21 Oct 1999 13:07:30 -0700 (PDT) Date: Thu, 21 Oct 1999 13:07:29 -0700 (PDT) From: "Dan Seafeldt, AZ.COM System Administrator" To: security@FreeBSD.ORG Subject: GRE/IP 47/PPTP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Will FreeBSD's /sbin/natd pass GRE IP packet type 47 as part of NT4.0 PPTP trust scenario? Seems run-o-the-mill SOHO routers in NAT mode fail in this capacity as they see TCP/UDP only? Although Cisco's latest IOS appears to handle it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 13:17:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.nexos.com.br (ns.nexos.com.br [200.223.94.67]) by hub.freebsd.org (Postfix) with ESMTP id 2C1DD14FA2; Thu, 21 Oct 1999 13:17:32 -0700 (PDT) (envelope-from josue@nexos.com.br) Received: from nexos.com.br (ubu.nexos.com.br [200.223.94.75]) by ns.nexos.com.br (8.9.2/8.9.2) with ESMTP id SAA17142; Thu, 21 Oct 1999 18:17:59 -0200 (BDB) (envelope-from josue@nexos.com.br) Message-ID: <380F752C.19B28700@nexos.com.br> Date: Thu, 21 Oct 1999 18:18:52 -0200 From: "=?iso-8859-1?Q?Josu=E9=20Jos=E9?= Souza Jr." Organization: Nexos =?iso-8859-1?Q?Servi=E7os?= de Redes Ltda. X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Natd problem Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, we administrate a network that has about 700 machines using a firewall with natd. The network deals with high traffic and is configured like this: Internet | | | ISA adapter 10Mbps ---------- | | PCI adapter 100Mbps | Firewall |------------------------Extranet | | ---------- | PCI adapter 100Mbps | | Intranet The problem is that sometimes we get this error message from natd Oct 21 16:04:49 fw natd[106]: failed to write packet back (Host is down) The machine also hangs up in a two times in a week basis. Could this be caused by the traffic on the ISA adapter? Does anyone have any hints about this problem? Thanks in advance, -- ------------------------------------------ Josué José Souza Jr. - Operações e Suporte josue@nexos.com.br Nexos Serviços de Redes Ltda. http://www.nexos.com.br Salvador - Bahia - Brasil ------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 13:57:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from logisticsoftware.co.nz (logisticsoftware.co.nz [202.37.163.1]) by hub.freebsd.org (Postfix) with ESMTP id CF42A14A1D; Thu, 21 Oct 1999 13:57:31 -0700 (PDT) (envelope-from jonc@logisticsoftware.co.nz) Received: (from jonc@localhost) by logisticsoftware.co.nz (8.9.3/8.9.3) id JAA08964; Fri, 22 Oct 1999 09:56:34 +1300 (NZDT) Date: Fri, 22 Oct 1999 09:56:34 +1300 (NZDT) From: Jonathan Chen To: "=?iso-8859-1?Q?Josu=E9=20Jos=E9?= Souza Jr." Cc: freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Natd problem In-Reply-To: <380F752C.19B28700@nexos.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 21 Oct 1999, [iso-8859-1] Josu=E9 Jos=E9 Souza Jr. wrote: [...] > The problem is that sometimes we get this error message from natd >=20 > Oct 21 16:04:49 fw natd[106]: failed to write packet back (Host is > down) When we had this, it was due to a misconfig'd ipfw rule. Our smallish network and reproducible error allowed me to fix it quick smart. With your 700 machine network, I wish you good luck. :-) Jonathan Chen ---------------------------------------------------------------------- "Don't forget the most important rule to live by.. Never believe anything you read on the USENET" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 14: 1:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from tetron03.tetronsoftware.com (tetron03.tetronsoftware.com [208.236.46.108]) by hub.freebsd.org (Postfix) with ESMTP id A95B214A1D; Thu, 21 Oct 1999 14:01:12 -0700 (PDT) (envelope-from zeus@tetron03.tetronsoftware.com) Received: from tetron03.tetronsoftware.com (tetron03.tetronsoftware.com [208.236.46.108]) by tetron03.tetronsoftware.com (8.9.3/8.9.3) with ESMTP id QAA40714; Thu, 21 Oct 1999 16:02:52 -0500 (CDT) (envelope-from zeus@tetron03.tetronsoftware.com) Date: Thu, 21 Oct 1999 16:02:52 -0500 (CDT) From: Gene Harris To: "=?iso-8859-1?Q?Josu=E9=20Jos=E9?= Souza Jr." Cc: freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Natd problem In-Reply-To: <380F752C.19B28700@nexos.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have had problems in the past mixing pnp isa and pci components. In one case, I pitched the isa card and went with a pci card and the problems went away. If your isa card is not pnp, then make sure that you tell the bios it is present (i.e. set any legacy isa irq and dma requirements in the bios setup.) Gene Harris Tetron Software, LLC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 15: 1:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (picasso.transbay.net [209.133.53.6]) by hub.freebsd.org (Postfix) with ESMTP id EF10A15009; Thu, 21 Oct 1999 15:01:20 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id AAA06078; Fri, 22 Oct 1999 00:01:05 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Robert Watson Cc: Dag-Erling Smorgrav , hackers@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Finer-grained securelevel: proof of concept In-reply-to: Your message of "Thu, 21 Oct 1999 08:41:28 EDT." Date: Fri, 22 Oct 1999 00:01:05 +0200 Message-ID: <6076.940543265@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Robert Watson writes: >On 21 Oct 1999, Dag-Erling Smorgrav wrote: > >> Patches are available from http://www.freebsd.org/~des/. This is >> strictly proof-of-concept; the patches demonstrate that fine-grained >> security knobs can be implemented with minimal code impact. No >> documentation is provided, RTFS. > >Very clean, pretty, etc -- only one object: I have been talking to a lot of people over here, and one common thing seems to be that they want to be able to set these things differently on a "per jail" basis. I actually think we should not get into the jail thing, but rather make them inheritable like other credentials, so the structure containing the stuff should hang of the proc structure, and hey wait, we already have this "struct ucred" hanging there. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 15:40:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 442C714FF2; Thu, 21 Oct 1999 15:40:33 -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.9.3/8.9.3) with SMTP id SAA50217; Thu, 21 Oct 1999 18:40:24 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 21 Oct 1999 18:40:24 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Poul-Henning Kamp Cc: Dag-Erling Smorgrav , hackers@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Finer-grained securelevel: proof of concept In-Reply-To: <6076.940543265@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 22 Oct 1999, Poul-Henning Kamp wrote: > In message , Robert > Watson writes: > >On 21 Oct 1999, Dag-Erling Smorgrav wrote: > > > >> Patches are available from http://www.freebsd.org/~des/. This is > >> strictly proof-of-concept; the patches demonstrate that fine-grained > >> security knobs can be implemented with minimal code impact. No > >> documentation is provided, RTFS. > > > >Very clean, pretty, etc -- only one object: > > I have been talking to a lot of people over here, and one common > thing seems to be that they want to be able to set these things > differently on a "per jail" basis. > > I actually think we should not get into the jail thing, but rather > make them inheritable like other credentials, so the structure > containing the stuff should hang of the proc structure, and hey > wait, we already have this "struct ucred" hanging there. At one point I submitted patches for a p->p_authext void pointer for kernel modules that want to maintain their own security contexts -- unfortunately, it never went in, and now that I've given it some though, perhaps a registration system makes more sense -- i.e., modules register a unique magic number and can access it via a hash/etc when they need it. One can imagine, actually, a chain of authorizers being queried for security-sensitive operations, each of which stores some of its own credentials... This might fit into my kernel tokens architecture, but that might also be a bit heavy-weight (it does have the inheritence properties you mention, however). The other approach for jails is the virtual machine approach--don't treat it so much as security, as much as accessible resources accessed as though by fd's -- interfaces or virtual interfaces are mapped to logical interfaces within virtual machines -- it's not so much as they are not permitted to access the resource, as much as they are unable to access it. One could imagine during the jail creation procedure-- j = jail_new(); jail_add_if(j, "ed0.inet.128.2.35.50", "eth0"); jail_add_if(j, "xl0", "eth1"); jail_enter(j); Etc. Doesn't fit well into the current jail model, which might fit the authorization token approach -- a token or capability represented as a token authorizing binding. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Oct 21 21:35:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail0.mco.bellsouth.net (mail0.mco.bellsouth.net [205.152.48.12]) by hub.freebsd.org (Postfix) with ESMTP id 9545614C34 for ; Thu, 21 Oct 1999 21:35:44 -0700 (PDT) (envelope-from bertke@bellsouth.net) Received: from bellsouth.net (adsl-78-196-151.sdf.bellsouth.net [216.78.196.151]) by mail0.mco.bellsouth.net (3.3.4alt/0.75.2) with ESMTP id AAA00474; Fri, 22 Oct 1999 00:35:46 -0400 (EDT) Message-ID: <380FE9E9.21DD8B35@bellsouth.net> Date: Fri, 22 Oct 1999 04:36:57 +0000 From: Bert Kellerman X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Dan Seafeldt, AZ.COM System Administrator" Cc: security@FreeBSD.ORG Subject: Re: GRE/IP 47/PPTP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You need to pass `-pptpalias ` on the command line. The ipaddress that you specify will be the only client/server on the inside that will get the type 47 packets. Check out the natd man page, it's all in there. AFAIK, cisco has supported GRE tunneling since IOS 9.x. Bert "Dan Seafeldt, AZ.COM System Administrator" wrote: > Will FreeBSD's /sbin/natd pass GRE IP packet type 47 as part of NT4.0 PPTP > trust scenario? Seems run-o-the-mill SOHO routers in NAT mode fail in this > capacity as they see TCP/UDP only? Although Cisco's latest IOS appears to > handle it. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Oct 22 0:38: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 237E014D07; Fri, 22 Oct 1999 00:38:01 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id JAA55460; Fri, 22 Oct 1999 09:37:57 +0200 (CEST) (envelope-from des) To: Robert Watson Cc: hackers@freebsd.org, security@freebsd.org Subject: Re: Finer-grained securelevel: proof of concept References: From: Dag-Erling Smorgrav Date: 22 Oct 1999 09:37:56 +0200 In-Reply-To: Robert Watson's message of "Thu, 21 Oct 1999 11:54:02 -0400 (EDT)" Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson writes: > On 21 Oct 1999, Dag-Erling Smorgrav wrote: > > Robert Watson writes: > > > Very clean, pretty, etc -- only one object: please call it something other > > > than capabilities :-). [deletia] > > Please read the thread on -security and -arch that lead to these > > patches. > I did--hence my comments. You seem to have missed the part that says "this should be integrated with process-level and user-level capabilities". DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Oct 22 6:43: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from vidle.i.cz (vidle.i.cz [193.179.36.138]) by hub.freebsd.org (Postfix) with ESMTP id 0E7BE15012 for ; Fri, 22 Oct 1999 06:43:01 -0700 (PDT) (envelope-from mm@i.cz) Received: from ns.i.cz (brana.i.cz [193.179.36.134]) by vidle.i.cz (Postfix) with ESMTP id B616E30702 for ; Fri, 22 Oct 1999 15:43:00 +0200 (CEST) Received: from woody.i.cz (woody.i.cz [192.168.18.29]) by ns.i.cz (Postfix) with ESMTP id 6491536415 for ; Fri, 22 Oct 1999 15:42:58 +0200 (CEST) Content-Length: 757 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <380FE9E9.21DD8B35@bellsouth.net> Date: Fri, 22 Oct 1999 15:42:58 +0200 (MET DST) Reply-To: mm@i.cz From: Martin Machacek To: security@FreeBSD.ORG Subject: Re: GRE/IP 47/PPTP Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 22-Oct-99 Bert Kellerman wrote: > You need to pass `-pptpalias ` on the command line. The ipaddress > that you specify will be the only client/server on the inside that will get > the type 47 packets. Check out the natd man page, it's all in there. AFAIK, > cisco has supported GRE tunneling since IOS 9.x. Well, GRE tunnelling is something completely different from suporting GRE in NAT. I can imagine doing one-to-one NAT and passing GRE, but doing many to one NAT and supporting multiple GRE streams is IMHO impossible. There is no parameter in the GRE encapsulation that would allow you to identify the real internal recipient if you NAT multiple internal addresses to one external address. Martin --- [PGP KeyID F3F409C4] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Oct 22 7:26: 1 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4CA0914E1D; Fri, 22 Oct 1999 07:25:53 -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.9.3/8.9.3) with SMTP id KAA52739; Fri, 22 Oct 1999 10:25:52 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 22 Oct 1999 10:25:52 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-arch@freebsd.org, freebsd-security@freebsd.org Subject: VFS, vnodes, and ACLs: Thoughts and Questions on integrating , POSIX.1e ACLs into FreeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm in the process of reviewing the POSIX.1e draft to being implementing ACLs. As you're probably aware, all other major UNIX distributions have extended ACL support available, if not turned on in the default file system. For those that have been following the POSIX.1e list recently, I've posted a summary of some of the ways they get them into the FS (IRIX: has general purpose attribute support; Solaris: an extra inode and file structure for each ACL; Linux: an extra block pointer in the inode) -- and now I have some questions about adding this support to FreeBSD. The first question has to do with integration into the vnode as vnops. The closest current vnops are vop_getattr and vop_setattr -- getting and setting standard file attributes (mode, size, modification dates, et al). It makes sense conceptually that the ACLs might be included in this attribute information, as a substructure or pointer or the like. However, because ACL support across different file systems is nebulous and likely to be inconsistent for a long time (if not forever), it makes sense to think of getting and setting ACLs as vnops themselves -- for this purpose on an experimental kernel I have introduced vop_getacl and vop_setacl. This allows the ACLs to be exposed in their own right to the layering and file system behavior -- file systems that don't implement ACLs or don't know about them return EOPNOSUPP, and a layered file system could easily choose to intecept ACL changes explicitely and implement tham in a union or the like. If the vnode interface is aware of ACLs, this raises the format and semantics of ACL structures exposed in vnops, as they should/must be consistently interpreted and implemented. My temptation is to make POSIX.1e ACLs part of the vnode-aware types -- the interface seems to be standard across the various UNIX implementations, and in this sense it's similar to the mode, uid, gid values in vattr that we also expose non-opaquely. For reference, here's a simplified view of how most platforms have chosen to represent ACLs for their kernel syscall interface: They either define an acl_t structure referring to an array of ACL entries (acl_entry_t), or they directly pass around arrays of acl_entry_t's via syscalls. For example, the LINUX (and Solaris) ACL syscalls look like this: int acl(const char *pathp, int cmd, int aclcnt, acl_entry_t *aclentp); int facl(int filedes, int cmd, int aclcnt, acl_entry_t *aclentp); typedef struct acl_entry_t { int a_type; uid_t a_id; mode_t a_perm; } acl_entry_t; The various POSIX.1e interfaces refer instead to acl_t's which are presumed to store references to acl_entry_t's, so you could also imagine a syscall interface referring to an acl_t structure, and without the count variable. typedef struct acl_t { int entries; int size; acl_entry_t *entp; } acl_t; This provides a general ACL structure with a pointer to an array of acl_entry_t's, or individual "this user/group gets this right". The other approach to doing this might be the approach of: typedef struct acl_t { int entries; int size; acl_entry_t ent[3]; }; /* 3 is the minimum entries in an ACL */ This is where the aclcnt argument could come into play. Which would remove indirection in the vnode-aware structure and therefore perhaps be "nicer". Either way, it looks like acl_t's would be the best type (in whatever form) to pass ACLs around in the kernel with, as they can contain data describing the array of acl_entry_t's, and not just the entries as a direct array would do. This vnode approach then moves the responsibility for implementing ACLs to individual file systems -- a layer could choose to take advantage of some existing mechanism (extrended attributes) to store them. There's also the issue of evaluation -- right now, my understanding is that the vnode call vop_open is implemented by each file system, which may return EPERM if it desires. POSIX.1e describes an evaluation procedure for ACLs -- preusmably providing a set of common functions all file systems (optionally) can use for ACL evaluation makes sense -- this would mean (for example) that the same ACL evaluation routines could be used in FFS and MFS without replicating code all over the place. The other option is to treat ACLs as opaque and fs-specific, but that makes layering a lot less useful for implementing ACLs. On the other hand, it would also force us to follow the POSIX.1e model for ACLs, which while popular might benefit from improvement? Anyhow, thoughts on the topic would be much appreciated. I have not yet tried to address the issue of integrating ACL storage into various file systems. A first bet might be NFS as (apparently) there are NFS extensions for passing ACLs from ACL-aware servers (such as Solaris, IRIX, and presumably Linux sometime soon as they're talking about it on their acl-develop mailing list). Another choice might be Coda/AFS which both support ACLs, albeit not POSIX.1e-style ACLs. Some conversion between the two could be done for the purposes of inspecting ACLs, although I think not setting (AFS groups work quite a bit differently than POSIX-style groups, as they allow users to create them on the fly and modify them as they see fit). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Oct 22 8:26:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.polytechnic.edu.na (mail.polytechnic.edu.na [196.31.225.2]) by hub.freebsd.org (Postfix) with ESMTP id 46E1714BE9 for ; Fri, 22 Oct 1999 08:25:48 -0700 (PDT) (envelope-from tim@iafrica.com.na) Received: from [196.31.225.199] (helo=310.priebe.alt.na) by mail.polytechnic.edu.na with smtp (Exim 3.02 #2) id 11eiTs-0000cn-00; Fri, 22 Oct 1999 15:27:56 -0200 From: Tim Priebe Reply-To: tim@iafrica.com.na To: "Patrick Bihan-Faou" , "Dag-Erling Smorgrav" Subject: Re: ipfw rule wrong in rc.firewall(?) Date: Thu, 21 Oct 1999 16:26:30 +0200 X-Mailer: KMail [version 1.0.17] Content-Type: text/plain Cc: "matt" , References: <002001bf1b1b$52ea0a80$190aa8c0@local.mindstep.com> MIME-Version: 1.0 Message-Id: <99102217281409.25232@310.priebe.alt.na> Content-Transfer-Encoding: 8bit X-KMail-Mark: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 20 Oct 1999, Patrick Bihan-Faou wrote: > Hi, > > > ----- Original Message ----- > From: Dag-Erling Smorgrav > > "Patrick Bihan-Faou" writes: > > > I guess it would add a couple of keywords in the lines of: > > > > > > ipfw add allow udp from ${oip} to any 53 monitor 10 > > > ipfw add allow udp from any to any established > > > ipfw add deny udp from any to any > > > > > > where "monitor" indicates that we want to allow the return data flow, 10 > is > > > a time-out value (packets must be no more that 10 seconds apart from one > > > another). > > > > Sounds like a good idea, but you may want to do something a little bit > > more fancy than just accepting the packets unconditionally. > > > > If you teach ipfw the notion of temporary rules (add a ttl field to > > the rule structure, and remove the rule when the ttl reaches 0), the > > effect of a "monitor" rule would simply be to add a temporary rule > > with a preselected rule number. That way, you can view and delete > > automagic rules manually. You might also want to have those automagic > > rules be 'skipto' rules rather than 'allow' rules, so you can do > > arbitrarily complex processing of those packets. > > I was more thinking of something like: > > ipfw add monitored > > > Here the keyword "monitored" (with a 'd'...) indicates where the packets > matching the monitored connection list should be handled.... Sort of like > the "established" keyword for TCP... This is why I wrote "established" for > the UDP rule. Because in a way that feature extends the meaning of > "established" beyond the scope of TCP sessions. > > Which is to say the keyword "established" indicates that ipfw can, by one > mean or another, verify that the packet is part of a session. This leaves as > much flexibility as one may want (or at least close enough), while not > requiring major architecture changes in ipfw (sort of)... > > Of course the problem of removing "established/monitored" connections is not > dealt with. Is it really a concern ? > > Now that I think of it, "monitored" might be a better word than > "established" since the type of checking (which could be also applied to TCP > connections) is somewhat stricter thant the "established" keyword for TCP > (which relies on trust of the TCP header). > > As far as coding goes, I would find it fun to work on that. So if you do not > have too much time to look at it, let me do some mods and submit them later > (I am talking of a couple of weeks time frame). What I would like to look at doing after you have done this, is to look at a way of having 2 or more firewalls share this state information. I have a client that is very serious about redundancy, and it was by showing them that I could setup 2 firewalls, and dynamic routing, for mutch less than the cost of a single commercial firewall, that was the final argument that finally got FBSD onto the network. I liked the state info in ipfilter, but it would have caused my present setup not to work. Tim. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Oct 22 8:49:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3F12814C2A; Fri, 22 Oct 1999 08:49:09 -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.9.3/8.9.3) with SMTP id LAA53171; Fri, 22 Oct 1999 11:48:46 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 22 Oct 1999 11:48:46 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: scott Cc: freebsd-arch@freebsd.org, freebsd-security@freebsd.org Subject: Re: VFS, vnodes, and ACLs: Thoughts and Questions on integrating , POSIX.1e ACLs into FreeBSD In-Reply-To: <19991022112650.A93123@chronis.pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've put the mailing lists back in the CC for my response because I include references to specifications, web pages, etc, below that answer some other people's questions also. On Fri, 22 Oct 1999, scott wrote: > On Fri, Oct 22, 1999 at 10:25:52AM -0400, Robert Watson wrote: > > > > I'm in the process of reviewing the POSIX.1e draft to being implementing > > ACLs. As you're probably aware, all other major UNIX distributions have > > extended ACL support available, if not turned on in the default file > > system. For those that have been following the POSIX.1e list recently, > > I've posted a summary of some of the ways they get them into the FS (IRIX: > > has general purpose attribute support; Solaris: an extra inode and file > > structure for each ACL; Linux: an extra block pointer in the inode) -- and > > now I have some questions about adding this support to FreeBSD. > > > > while I don't have the expertise to answer your questions, I am very > interested in the topic of ACL's for the filesystem, and am wondering > you can supply me with pointers to the posix.1e ACL specification and > discussions. > > I'd love to see a *good* ACL for freebsd. In particular, the admin > should be able to disallow symlinking in world writable directories, > choose what users and on what tty's can execute what set*id programs, > etc. > > I'm glad to see you taking an interest in this, and if I can get up to > speed on the standard you are referring to and some of the fs source > code, I'll certainly help out with ACL's for freebsd in any way I can. You can find information on the FreeBSD POSIX.1e implementation at http://www.watson.org/fbsd-hardening/posix1e/ Currently only information on our auditing implementation is online; we have most of a MAC implementation that I'll put online shortly, and ACLs are the next one we're working on. The spec does not define ACL rights for all the things you discuss for directories, but does provide an extensible environment for rights, so it's possible to fit them into the framework in a consistent way. At this point I'm in the design phase for FreeBSD ACLs and any advice and suggestions is greatly welcome--I'm a competent C and kernel programmer, but this is my first in-depth interaction with VFS/vnodes, so it's a learning experience for me also. There's a link from the page to a general POSIX.1e page including downloads of the specs (although redistribution is limited by our agreement with IEEEE). POSIX.1e defines standard interfaces for ACLs, Capabilities, MAC, Information Labels, and Auditing. It's a withdrawn draft, but some components are quite implementable, and are being implemented by a number of folk. There's also a posix1e mailing list for cross-platform and portability discussions that can be subscribed to by sending mail containing "subscribe posix1e" to majordomo@cyrus.watson.org. The posting address is posix1e@cyrus.watson.org. A web-accessible archive is available courtesy securityfocus.com -- it doesn't go back all the way to the beginning of the list, but includes a lot of the interesting recent discussions on MAC, ACLs, etc, including some reviews of ACL implementations on different platforms from a design perspective. I also have a complete archive available via anonymous imap from server cyrus.watson.org, mailbox lists.sec.posix1e Please let me know if you have any trouble accessing web pages, mailing lists, etc, and I'll see what I can do. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Oct 22 10:48:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 9B5EC14C57 for ; Fri, 22 Oct 1999 10:48:54 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id KAA67824; Fri, 22 Oct 1999 10:48:48 -0700 (PDT) From: Archie Cobbs Message-Id: <199910221748.KAA67824@bubba.whistle.com> Subject: Re: GRE/IP 47/PPTP In-Reply-To: from Martin Machacek at "Oct 22, 1999 03:42:58 pm" To: mm@i.cz Date: Fri, 22 Oct 1999 10:48:48 -0700 (PDT) Cc: security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Martin Machacek writes: > Well, GRE tunnelling is something completely different from suporting GRE in > NAT. I can imagine doing one-to-one NAT and passing GRE, but doing many to one > NAT and supporting multiple GRE streams is IMHO impossible. There is no > parameter in the GRE encapsulation that would allow you to identify the real > internal recipient if you NAT multiple internal addresses to one external > address. True in general.. however, if all you're using GRE for is PPTP, then you can multiplex on the call identifier in the PPTP/GRE header. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Oct 22 22:35:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail0.mco.bellsouth.net (mail0.mco.bellsouth.net [205.152.48.12]) by hub.freebsd.org (Postfix) with ESMTP id A1E7514CFD for ; Fri, 22 Oct 1999 22:35:48 -0700 (PDT) (envelope-from bertke@bellsouth.net) Received: from bellsouth.net (adsl-78-196-151.sdf.bellsouth.net [216.78.196.151]) by mail0.mco.bellsouth.net (3.3.4alt/0.75.2) with ESMTP id BAA04292 for ; Sat, 23 Oct 1999 01:35:54 -0400 (EDT) Message-ID: <38114983.15EEE676@bellsouth.net> Date: Sat, 23 Oct 1999 05:37:08 +0000 From: Bert Kellerman X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i386) X-Accept-Language: en MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: Re: GRE/IP 47/PPTP References: <199910221748.KAA67824@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > Martin Machacek writes: > > Well, GRE tunnelling is something completely different from suporting GRE in > > NAT. I can imagine doing one-to-one NAT and passing GRE, but doing many to one > > NAT and supporting multiple GRE streams is IMHO impossible. There is no > > parameter in the GRE encapsulation that would allow you to identify the real > > internal recipient if you NAT multiple internal addresses to one external > > address. > > True in general.. however, if all you're using GRE for is PPTP, then > you can multiplex on the call identifier in the PPTP/GRE header. > > -Archie > > Are you referring to the optional 32 bit key field in the GRE header? Won't the > packet on the way back in have a different key field, as this is used for > authenticating the sender, and change? The natd implementation would then need a > way to calculate the expected return key field to differentiate between > connections. However, since there is a 32 bit sequence number in the GRE > header like TCP, I wonder if it would be possible for the router to recreate the > internal sequence numbers and assign each internal client a limited pool out of > the 32 bit outside sequence block. Could this be possible? I mean how many times > has a single TCP session used all 4 million sequence numbers? RFC 1701 states > that this sequence number field is also optional so this might not work for all > vendors. Bert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Oct 23 1:31:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from jason.argos.org (a13b146.neo.rr.com [204.210.197.146]) by hub.freebsd.org (Postfix) with ESMTP id B298114C1F for ; Sat, 23 Oct 1999 01:31:47 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id EAA18382; Sat, 23 Oct 1999 04:31:28 -0400 Date: Sat, 23 Oct 1999 04:31:28 -0400 (EDT) From: Mike Nowlin To: Robert Watson Cc: security@FreeBSD.ORG Subject: Re: Kerberos integration into ports--in particular, SSH In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > It looks like many ports still don't use PAM for authentication. This is > not something I have time to address, it's just a comment that it would be > nice if now that we have PAM, things used PAM :-). Also, it's a little > funky to have an /etc/auth.conf and a /etc/pam.conf -- auth.conf seems > only to affect su? It seems that a lot of the system still doesn't use PAM for auth... A quick grep of ftpd (a recent pamifying project) returns: twikki:/usr/src/libexec/ftpd$ grep -i pam * Makefile:.PATH: ${.CURDIR}/../../lib/libpam/modules/pam_kerberosIV We developed some changes to ftpd to support PAM (haven't submitted them yet -- a couple of quirks to work out), but I'm sure a lot of the system doesn't handle it yet. Is there a doc somewhere which gets into this, or does one need to be written? We're trying to handle security through a PAM/(PostgreSQL|MySQL) interface as much as possible, so we're willing to do a bit of fixing if necessary. --mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Oct 23 22:56:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from bifrost.agrknives.com (bifrost.hos.net [205.238.129.40]) by hub.freebsd.org (Postfix) with ESMTP id 2734B14DF6 for ; Sat, 23 Oct 1999 22:56:12 -0700 (PDT) (envelope-from arussell@bifrost.agrknives.com) Received: (from arussell@localhost) by bifrost.agrknives.com (8.8.8/8.8.8) id AAA11814 for security@freebsd.org; Sun, 24 Oct 1999 00:54:22 -0500 (CDT) (envelope-from arussell) From: "A.G. Russell IV" Message-Id: <199910240554.AAA11814@bifrost.agrknives.com> Subject: kernel patch to detect port scan, without turning on ports... To: security@freebsd.org Date: Sun, 24 Oct 1999 00:54:22 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry if this is redundant, I'm looking for the kernel patch to allow detection of a port scan without turning on each of the ports. I may be confused, and thinking of another OS, but there is always hope. ;-> Thanks in advance. A.G. _______________________________________________________________________________ A.G. Russell IV KC5KFD High Order Software e-mail: ag4@hos.net Phone 512-834-1145 These are my views, on anyone else they would look silly. When it absolutely, positively has to be destroyed by tomorrow... United States Marine Corps ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Oct 23 22:59:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from atdot.dotat.org (atdot.dotat.org [150.101.89.3]) by hub.freebsd.org (Postfix) with ESMTP id C948415084 for ; Sat, 23 Oct 1999 22:59:40 -0700 (PDT) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.3/8.7) id PAA55113; Sun, 24 Oct 1999 15:26:58 +0930 (CST) From: Mark Newton Message-Id: <199910240556.PAA55113@atdot.dotat.org> Subject: Re: kernel patch to detect port scan, without turning on ports... To: arussell@bifrost.agrknives.com (A.G. Russell IV) Date: Sun, 24 Oct 1999 15:26:57 +0930 (CST) Cc: security@FreeBSD.ORG In-Reply-To: <199910240554.AAA11814@bifrost.agrknives.com> from "A.G. Russell IV" at Oct 24, 99 00:54:22 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A.G. Russell IV wrote: > Sorry if this is redundant, > I'm looking for the kernel patch to allow detection of a port scan without > turning on each of the ports. Execute the following sysctl -w net.inet.tcp.log_in_vain=1 sysctl -w net.inet.udp.log_in_vain=1 You'll get a console log message whenever someone tries to reach a port which isn't listening. - mark -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1620-2223 ------------- Fax: +61-8-82231777 ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message