From owner-freebsd-security Sun Jul 4 11:16:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.240.222]) by hub.freebsd.org (Postfix) with ESMTP id 8116214D6A for ; Sun, 4 Jul 1999 11:16:33 -0700 (PDT) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.1) id LAA26538; Sun, 4 Jul 1999 11:16:28 -0700 (PDT) (envelope-from mph) Date: Sun, 4 Jul 1999 11:16:27 -0700 From: Matthew Hunt To: matt Cc: mariusz , security@freebsd.org Subject: Re: ssh2 & class in login.conf not work ? Message-ID: <19990704111627.A26488@wopr.caltech.edu> References: <19990703131951.B86487@wopr.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from matt on Sat, Jul 03, 1999 at 06:46:26PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jul 03, 1999 at 06:46:26PM -0400, matt wrote: > I used the ports collection, I always do... but I don't see any > documentation of how to make ssh2 use login, however I do see the > code now that I glance over the patches directory.. odd.. Anyone > know what option activates this? The patches aren't to make it use login(1), but rather to honor the settings in login.conf (e.g. resource limits). AFAIK, this should happen automatically, but I don't usee ssh2, so I don't know for sure. If you're using ssh2 from ports, and login.conf is not having any effect, perhaps you should contact the maintainer of the port, issei@jp.FreeBSD.org. Matt -- Matthew Hunt * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 4 21:29:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from backup.af.speednet.com.au (af.speednet.com.au [202.135.206.244]) by hub.freebsd.org (Postfix) with ESMTP id D6EFD14BF1 for ; Sun, 4 Jul 1999 21:29:13 -0700 (PDT) (envelope-from andyf@speednet.com.au) Received: from backup.zippynet.iol.net.au (backup.zippynet.iol.net.au [172.22.2.4]) by backup.af.speednet.com.au (8.9.1/8.9.1) with ESMTP id OAA16933; Mon, 5 Jul 1999 14:03:57 +1000 (EST) Date: Mon, 5 Jul 1999 14:03:56 +1000 (EST) From: Andy Farkas X-Sender: andyf@backup.zippynet.iol.net.au To: "N.N.M" Cc: freebsd-security@FreeBSD.ORG Subject: Re: A strange process In-Reply-To: <19990629132406.51156.qmail@hotmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 29 Jun 1999, N.N.M wrote: > Thanks for your replies. I got worried (and still am!), as I am not behind > the console right now, so can't get sure if it's a simple mistake or a true > effort to break in. Anyway, I hope it is just a book on "z" key! (-: Might be a bit late now, but you can run systat(1)'s :vmstat option and look at the interrupts comming in on atkbd0... > > Nazila > > > >From: Nick Hibma > >Reply-To: Nick Hibma > >To: "N.N.M" > >CC: freebsd-security@FreeBSD.ORG > >Subject: Re: A strange process > >Date: Tue, 29 Jun 1999 15:04:17 +0200 (MET DST) > > > >Yup, the guy sitting behind the console has dropped a book on the 'z' > >key. It's most probably not a German or French keyboard. :) > > > >Nick > > > > > >On Tue, 29 Jun 1999, N.N.M wrote: > > > > > Hi everybody, > > > > > > Any knows what the following process can mean? > > > > > > login -p zzzzzzzz > > > > > > I have it in the result of "ps -aux" entry with the owner of "root". It > >also > > > re-appears in a moment after being killed by me! What can it be? > > > > > > > > > Thanks, > > > Nazila M. > > > > > > > > > > > > ______________________________________________________ > > > Get Your Private, Free Email at http://www.hotmail.com > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > > > > >-- > >ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy > > > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- :{ andyf@speednet.com.au Andy Farkas System Administrator Speed Internet Services http://www.speednet.com.au/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 1:15:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from aic-gw.mlink.net (aic-gw.mlink.net [209.104.118.65]) by hub.freebsd.org (Postfix) with SMTP id 8719114E25 for ; Mon, 5 Jul 1999 01:15:07 -0700 (PDT) (envelope-from matt@MLINK.NET) Received: (qmail 25098 invoked by uid 1000); 5 Jul 1999 08:15:06 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Jul 1999 08:15:06 -0000 Date: Mon, 5 Jul 1999 04:15:06 -0400 (EDT) From: matt To: Matthew Hunt Cc: mariusz , security@freebsd.org Subject: Re: ssh2 & class in login.conf not work ? In-Reply-To: <19990704111627.A26488@wopr.caltech.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, 4 Jul 1999, Matthew Hunt wrote: [...] : The patches aren't to make it use login(1), but rather to honor : the settings in login.conf (e.g. resource limits). AFAIK, this should : happen automatically, but I don't usee ssh2, so I don't know for sure. You are totally correct, this was an error on my part. Can I blame it on lack of sleep? SSH2 from ports does honour the login.conf caps.. I would assume at that point that the person who started this thread might have forgotten to do "cap_mkdb /etc/login.conf" : If you're using ssh2 from ports, and login.conf is not having any : effect, perhaps you should contact the maintainer of the port, : issei@jp.FreeBSD.org. : : Matt : : -- : Matthew Hunt * UNIX is a lever for the : http://www.pobox.com/~mph/ * intellect. -J.R. Mashey Matt (two matt's, on the same thread, heh) -- matt@AIC-GW.MLINK.NET To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 3:20:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id AAEEA15280 for ; Mon, 5 Jul 1999 03:20:48 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id LAA10868; Mon, 5 Jul 1999 11:20:32 +0100 (BST) (envelope-from joe) Date: Mon, 5 Jul 1999 11:20:32 +0100 From: Josef Karthauser To: Dag-Erling Smorgrav Cc: "Rodney W. Grimes" , Snob Art Genre , Bill Fink , freebsd-security@FreeBSD.ORG Subject: Re: your mail Message-ID: <19990705112032.D82833@pavilion.net> References: <19990702104239.X69050@pavilion.net> <199907021541.IAA22509@gndrsh.aac.dev.com> <19990702171221.D69050@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Dag-Erling Smorgrav on Sat, Jul 03, 1999 at 11:29:37AM +0200 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jul 03, 1999 at 11:29:37AM +0200, Dag-Erling Smorgrav wrote: > Josef Karthauser writes: > > Does anybody know what the world record for IP addresses on one machine > > is? '-) > > I don't know if it's a world record, but I know of two production > servers which are about to be assigned 700 IP addresses each. We've got 3 /24's on one already. Has been since 2.2.6 - now 3.2 dual processor. Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 3:22: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 4D74015322 for ; Mon, 5 Jul 1999 03:21:57 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id LAA11203; Mon, 5 Jul 1999 11:21:43 +0100 (BST) (envelope-from joe) Date: Mon, 5 Jul 1999 11:21:43 +0100 From: Josef Karthauser To: Ollivier Robert Cc: freebsd-security@FreeBSD.ORG Subject: Re: your mail Message-ID: <19990705112143.E82833@pavilion.net> References: <19990702095858.V69050@pavilion.net> <19990702104239.X69050@pavilion.net> <19990702195432.A45632@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990702195432.A45632@keltia.freenix.fr>; from Ollivier Robert on Fri, Jul 02, 1999 at 07:54:32PM +0200 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jul 02, 1999 at 07:54:32PM +0200, Ollivier Robert wrote: > According to Josef Karthauser: > > I've told him that I'm shutting down his internet access. That said he's > > been a naughty boy and changed his IP address a couple of times to other > > people's. He thinks that I don't know, but of course I've got changing > > ARP addresses. What I'd like to do now is ignore his MAC address on the > > This is not a technical problem. This is a human problem. Don't try to apply > technical solutions to human problems. He's bad, spank him. You don't have > time to waste with such users, just remove them. > > I mean it and it is that simple. Of course it is - but not as much fun. It's much more fun confusing him ;) [how smart does he think he is exactly?] Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 3:45:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f273.hotmail.com [207.82.251.164]) by hub.freebsd.org (Postfix) with SMTP id 8809514C4B for ; Mon, 5 Jul 1999 03:45:26 -0700 (PDT) (envelope-from madrapour@hotmail.com) Received: (qmail 71257 invoked by uid 0); 5 Jul 1999 10:45:25 -0000 Message-ID: <19990705104525.71256.qmail@hotmail.com> Received: from 195.96.144.201 by www.hotmail.com with HTTP; Mon, 05 Jul 1999 03:45:24 PDT X-Originating-IP: [195.96.144.201] From: N.N.M To: freebsd-security@freebsd.org Subject: IDENTD Date: Mon, 05 Jul 1999 03:45:24 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi everybody, I'm not sure if this subject was discussed list before or not. If so, sorry for inconvenience. (-: The question is related to "identd". Is it necessary for Mailing System to work properly or not? And if not, can I block its port (113) on the firewall without causing any problem for the services? I read somewhere that it's better to block "identd connections" by "reset action in IPFW" instead of "deny" or something like that. Blocking the port with using "deny action" makes the services like "sendmail" or "ircd" very slow. thanks, Nazila M. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 3:59:18 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 894151535E; Mon, 5 Jul 1999 03:58:49 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id MAA14227; Mon, 5 Jul 1999 12:58:44 +0200 (CEST) (envelope-from des) To: Josef Karthauser Cc: Ollivier Robert , chat@freebsd.org Subject: Re: your mail References: <19990702095858.V69050@pavilion.net> <19990702104239.X69050@pavilion.net> <19990702195432.A45632@keltia.freenix.fr> <19990705112143.E82833@pavilion.net> From: Dag-Erling Smorgrav Date: 05 Jul 1999 12:58:44 +0200 In-Reply-To: Josef Karthauser's message of "Mon, 5 Jul 1999 11:21:43 +0100" Message-ID: Lines: 20 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Josef Karthauser writes: > On Fri, Jul 02, 1999 at 07:54:32PM +0200, Ollivier Robert wrote: > > This is not a technical problem. This is a human problem. Don't try to apply > > technical solutions to human problems. He's bad, spank him. You don't have > > time to waste with such users, just remove them. > Of course it is - but not as much fun. It's much more fun confusing him ;) > [how smart does he think he is exactly?] Personally, I find it much more gratifying to just walk in, confiscate the Ethernet cable, and walk right out again. Of course, that's just for effect (and personal gratification); you can't watch his face while you pull the cable from the patch panel or disable the port he's hooked up to on backbone switch, since you don't let him into the NOC. (Yes, I used to read bofh.* and the Scary Devil Monastery on a regular basis. I don't have time for that any more, unfortunately.) 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 Jul 5 4:30:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f295.hotmail.com [207.82.251.186]) by hub.freebsd.org (Postfix) with SMTP id 82AC414DB9 for ; Mon, 5 Jul 1999 04:30:30 -0700 (PDT) (envelope-from madrapour@hotmail.com) Received: (qmail 28795 invoked by uid 0); 5 Jul 1999 11:30:29 -0000 Message-ID: <19990705113029.28794.qmail@hotmail.com> Received: from 195.96.144.201 by www.hotmail.com with HTTP; Mon, 05 Jul 1999 04:30:28 PDT X-Originating-IP: [195.96.144.201] From: N.N.M To: jcarlos@bahianet.com.br Cc: freebsd-security@freebsd.org Subject: Re: IDENTD Date: Mon, 05 Jul 1999 04:30:28 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for information. 1) Could you tell me please if I can block this sort of connection (ident) without causing any problem or inconvenience for the services like mail or so? 2) Can it be consequnced: it is basically better to block the all conncetions we want, by using "reject" instead of "deny"? Based on what you said (and I read about), using "reject" decreases the further re-attemting conncetions, so it will decrease the unusable and unwanted traffic as well. Is it right? Nazila M. >From: "Joao Carlos" >To: "N.N.M" >Subject: Re: IDENTD >Date: Mon, 5 Jul 1999 07:52:33 -0300 >MIME-Version: 1.0 >From jcarlos@bahianet.com.br Mon Jul 5 10:50:29 1999 >Received: from jcarlos (jcarlos.bahianet.com.br [200.223.88.250])by >postman.bahianet.com.br (8.9.3/8.9.3) with SMTP id HAA22873for >; Mon, 5 Jul 1999 07:46:52 -0300 (EST) >Message-ID: <002901bec6d4$7d809de0$fa58dfc8@bahianet.com.br> >References: <19990705104525.71256.qmail@hotmail.com> >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 > > > I read somewhere that it's better to block "identd connections" by >"reset > > action in IPFW" instead of "deny" or something like that. Blocking the >port > > with using "deny action" makes the services like "sendmail" or "ircd" >very > > slow. > > >Sure it is, since with the deny action, the service that is trying to >access >your firewall does not get ny answer, the try again. 3 times in general. >And >if you use reject instead, the service gets the reject answer and stop >trying. > > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 4:43:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from asteroid.svib.ru (asteroid.svib.ru [195.151.166.145]) by hub.freebsd.org (Postfix) with ESMTP id 5F0C614DB9 for ; Mon, 5 Jul 1999 04:43:23 -0700 (PDT) (envelope-from tarkhil@asteroid.svib.ru) Received: from shuttle.svib.ru (shuttle.svib.ru [195.151.166.144]) by asteroid.svib.ru (8.9.3/8.9.3) with ESMTP id PAA06608 for ; Mon, 5 Jul 1999 15:43:19 +0400 (MSD) (envelope-from tarkhil@asteroid.svib.ru) Received: from shuttle.svib.ru (minas-tirith.pol.ru [127.0.0.1]) by shuttle.svib.ru (8.9.3/8.8.8) with ESMTP id PAA56227 for ; Mon, 5 Jul 1999 15:47:13 +0400 (MSD) (envelope-from tarkhil@shuttle.svib.ru) Message-Id: <199907051147.PAA56227@shuttle.svib.ru> To: security@freebsd.org Reply-To: tarkhil@asteroid.svib.ru Subject: stunnel troubles X-URL: http://freebsd.svib.ru Date: Mon, 05 Jul 1999 15:47:12 +0400 From: Alex Povolotsky Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! Can someone with experience in stunnelling pop3 help me? I've done everything lik described, and nothing worked :-) Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 5:41:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from postman.bahianet.com.br (postman.bahianet.com.br [200.223.88.38]) by hub.freebsd.org (Postfix) with ESMTP id 4AE2415341 for ; Mon, 5 Jul 1999 05:41:28 -0700 (PDT) (envelope-from jcarlos@bahianet.com.br) Received: from jcarlos (jcarlos.bahianet.com.br [200.223.88.250]) by postman.bahianet.com.br (8.9.3/8.9.3) with SMTP id JAA29074; Mon, 5 Jul 1999 09:37:44 -0300 (EST) Message-ID: <000b01bec6e3$fac76540$fa58dfc8@bahianet.com.br> From: "Joao Carlos" To: "N.N.M" Cc: References: <19990705113029.28794.qmail@hotmail.com> Subject: Re: IDENTD Date: Mon, 5 Jul 1999 09:43:26 -0300 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 > Thanks for information. you're welcome > > 1) Could you tell me please if I can block this sort of connection (ident) > without causing any problem or inconvenience for the services like mail or > so? Look, unless you have a big reason to block, i think if you run sendmail or popper in your machie, you shouldn't block. the services won't stop working, but sendmail and popper likes to check who is using the services. You can block, if you want, incoming requests for port 113, but i really think you should let outgoing connections to be completed. IRC uses identd every time the client connects, but don't worry, if you block everybody will continue connecting without problems. That's my own opinion. > > 2) Can it be consequnced: it is basically better to block the all > conncetions we want, by using "reject" instead of "deny"? Based on what you > said (and I read about), using "reject" decreases the further re-attemting > conncetions, so it will decrease the unusable and unwanted traffic as well. > Is it right? Yes it is. The basic difference some people like to use DENY is that the otehr machine does not know what is happening... i mean... if you use reject, The person is trying to connect you know you are rejecting that connection... but if you use deny, onl;y you know that...for example... if you REJECT an ICMP packet, the person will know you're rejecting, but if you DENY, that person will only see timed out messages. Please, if i'm wrong in anything , somebody tells me that. Joao Carlos jcarlos@bahianet.com.br To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 5:58:25 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 32A4A14FBE for ; Mon, 5 Jul 1999 05:58:10 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id OAA16892; Mon, 5 Jul 1999 14:57:44 +0200 (CEST) (envelope-from des) To: "N.N.M" Cc: jcarlos@bahianet.com.br, freebsd-security@FreeBSD.ORG Subject: Re: IDENTD References: <19990705113029.28794.qmail@hotmail.com> From: Dag-Erling Smorgrav Date: 05 Jul 1999 14:57:43 +0200 In-Reply-To: "N.N.M"'s message of "Mon, 05 Jul 1999 04:30:28 PDT" Message-ID: Lines: 29 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "N.N.M" writes: > 2) Can it be consequnced: it is basically better to block the all > conncetions we want, by using "reject" instead of "deny"? Based on what you > said (and I read about), using "reject" decreases the further re-attemting > conncetions, so it will decrease the unusable and unwanted traffic as well. > Is it right? Depends how paranoid you are, and how exposed you are. If you block, clients will sit around waiting for an answer until they time out (normally after 75 seconds, I think). If you reject, they'll get an immediate negative reply and give up at once. So, from the client's POV, reject is better. On the other hand, if you get flooded (syn flood, port scan, whatever), a reject rule will generate large amounts of ICMP traffic which not only eats local resources but may bring down your upstream routers if the attacker spoofs his source address (you're sending out ICMP packets to zillions of invalid addresses, and the router blows up trying to find out where to send them). You can avoid these problems to a certain degree by using a traffic shaper (altq, dummynet) to impose a rate limit on outgoing SYN+ACK (easier on the router) and SYN cookies to avoid keeping a list of received SYNs (easier on yourself). 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 Jul 5 9:36:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from madeline.boneyard.lawrence.ks.us (madeline.boneyard.lawrence.ks.us [24.124.33.226]) by hub.freebsd.org (Postfix) with ESMTP id E902314D95 for ; Mon, 5 Jul 1999 09:36:18 -0700 (PDT) (envelope-from bsd-sec@boneyard.lawrence.ks.us) Received: from madeline.boneyard.lawrence.ks.us (bsd-sec@madeline.boneyard.lawrence.ks.us [24.124.33.226]) by madeline.boneyard.lawrence.ks.us (8.9.3/8.9.3) with ESMTP id LAA11103; Mon, 5 Jul 1999 11:36:42 -0500 (CDT) Date: Mon, 5 Jul 1999 11:36:41 -0500 (CDT) From: "Stephen D. Spencer" To: Josef Karthauser Cc: freebsd-security@FreeBSD.ORG Subject: Re: your mail In-Reply-To: <19990702111953.Z69050@pavilion.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 Fri, 2 Jul 1999, Josef Karthauser wrote: > On Fri, Jul 02, 1999 at 03:10:47AM -0700, Cliff Skolnick wrote: > > > > Add permanent, static arp entries for all your legit mac/ip combos, then > > [...] > > That's the cookie. Thanks :) > Or a simpler method might be to simply statically add his mac to your ARP table with a non-routable IP address. Had to do this on a Cisco. Rather simple and is quite amusing to observe customer reactions. :) Don't worry about the future. Stephen Spencer Or worry, but understand that worrying Lawrence, KS is about as effective as trying to solve an algebra equation by chewing bubble gum. -lee perry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 13:51:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.249.195.3]) by hub.freebsd.org (Postfix) with ESMTP id 40DD614ED3 for ; Mon, 5 Jul 1999 13:51:18 -0700 (PDT) (envelope-from paulo@nlink.com.br) Received: from localhost (paulo@localhost) by mirage.nlink.com.br (8.9.3/8.9.1) with SMTP id RAA00245 for ; Mon, 5 Jul 1999 17:51:13 -0300 (EST) Date: Mon, 5 Jul 1999 17:51:13 -0300 (EST) From: Paulo Fragoso To: freebsd-security@freebsd.org Subject: IMAP or QPOPPER Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm thiking put IMAP4 server and its ipop3d in my mail server. Are there any security problems with imap-4.5? I've used qpopper since the begin and I would like to listen some opinions about IMAP :-) Thanks, Paulo Fragoso. ------ " ... Overall we've found FreeBSD to excel in performace, stability, technical support, and of course price. Two years after discovering FreeBSD, we have yet to find a reason why we switch to anything else" -David Filo, Yahoo! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 21:18:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from luckyscasino.com (unknown [207.124.92.105]) by hub.freebsd.org (Postfix) with SMTP id EF51F153A3 for ; Mon, 5 Jul 1999 21:17:27 -0700 (PDT) (envelope-from affiliate@luckyscasino.com) Date: Mon, 05 Jul 1999 22:15:17 -0600 X-Mailer: CyberCreek Avalanche 98 Demo; RSR Build:33666 Subject: Earn Cash Content-Type: text/plain; charset="us-ascii" Message-Id: From: affiliate@luckyscasino.com To: FreeBSD-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Webmaster, We are a business conducting business and this is not unsolicited bulk email. We have purchased your email address from an Internet marketing center. If you do not wish to receive further notices from Lucky's Casino, please reply to this e-mail and type "UNSUBSCRIBE" in the subject field. Want to earn extra cash? Join the Lucky's Casino affiliate program to earn revenues from your website. By participating in this mutually beneficial program, webmasters like your-self will get the opportunity to earn extra cash and become a part of the fastest growing industry in the world. Need more Info? If you are interested in becoming an affiliate of Lucky's Casino, and would like to find out more about this program, please visit: http://207.236.72.231/TrackA.asp Please let us know if you have any comments or questions by e-mailing us at affiliate@luckyscasino.com Regards, The Staff at Lucky's We hope you have a great day! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 21:18:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from luckyscasino.com (unknown [207.124.92.105]) by hub.freebsd.org (Postfix) with SMTP id 35ECC153B2 for ; Mon, 5 Jul 1999 21:17:27 -0700 (PDT) (envelope-from affiliate@luckyscasino.com) Message-Id: To: FreeBSD-security@freebsd.org Date: Mon, 05 Jul 1999 22:16:04 -0600 From: affiliate@luckyscasino.com Subject: Earn Cash X-Mailer: CyberCreek Avalanche 98 Demo; RSR Build:33666 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Webmaster, We are a business conducting business and this is not unsolicited bulk email. We have purchased your email address from an Internet marketing center. If you do not wish to receive further notices from Lucky's Casino, please reply to this e-mail and type "UNSUBSCRIBE" in the subject field. Want to earn extra cash? Join the Lucky's Casino affiliate program to earn revenues from your website. By participating in this mutually beneficial program, webmasters like your-self will get the opportunity to earn extra cash and become a part of the fastest growing industry in the world. Need more Info? If you are interested in becoming an affiliate of Lucky's Casino, and would like to find out more about this program, please visit: http://207.236.72.231/TrackA.asp Please let us know if you have any comments or questions by e-mailing us at affiliate@luckyscasino.com Regards, The Staff at Lucky's We hope you have a great day! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 23: 4:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from abatis.sweb.com (ip-140-066.gw.total-web.net [209.187.140.66]) by hub.freebsd.org (Postfix) with ESMTP id 0190614C2A for ; Mon, 5 Jul 1999 23:04:17 -0700 (PDT) (envelope-from zaph0d@abatis.sweb.com) Received: from localhost (zaph0d@localhost) by abatis.sweb.com (8.9.3/8.9.3) with SMTP id CAA71316; Tue, 6 Jul 1999 02:04:07 -0400 (EDT) Date: Tue, 6 Jul 1999 02:04:04 -0400 (EDT) From: zaph0d To: affiliate@luckyscasino.com Cc: FreeBSD-security@FreeBSD.ORG Subject: Re: Earn Cash 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 I hope someone at FreeBSD.org has already mailed the admins of whomever's system this orignated? On Mon, 5 Jul 1999 affiliate@luckyscasino.com wrote: > Dear Webmaster, > > We are a business conducting business and this is not unsolicited bulk email. We have purchased your email address from an Internet marketing center. If you do not wish to receive further notices from Lucky's Casino, please reply to this e-mail and type "UNSUBSCRIBE" in the subject field. > > Want to earn extra cash? > Join the Lucky's Casino affiliate program to earn revenues from your website. By participating in this mutually beneficial program, webmasters like your-self will get the opportunity to earn extra cash and become a part of the fastest growing industry in the world. > > Need more Info? > If you are interested in becoming an affiliate of Lucky's Casino, and would like to find out more about this program, please visit: > > http://207.236.72.231/TrackA.asp > > > Please let us know if you have any comments or questions by e-mailing us at affiliate@luckyscasino.com > > > Regards, > The Staff at Lucky's > We hope you have a great day! > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 5 23:12:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from ontario.mooseriver.com (erie.mooseriver.com [208.138.31.117]) by hub.freebsd.org (Postfix) with ESMTP id 027B114C0C for ; Mon, 5 Jul 1999 23:12:54 -0700 (PDT) (envelope-from jgrosch@ontario.mooseriver.com) Received: (from jgrosch@localhost) by ontario.mooseriver.com (8.9.3/8.9.1) id XAA14385; Mon, 5 Jul 1999 23:11:59 -0700 (PDT) (envelope-from jgrosch) Date: Mon, 5 Jul 1999 23:11:59 -0700 From: Josef Grosch To: zaph0d Cc: affiliate@luckyscasino.com, FreeBSD-security@FreeBSD.ORG Subject: Re: Earn Cash Message-ID: <19990705231159.A14359@ontario.mooseriver.com> Reply-To: jgrosch@MooseRiver.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from zaph0d on Tue, Jul 06, 1999 at 02:04:04AM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jul 06, 1999 at 02:04:04AM -0400, zaph0d wrote: > I hope someone at FreeBSD.org has already mailed the admins of whomever's > system this orignated? > > > > On Mon, 5 Jul 1999 affiliate@luckyscasino.com wrote: > > > Dear Webmaster, > > > > We are a business conducting business and this is not unsolicited bulk email. We have purchased your email address from an Internet marketing center. If you do not wish to receive further notices from Lucky's Casino, please reply to this e-mail and type "UNSUBSCRIBE" in the subject field. [ YATTA, YATTA, YA ] I am sure that right about now the sys admins at the upstream provider of this loser are yanking his account. I am also sure that these same sys admins have gotten lots of email from this list, informaing them of this little "problem" Josef -- Josef Grosch | Another day closer to a | FreeBSD 3.2 jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 1:49:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.thegrid.net (smtp.thegrid.net [209.162.1.11]) by hub.freebsd.org (Postfix) with SMTP id 460A014BEF for ; Tue, 6 Jul 1999 01:49:18 -0700 (PDT) (envelope-from dean@thegrid.net) Received: (qmail 14534 invoked from network); 6 Jul 1999 08:49:17 -0000 Received: from pop.thegrid.net (209.162.1.5) by smtp.thegrid.net with SMTP; 6 Jul 1999 08:49:17 -0000 Received: from remus (oak-ts1-h1-48-198.ispmodems.net [209.162.48.198]) by pop.thegrid.net (8.9.1a/8.9.1) with SMTP id BAA17265 for ; Tue, 6 Jul 1999 01:49:15 -0700 (PDT) Message-Id: <4.1.19990706014149.00963570@mail.thegrid.net> X-Sender: i289861@mail.thegrid.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 06 Jul 1999 01:47:18 -0700 To: freebsd-security@FreeBSD.ORG From: Dean Subject: Re: Tracking Root Users In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 03:04 PM 7/1/99 -0400, Master Of Spirits wrote: >I have found that the simplest way (which I use myself) it a few >modifictions to the shells themself, and to syslog.conf. For the purposes >of tracking commands used by uid 0, the shells script waits for su to >send a confirmed su signal and then logs to a log file and continues to >log all commands sent through the shell untill su sends a termination >signal. This bypasses syslog entirely save for the notification of a >failed or successful SU attempts. Minor adustments could also pipe this >feedback to a printer or external device, thus removing the possibility of >hackers editing the logs themselves. > >-= UNACOM System Admin =- That is a great idea, but an attacker could simply change shells directly after su-ing. I suppose all you need do is build this extra logging into each shell you have on your machines. Course, the attacker could import his own shell to get around that.... Maybe some sort of program that listens to the tty. My two cents, Dean ------------------------------------------------------------------------------- A train stops at a train station, a bus stops at a bus staion. On my desk, I have a workstation.... ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 2:50:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from iprolink.co.nz (iprolink.co.nz [202.36.121.1]) by hub.freebsd.org (Postfix) with SMTP id 550EF153B4 for ; Tue, 6 Jul 1999 02:50:47 -0700 (PDT) (envelope-from zas@iprolink.co.nz) Received: from iprolink.co.nz (p5-max41.akl.ihug.co.nz [206.18.102.5]) by iprolink.co.nz (2.54.1/2.54.1) with ESMTP id VAA108384 for ; Tue, 6 Jul 1999 21:50:45 +1200 Message-ID: <3781D395.A4587B90@iprolink.co.nz> Date: Tue, 06 Jul 1999 21:59:49 +1200 From: Zane Shailer X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: auth 4484964d unsubscribe freebsd-security zas@iprolink.co.nz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth 4484964d unsubscribe freebsd-security zas@iprolink.co.nz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 2:53:12 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 2BA89153C6 for ; Tue, 6 Jul 1999 02:52: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.8.8/8.8.8) with SMTP id FAA04999; Tue, 6 Jul 1999 05:52:44 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Tue, 6 Jul 1999 05:52:44 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Darren Reed Cc: Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: <199907011413.AAA02422@cheops.anu.edu.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 On Fri, 2 Jul 1999, Darren Reed wrote: > > It appears that the process accounting in FreeBSD is a remnant of a bygone > > era, where all cpu time was costly and had to be accounted for. From a > > security perspective, process accounting would need to: > > - log uid, gid, and euid of the user calling the process. > > - log the process name, executable name, and path to the executable. > > - log arguments to the process being executed. > > - log date and amount of time the process took to complete. > > - log the tty the user who called the process executed it from. > > Process accounting provides information for what it was intended to do. > Attempting to use that information for different purposes is going to > lead you down the garden path. Process accounting is still useful, in > its current form, so `fixing' it is not the right thing to do. > > What's required here is auditting. I *think* the POSIX security module > being worked on at present is more in line with what you're aiming to > achieve. If you've got access to Solaris, checkout the man pages for > auditd, bsm, etc. Sorry for the delay in getting back to you -- I've been traveling for the last week and have just settled down in Cambridge to do a few weeks research on tamper-proof hardware :-). Indeed, I am working on a POSIX.1e auditing module for FreeBSD. I've largely completed userland libraries, and Nate Williams and myself are working on adapting the KTRACE interface to provide a nice backend for it. I have an initial version online that captures a few syscalls for the sake of demonstration, but I have a lot of new code that is currently on my notebook here in the UK, but not connected to the network. I've been playing with an intrusion detection interface for the auditing support, and have a few modules that catch the standard things (creation of setuid binaries (i.e., backdoors), etc). Similarly, I have a module that looks for long strings being passed as arguments to programs, as well as coredumps in daemons that have bound network ports. I have a simple expression language that allows a generic IDS module to watch for sets of events with certain properties, although the parser needs some more work. The problem with KTRACE is that it doesn't have a concept of discrete syscalls, it's really more of a log of events, and various kernel calls (such as namei) create log entries once in a while, which just happen to be in a useful order. We'd like to modify it to generate transactions of a sort that are discrete packages of entries in a well-defined and useful order, which can then be converted to POSIX.1e-style records for use in userland. My hope is to put a lot of this code online when I return from the UK in early August. I haven't made any forward progress in the KTRACE changes and my code largely relies on the hackish hooks in syscalls to gather data. I believe the kernel changes are the primary interest to Nate, so perhaps he could comment on how such changes could be made. 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, Computing Laboratory at Cambridge University 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 Jul 6 2:55:39 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 17BDE153CC for ; Tue, 6 Jul 1999 02:55:36 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id FAA05009; Tue, 6 Jul 1999 05:55:34 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Tue, 6 Jul 1999 05:55:34 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Dean Cc: freebsd-security@FreeBSD.ORG Subject: Re: Tracking Root Users In-Reply-To: <4.1.19990706014149.00963570@mail.thegrid.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 With auditing support in kernel, this should not be a problem. However, it would be necessary to protect a userland support daemon from interference by other processes. There are various ways to do this that might be tied into the securelevel system. One thing I had in mind was processes flagged appropriately would not be signalable/debuggable/etc after the securelevel was raised above the processes starting securelevel. This would mean that auditd started before the bumping of the securelevel would be fairly immune to interference (leaving aside lack of disk space) following boot. This would not protect it against denial of service due to lack of disk space, etc, etc, but would at least prevent it from being killed or attacked using debugging. Presumably the config file would also need to be protected, etc. On Tue, 6 Jul 1999, Dean wrote: > At 03:04 PM 7/1/99 -0400, Master Of Spirits wrote: > >I have found that the simplest way (which I use myself) it a few > >modifictions to the shells themself, and to syslog.conf. For the purposes > >of tracking commands used by uid 0, the shells script waits for su to > >send a confirmed su signal and then logs to a log file and continues to > >log all commands sent through the shell untill su sends a termination > >signal. This bypasses syslog entirely save for the notification of a > >failed or successful SU attempts. Minor adustments could also pipe this > >feedback to a printer or external device, thus removing the possibility of > >hackers editing the logs themselves. > > > >-= UNACOM System Admin =- > > That is a great idea, but an attacker could simply change shells directly > after su-ing. I suppose all you need do is build this extra logging into > each shell you have on your machines. Course, the attacker could import > his own shell to get around that.... Maybe some sort of program that > listens to the tty. > My two cents, > Dean > ------------------------------------------------------------------------------- > A train stops at a train station, a bus stops at a bus > staion. On my desk, I have a workstation.... > ------------------------------------------------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University 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 Jul 6 4:10: 6 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 8440E153D7 for ; Tue, 6 Jul 1999 04:09:51 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id HAA05180; Tue, 6 Jul 1999 07:09:43 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Tue, 6 Jul 1999 07:09:43 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Vladimir Mencl, MK, susSED" Cc: security@FreeBSD.ORG Subject: Re: X security (was Re: X and 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 Sat, 26 Jun 1999, Vladimir Mencl, MK, susSED wrote: > On Sat, 26 Jun 1999, Robert Watson wrote: > > ... > > > > > I personally like to run incoming tunneled X sessions from under-trusted > > hosts in Xnest, but maybe that's just me... :-) > > > Does it give more security? My belief is yes: suppose you slogin into an untrusted host where you want to run an X application. Having the ssh session point to an Xnest would prevent a remote user with privilege capable of reading your .Xauthority file from grabbing shots of your screen, etc. As I frequently log into a variety of hosts at a variety of institutions, most of which are most likely not mutually trusting, and I have privileged access to a number of their machines, I'd rather not have one compromised as the result of another being compromised. An X display is an excellent way to spread suffering, and Xnest seems like a decent answer to the problem, as it isolates applications. I posted this in bugtraq a few years ago, and someone responded that isolation of applications on the X display was supposed to go into a future version of X (broadway?) but I never heard anything further. I have not inspected Xnest source, so it might be worth doing sometime. My suspicion is it actually renders the virtual display as a bitmap. Probably a better alternative would be to write an X proxy that speaks the X protocol and prevents unfortunate things from happening (grabs, xinput capture, etc?), perhaps one that spoke to a window manager with security extensions to allow you to take advantage of knowledge of window behavior. 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, Computing Laboratory at Cambridge University 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 Jul 6 6: 0:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 07A2614BD3 for ; Tue, 6 Jul 1999 06:00:33 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id WAA10358 for ; Tue, 6 Jul 1999 22:30:29 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA25027; Tue, 6 Jul 1999 22:30:23 +0930 Date: Tue, 6 Jul 1999 22:30:21 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: security@freebsd.org Subject: Improved libcrypt ready for testing 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 just finished polishing off a replacement crypt library, based on some earlier work by Brandon Gillespie, which provides the following features: * Support for MD5, SHA-1, DES (two forms), and Blowfish password (a la OpenBSD) * Password crypt format defined by login capabilities Two new login capabilities are added: localcipher - which password hash algorithm do we use for this login class? localcipherrounds - how many encryption rounds should we use (for algorithms which support it, namely New-DES and Blowfish). The 'New-DES' algorithm has actually been present in the code forever, but commented out. In contrast to the 'traditional' DES password format, NewDES passwords have 4 bytes of encoded salt (instead of 2), with no maximum password length (instead of an 8-character limit). It can also accept a definable number of encryption rounds, so is somewhat 'future-proof'. The SHA-1 algorithm is directly analogous to the FreeBSD-standard MD5 algorithm. The Blowfish algorithm is ported from OpenBSD, and also supports a customizable number of encryption rounds (from 2^4 up to 2^31). Using login.conf, you could (for example) set your root password to be a 2^12 round Blowfish password (which takes ~35 seconds to crypt() on my P120), your regular user passwords to be SHA-1, and a subset (say, users who you want to share password entries with a Sun machine) as Old-DES format. I've changed the default password format (i.e., in the absence of an overriding login class) to SHA-1 for new passwords; this is fairly arbitrary but based on the general feeling that SHA-1 is a 'stronger' algorithm than MD5. In order to accomodate multiple algorithms better, the crypted passwords have the format $token$hash$password where "token" is a string, not a numerical identifier (i.e., '1' for current MD5 passwords, and "2a" for openbsd blowfish passwords). Using a numeric identifier is non-portable across vendors without an assigning authority, and there's the possibility of collision should another vendor choose the same number as us for a different algorithm (of course, they could still choose an incompatible algorithm using MD5, etc, but this is less likely). (Cisco seem to use either our (old) MD5 algorithm for their routers, or one with the same form) The 'oldmd5' and 'openbsd' localcipher values will produce passwords in the traditional format, and 'md5' and 'blowfish' produce the new "$MD5"/"$Blowfish$" tokens. 'des', 'newdes', and 'sha1' are the other possible values. The source itself is split between the "exportable" ciphers and the restricted ones under secure/ - in contrast to the previous version, the library is only built from under /usr/src/lib/libcrypt, which pulls in the extra files from /usr/src/secure/lib/libcrypt if it exists. This means no duplication of code between the two directories. In order to support blowfish passwords, the blowfish encryption/decryption code from openbsd has been included - this probably should be broken out into its own library, perhaps combined with the DES routines into a libcrypto. The new library (and changes to passwd(1)) is available at http://www.physics.adelaide.edu.au/~kkennawa/new-crypt.tar.gz and should be extracted over the top of your /usr/src tree (since the changes are so large it's not worthwhile providing diffs). I'd appreciate it if people could test this and see how it goes (back up your current libcrypt* first!!) - I've tested it myself fairly thoroughly, but there may be some bootstrap or backwards-compatability issues, and I haven't yet tested it on an existing OpenBSD password file. I'd also like to hear any feedback about the code itself. Thanks to Brandon Gillespie (who committed the original code on which this version is based) and Mark Murray for their help. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 6:34:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 926C814F2B for ; Tue, 6 Jul 1999 06:34:11 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 58E2B78; Tue, 6 Jul 1999 21:34:10 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Kris Kennaway Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-reply-to: Your message of "Tue, 06 Jul 1999 22:30:21 +0930." Date: Tue, 06 Jul 1999 21:34:10 +0800 From: Peter Wemm Message-Id: <19990706133410.58E2B78@overcee.netplex.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: [..] > In order to accomodate multiple algorithms better, the crypted passwords have > the format $token$hash$password where "token" is a string, not a numerical > identifier (i.e., '1' for current MD5 passwords, and "2a" for openbsd > blowfish > passwords). Using a numeric identifier is non-portable across vendors without > an assigning authority, and there's the possibility of collision should > another vendor choose the same number as us for a different algorithm (of > course, they could still choose an incompatible algorithm using MD5, etc, but > this is less likely). (Cisco seem to use either our (old) MD5 algorithm for > their routers, or one with the same form) I'd strongly suggest encoding the number of rounds as well, ie: $token$salt$rounds$password That way plain old crypt(3) can work without needing to dive off to /etc/login.conf.db. When passwd(1) generates the string it can set the number of rounds either from the count in login.conf, or perhaps some sort of time count. For example, suppose you specify that the root login is to have a minimum number of X rounds, and the has has to run for at least N seconds on this system. So, it could scale according to cpu speed. Also, I don't think using $2a$ for openbsd blowfish is a good idea - use $2$ directly since it's what they use. Ther is no need to be different for the sake of it. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 6:56:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 6F82615401 for ; Tue, 6 Jul 1999 06:56:37 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id XAA10030; Tue, 6 Jul 1999 23:26:33 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA22357; Tue, 6 Jul 1999 23:26:30 +0930 Date: Tue, 6 Jul 1999 23:26:28 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Peter Wemm Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <19990706133410.58E2B78@overcee.netplex.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 On Tue, 6 Jul 1999, Peter Wemm wrote: > I'd strongly suggest encoding the number of rounds as well, ie: > $token$salt$rounds$password For the two algorithms which currently support variable rounds, it's already encoded into the password: $Blowfish$xy$ following the OpenBSD format (xy = log2 rounds), and _ for New-DES. ( encoded as a base-64 binary value). I was thinking about defining the general format as you suggest, and leaving the "rounds" null (or zero) for things like MD5/SHA-1 which have a static count (or maybe allowing variable rounds there, although I don't know if there are cryptographic implications to doing that). It would probably also be worthwhile redefining New-DES and our blowfish format to fit this common form: $DES$$salt$hash The question then becomes whether we make implementation-defined or always log base-2? > That way plain old crypt(3) can work without needing to dive off to > /etc/login.conf.db. When passwd(1) generates the string it can set the > number of rounds either from the count in login.conf, or perhaps some sort > of time count. For example, suppose you specify that the root login is > to have a minimum number of X rounds, and the has has to run for at least > N seconds on this system. So, it could scale according to cpu speed. That's an interesting idea. I'll have to think about that. > Also, I don't think using $2a$ for openbsd blowfish is a good idea - use > $2$ directly since it's what they use. Ther is no need to be different for > the sake of it. Are you sure? from lib/libc/crypt/bcrypt.c static void encode_salt(salt, csalt, clen, logr) char *salt; u_int8_t *csalt; u_int16_t clen; u_int8_t logr; #endif { salt[0] = '$'; salt[1] = BCRYPT_VERSION; salt[2] = 'a'; salt[3] = '$'; snprintf(salt + 4, 4, "%2.2u$", logr); encode_base64((u_int8_t *) salt + 7, csalt, clen); } Having said that, the version doesn't actually seem to be used in their code ($2$ is equivalent to $2a$), but it's there presumably for forward compatability. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 9: 5:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 30AB015421 for ; Tue, 6 Jul 1999 09:05:26 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id DD35C78; Wed, 7 Jul 1999 00:05:24 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Kris Kennaway Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-reply-to: Your message of "Tue, 06 Jul 1999 23:26:28 +0930." Date: Wed, 07 Jul 1999 00:05:24 +0800 From: Peter Wemm Message-Id: <19990706160524.DD35C78@overcee.netplex.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > On Tue, 6 Jul 1999, Peter Wemm wrote: > > > I'd strongly suggest encoding the number of rounds as well, ie: > > $token$salt$rounds$password > > For the two algorithms which currently support variable rounds, it's > already encoded into the password: OK. > I was thinking about defining the general format as you suggest, and leaving > the "rounds" null (or zero) for things like MD5/SHA-1 which have a static > count (or maybe allowing variable rounds there, although I don't know if ther e > are cryptographic implications to doing that). I guess the main thing is to not define any new methods without the rounds in there somehow. > It would probably also be worthwhile redefining New-DES and our blowfish > format to fit this common form: > > $DES$$salt$hash IMHO, don't change the existing new-des stuff since it's partially understood in a number of places already. > The question then becomes whether we make implementation-defined or > always log base-2? I'd suggest leave it implementation defined since there's no telling how fast or slow a given algorithm may be. IMHO, do it either log2 or log10 or do some sort of power encoding, ie literally store 2 and 12 for 2^12 or 10 and 6 for 10^6 rounds. > > That way plain old crypt(3) can work without needing to dive off to > > /etc/login.conf.db. When passwd(1) generates the string it can set the > > number of rounds either from the count in login.conf, or perhaps some sort > > of time count. For example, suppose you specify that the root login is > > to have a minimum number of X rounds, and the has has to run for at least > > N seconds on this system. So, it could scale according to cpu speed. > > That's an interesting idea. I'll have to think about that. The risk is that there has to be a reasonable minimum, otherwise an evil hacker (TM) might run some cpu burners to slow down the timing to get a weaker number of rounds. There's also the risk that your K7-1000 encodes and exports a password to a 386SX-25. :-) > > Also, I don't think using $2a$ for openbsd blowfish is a good idea - use > > $2$ directly since it's what they use. Ther is no need to be different for > > the sake of it. > > Are you sure? from lib/libc/crypt/bcrypt.c No, sorry. :-) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 10:13:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (unknown [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6B98B14C2F for ; Tue, 6 Jul 1999 10:13:47 -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.8.8/8.8.8) with SMTP id LAA20810; Tue, 6 Jul 1999 11:13:35 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA14163; Tue, 6 Jul 1999 11:13:33 -0600 Date: Tue, 6 Jul 1999 11:13:33 -0600 Message-Id: <199907061713.LAA14163@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Watson Cc: Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: References: <199907011413.AAA02422@cheops.anu.edu.au> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ Intrusion detection ] > The problem with KTRACE is that it doesn't have a concept of discrete > syscalls, it's really more of a log of events, and various kernel calls > (such as namei) create log entries once in a while, which just happen to > be in a useful order. Which happen to be in a useful order in a UP kernel. On an SMP kernel all bets are off, and a solution that doesn't work on SMP (or works because of quirks in the current SMP implementation) aren't acceptable IMO. > We'd like to modify it to generate transactions of > a sort that are discrete packages of entries in a well-defined and useful > order, which can then be converted to POSIX.1e-style records for use in > userland. Agreed. However, all ideas that I have come up with (so far) involve more changes to the kernel sources than I'm comfortable with, so I'm trying to think of a new strategy that doesn't require large-scale changes to the entire kernel. If we have too many changes, the chance of rejection by the kernel gurus are high, and I don't have the time or desire to spend months/years going through an iterative process to make them palatable, all the while hand-maintaining them while the kernel goes through revolutionary changes for SMP support that I forsee are going to occur. > My hope is to put a lot of this code online when I return from the UK in > early August. I haven't made any forward progress in the KTRACE changes > and my code largely relies on the hackish hooks in syscalls to gather > data. These are the 'easy' way to do things, and *may* be the only sane way to do things. However, it requires alot of work for anyone modifying the kernel to keep things straight (this isn't overly bad), but it requires anyone adding a new syscall to add this in, and this 'requirement' may not be followed. It would be nicer if this could somehow be 'automated' like it is in KTRACE currently, but I haven't thought of a good way (yet). Nate ps. How's Cambridge? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 10:17:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 12FCB14BD7 for ; Tue, 6 Jul 1999 10:17:24 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id KAA05144; Tue, 6 Jul 1999 10:17:01 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 6 Jul 1999 10:17:00 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Paulo Fragoso Cc: freebsd-security@freebsd.org Subject: Re: IMAP or QPOPPER 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, 5 Jul 1999, Paulo Fragoso wrote: > Hi, > > I'm thiking put IMAP4 server and its ipop3d in my mail server. Are there > any security problems with imap-4.5? I've used qpopper since the begin and > I would like to listen some opinions about IMAP :-) You might want to check out the bugtraq archives at http://www.securityfocus.com/ on IMAP problems and make sure that you are properly secured. I've run IMAP for over a year and never had a problem with it, but I do have it heavily firewalled. I get on average two unauthorized connections to that port a week, but they don't get anywhere thanks to ipfw. Good luck, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 10:36:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id A545914F68 for ; Tue, 6 Jul 1999 10:36:13 -0700 (PDT) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.8.8) id NAA19710 for freebsd-security@freebsd.org; Tue, 6 Jul 1999 13:37:37 -0400 (EDT) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199907061737.NAA19710@cc942873-a.ewndsr1.nj.home.com> Subject: Failed FTP Attempts To: freebsd-security@freebsd.org Date: Tue, 6 Jul 1999 13:37:37 -0400 (EDT) Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL40 (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 Hmmm... noticed these in my logs: Jul 6 10:05:37 cc942873-a ftpd[19216]: connection from lon-c45-001-vty4.as.wcom.net (195.232.2.4) Jul 6 10:05:37 cc942873-a ftpd[19216]: ANONYMOUS FTP LOGIN REFUSED FROM lon-c45-001-vty4.as.wcom.net Jul 6 10:05:37 cc942873-a ftpd[19216]: FTP LOGIN FAILED FROM lon-c45-001-vty4.as.wcom.net, mp3 Jul 6 10:05:38 cc942873-a ftpd[19216]: FTP LOGIN FAILED FROM lon-c45-001-vty4.as.wcom.net, warez Jul 6 10:05:40 cc942873-a ftpd[19216]: FTP LOGIN FAILED FROM lon-c45-001-vty4.as.wcom.net, leech My first guess is a mistaken identity; our friend in search of warez typed in a bad IP addy or something. Anyone see something there more sinister? I have no idea why people would be looking me up for ftp'ing warez and mp3s. BTW, I turned off my ftpd in inetd.conf after noticing this. I have not used ftp in ages now that I have managed to install ssh on 90% of the machines I use (the miracle of scp). -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 10:50:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from trooper.velocet.ca (trooper.velocet.net [209.167.225.226]) by hub.freebsd.org (Postfix) with ESMTP id 3C88C14D33 for ; Tue, 6 Jul 1999 10:50:40 -0700 (PDT) (envelope-from dgilbert@trooper.velocet.ca) Received: (from dgilbert@localhost) by trooper.velocet.ca (8.8.7/8.8.7) id NAA09797; Tue, 6 Jul 1999 13:50:36 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14210.16875.956392.173972@trooper.velocet.ca> Date: Tue, 6 Jul 1999 13:50:35 -0400 (EDT) To: Robert Watson Cc: "Vladimir Mencl, MK, susSED" , security@FreeBSD.ORG Subject: Re: X security (was Re: X and SSH) In-Reply-To: References: X-Mailer: VM 6.71 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Robert" == Robert Watson writes: Robert> On Sat, 26 Jun 1999, Vladimir Mencl, MK, susSED wrote: >> On Sat, 26 Jun 1999, Robert Watson wrote: >> >> ... >> >> > > I personally like to run incoming tunneled X sessions from >> under-trusted > hosts in Xnest, but maybe that's just me... :-) >> >> Does it give more security? Robert> I have not inspected Xnest source, so it might be worth doing Robert> sometime. My suspicion is it actually renders the virtual Robert> display as a bitmap. Probably a better alternative would be Robert> to write an X proxy that speaks the X protocol and prevents Robert> unfortunate things from happening (grabs, xinput capture, Robert> etc?), perhaps one that spoke to a window manager with Robert> security extensions to allow you to take advantage of Robert> knowledge of window behavior. You might be better off starting with the dxpc source, then, as that code is already optimized to do just that. The X proxy in ssh also does some xauth translation (where the X proxy in dxpc just transfers it as given) Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 10:58:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id A69DA14FA0 for ; Tue, 6 Jul 1999 10:58:15 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 3A9CE78; Wed, 7 Jul 1999 01:58:14 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Kris Kennaway Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-reply-to: Your message of "Tue, 06 Jul 1999 23:26:28 +0930." Date: Wed, 07 Jul 1999 01:58:14 +0800 From: Peter Wemm Message-Id: <19990706175814.3A9CE78@overcee.netplex.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > On Tue, 6 Jul 1999, Peter Wemm wrote: > > > I'd strongly suggest encoding the number of rounds as well, ie: > > $token$salt$rounds$password > > For the two algorithms which currently support variable rounds, it's > already encoded into the password: > > $Blowfish$xy$ following the OpenBSD format (xy = log2 rounds) , > and > > _ for New-DES. ( encoded as a base-64 binary > value). Say... you wouldn't like to impliment an NT-style password hash, would you? *NOT* the LAN-Manager (LAN-damager?) hash with the 2 chunks of 7 characters weak method that gets decoded in what seems like seconds according to bugtraq. The NT hash is 128 character etc. It's also unicode and not case sensitive, but that shouldn't be a problem to implement. The reason I ask is that there are a number of protocols that have this embedded in it, including PPP's MS-CHAP and SMB. Samba has to have a seperate password file with NT-style password hashes to authenticate with Win98 clients etc. There's a few examples of this hash method in the source tree, both ppp's have it for starters. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 11: 8:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id AF86514F52 for ; Tue, 6 Jul 1999 11:08:22 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id UAA06433; Tue, 6 Jul 1999 20:07:21 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907061807.UAA06433@gratis.grondar.za> To: Kris Kennaway Cc: security@FreeBSD.ORG Subject: Re: Improved libcrypt ready for testing Date: Tue, 06 Jul 1999 20:07:20 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I've just finished polishing off a replacement crypt library, based on > some earlier work by Brandon Gillespie, which provides the following > features: > > * Support for MD5, SHA-1, DES (two forms), and Blowfish password > (a la OpenBSD) > > * Password crypt format defined by login capabilities Cool! I'm back from overseas now, and I'd like to review this, please. Thanks for the hard work! :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 16:35:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id BACA214CFF for ; Tue, 6 Jul 1999 16:35:20 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id JAA13886; Wed, 7 Jul 1999 09:05:17 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA22206; Wed, 7 Jul 1999 09:05:16 +0930 Date: Wed, 7 Jul 1999 09:05:16 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Mark Murray Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <199907061807.UAA06433@gratis.grondar.za> 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, 6 Jul 1999, Mark Murray wrote: > Cool! > > I'm back from overseas now, and I'd like to review this, please. Please do! Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 16:38:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 19CAE14CFF for ; Tue, 6 Jul 1999 16:38:38 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id JAA13978; Wed, 7 Jul 1999 09:08:33 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA02105; Wed, 7 Jul 1999 09:08:33 +0930 Date: Wed, 7 Jul 1999 09:08:32 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Peter Wemm Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <19990706175814.3A9CE78@overcee.netplex.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 On Wed, 7 Jul 1999, Peter Wemm wrote: > Say... you wouldn't like to impliment an NT-style password hash, would you? > *NOT* the LAN-Manager (LAN-damager?) hash with the 2 chunks of 7 characters > weak method that gets decoded in what seems like seconds according to > bugtraq. The NT hash is 128 character etc. It's also unicode and not case > sensitive, but that shouldn't be a problem to implement. This is worth looking at. Do the password hashes have any distinguishing characteristics other than being 128 characters long? I'm wondering how they'd be distinguished in the password file, unless we add a $NT$ prefix. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 18:37:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from phoenix (phoenix.aye.net [206.185.8.134]) by hub.freebsd.org (Postfix) with SMTP id C6D4C1537A for ; Tue, 6 Jul 1999 18:36:59 -0700 (PDT) (envelope-from barrett@phoenix.aye.net) Received: (qmail 9112 invoked by uid 1000); 7 Jul 1999 01:34:10 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Jul 1999 01:34:10 -0000 Date: Tue, 6 Jul 1999 21:34:10 -0400 (EDT) From: Barrett Richardson To: cjclark@home.com Cc: freebsd-security@freebsd.org Subject: Re: Failed FTP Attempts In-Reply-To: <199907061737.NAA19710@cc942873-a.ewndsr1.nj.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 6 Jul 1999, Crist J. Clark wrote: > Hmmm... noticed these in my logs: > > Jul 6 10:05:37 cc942873-a ftpd[19216]: connection from lon-c45-001-vty4.as.wcom.net (195.232.2.4) > Jul 6 10:05:37 cc942873-a ftpd[19216]: ANONYMOUS FTP LOGIN REFUSED FROM lon-c45-001-vty4.as.wcom.net > Jul 6 10:05:37 cc942873-a ftpd[19216]: FTP LOGIN FAILED FROM lon-c45-001-vty4.as.wcom.net, mp3 > Jul 6 10:05:38 cc942873-a ftpd[19216]: FTP LOGIN FAILED FROM lon-c45-001-vty4.as.wcom.net, warez > Jul 6 10:05:40 cc942873-a ftpd[19216]: FTP LOGIN FAILED FROM lon-c45-001-vty4.as.wcom.net, leech > I've seen attempted logins for warez and leech on my machine also. A guess is that these are accounts typically set up by script kiddies that have been able to add accounts on systems. They must use those account names to store and trade their pirated goodies. - Barrett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 6 23:33: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id B9DB414A09 for ; Tue, 6 Jul 1999 23:32:41 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id IAA10374; Wed, 7 Jul 1999 08:32:10 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907070632.IAA10374@gratis.grondar.za> To: Kris Kennaway Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing Date: Wed, 07 Jul 1999 08:32:08 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Tue, 6 Jul 1999, Mark Murray wrote: > > > Cool! > > > > I'm back from overseas now, and I'd like to review this, please. > > Please do! Erm, please post again where you have this; I seem to have deleted that mail :-( M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 0:35:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from drago.cert.org.tw (drago.cert.org.tw [140.117.100.10]) by hub.freebsd.org (Postfix) with ESMTP id F402514CA8 for ; Wed, 7 Jul 1999 00:35:19 -0700 (PDT) (envelope-from foxfair@drago.cert.org.tw) Received: from foxfair (foxfair.cc.nsysu.edu.tw [140.117.100.101]) by drago.cert.org.tw (8.9.3/8.9.3) with SMTP id PAA47084 for ; Wed, 7 Jul 1999 15:36:10 +0800 (CST) Date: Wed, 07 Jul 1999 15:35:31 +0800 From: Foxfair Hu To: freebsd-security@FreeBSD.org Subject: Fw: PGP 6.5.1 has been released Message-Id: <378303431AE.37A6FOXFAIR@drago.cert.org.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.25.04 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just FYI. ---------------- Original message follows ---------------- From: Cody Brownstein To: BUGTRAQ@SECURITYFOCUS.COM Date: Tue, 6 Jul 1999 18:21:39 -0700 Subject: PGP 6.5.1 has been released -- NEW FEATURES IN 6.5.1 PGPnet. PGPnet is a landmark product in the history of PGP. PGPnet secures all TCP/IP communications between itself and any other machine running PGPnet. PGPnet has been successfully tested with Cisco routers(requires Cisco IOS 12.0(4) or later with IPSec TripleDES), Linux FreeS/WAN, and many others. Self-Decrypting Archives. You may now encrypt files or folders into Self-Decrypting Archives (SDA) which can be used by users who do not even have PGP. The archives are completely independent of any application, compressed and protected by PGP's strong cryptography. Integrated PGP Command Line. This version incorporates the popular command line version of PGP for Windows platforms. This product provides you a convenient way to integrate PGP with other Windows applications and automated processes on your desktop system. Please note that this is intended for single user/workstation use. For use on servers, customers are required to purchase the PGP Command Line/Batch Server product. Please contact your local Network Associates Sales representative for more information. Automated Freespace Wiping. PGP's Freespace Wipe feature now allows you to use the Windows Task Scheduler to schedule periodic secure wiping of the freespace on your disk. Hotkeys. The Use Current Window feature has been significantly enhanced by the addition of Hotkeys. By pressing the configured key combination, the Encrypt/Decrypt/Sign functions can be automatically invoked in zero clicks without using PGPtray. Fingerprint Word List. When verifying a PGP public key fingerprint, you can now choose to view the fingerprint as a word list instead of hexadecimal characters. The word list in the fingerprint text box is made up of special authentication words that PGP uses and are carefully selected to be phonetically distinct and easy to understand without phonetic ambiguity. Support for Outlook 2000 and Outlook Express 5.0. This version of PGP adds support for sending and receiving encrypted e-mail in Microsoft Outlook 2000 and Outlook Express 5.0. HTTP Proxy Support. If you are behind a corporate firewall with an HTTP proxy server, PGP now supports accessing HTTP keyservers through the proxy. To use this feature, you must configure the proxy server address in your Internet Explorer preferences. Smart Word Wrapping. The word wrapping in PGP now automatically rewraps paragraphs and even quoted paragraphs resulting in much cleaner signed messages. ----- Cody Brownstein ----- PGP Fingerprint: 291B 5051 B97F 8B30 49F8 A068 15CF 26D6 E4DE 5291 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 4:14:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 1546E14EBB for ; Wed, 7 Jul 1999 04:14:14 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id MAA67638; Wed, 7 Jul 1999 12:14:08 +0100 (BST) (envelope-from joe) Date: Wed, 7 Jul 1999 12:14:08 +0100 From: Josef Karthauser To: "Stephen D. Spencer" Cc: freebsd-security@FreeBSD.ORG Subject: Re: your mail Message-ID: <19990707121408.H30024@pavilion.net> References: <19990702111953.Z69050@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Stephen D. Spencer on Mon, Jul 05, 1999 at 11:36:41AM -0500 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jul 05, 1999 at 11:36:41AM -0500, Stephen D. Spencer wrote: > On Fri, 2 Jul 1999, Josef Karthauser wrote: > > > On Fri, Jul 02, 1999 at 03:10:47AM -0700, Cliff Skolnick wrote: > > > > > > Add permanent, static arp entries for all your legit mac/ip combos, then > > > [...] > > > > That's the cookie. Thanks :) > > > > Or a simpler method might be to simply statically add his mac to your ARP > table with a non-routable IP address. Had to do this on a Cisco. Rather > simple and is quite amusing to observe customer reactions. :) > That doesn't work! One mac can have multiple IP addresses. All this does is to stop anyone else using the unroutable ip address. Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 4:41:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 41BF114DE2 for ; Wed, 7 Jul 1999 04:41:09 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 58E8E78; Wed, 7 Jul 1999 19:41:08 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Kris Kennaway Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-reply-to: Your message of "Wed, 07 Jul 1999 09:08:32 +0930." Date: Wed, 07 Jul 1999 19:41:08 +0800 From: Peter Wemm Message-Id: <19990707114108.58E8E78@overcee.netplex.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > On Wed, 7 Jul 1999, Peter Wemm wrote: > > > Say... you wouldn't like to impliment an NT-style password hash, would you? > > *NOT* the LAN-Manager (LAN-damager?) hash with the 2 chunks of 7 characters > > weak method that gets decoded in what seems like seconds according to > > bugtraq. The NT hash is 128 character etc. It's also unicode and not case > > sensitive, but that shouldn't be a problem to implement. > > This is worth looking at. Do the password hashes have any distinguishing > characteristics other than being 128 characters long? I'm wondering how > they'd be distinguished in the password file, unless we add a $NT$ prefix. > > Kris Looking at /usr/local/private/smbpasswd, samba's NT-style shadow password file: logname:2004:260AAF5FD661391EAAD3B345B51404EE:E9402F112D1BEC4978F943B55C11EB46: Gecos Username:/home/logname:/usr/local/bin/tcsh So, I guess this would do: $NT$260AAF5FD661391EAAD3B345B51404EE$E9402F112D1BEC4978F943B55C11EB46 (This is a real line with the names and hash sufficiently corrupted so nobody gets ideas about trying to crack it. :-) Also, we really do need some way to implement plugins that works on both static and dynamic binaries. I would suggest that for dynamic binaries, libcrypt would be compiled (ie: #ifdef PIC) to dlopen() the .so files based on a config file. For static libcrypt, it would have to fork and pipe the string to a static helper binary that returns the hash from the string. That way /sbin/init will be able to verify any method for root password when in non-secure console mode. I would suggest a /etc/crypt.conf or something that contains the prefix and both a static and dynamic plugin. ie: NT /usr/lib/pwhash_nt.so /sbin/_pwhash_nt 1 /usr/lib/pwhash_md5.so /sbin/_pwhash_md5 2 /usr/lib/pwhash_bfish.so /sbin/_pwhash_bfish default /usr/lib/pwhash_des.so /sbin/_pwhash_des Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 5:33:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id C8FAB1537A for ; Wed, 7 Jul 1999 05:33:10 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id WAA29578; Wed, 7 Jul 1999 22:03:09 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA30295; Wed, 7 Jul 1999 22:03:01 +0930 Date: Wed, 7 Jul 1999 22:02:56 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Peter Wemm Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <19990707114108.58E8E78@overcee.netplex.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 On Wed, 7 Jul 1999, Peter Wemm wrote: > > This is worth looking at. Do the password hashes have any distinguishing > > characteristics other than being 128 characters long? I'm wondering how > > they'd be distinguished in the password file, unless we add a $NT$ prefix. > Looking at /usr/local/private/smbpasswd, samba's NT-style shadow > password file: > > logname:2004:260AAF5FD661391EAAD3B345B51404EE:E9402F112D1BEC4978F943B55C11EB46: > Gecos Username:/home/logname:/usr/local/bin/tcsh The first of those hashes is the LanManager hash, which we do not want to include(that's the case-insensitive one which is trivially easy to break). Because they're hashes of the same plaintext, if you break the LM hash you get the upcased version of the password which you can then permute. > Also, we really do need some way to implement plugins that works on both > static and dynamic binaries. I would suggest that for dynamic binaries, > libcrypt would be compiled (ie: #ifdef PIC) to dlopen() the .so files > based on a config file. For static libcrypt, it would have to fork and pipe > the string to a static helper binary that returns the hash from the string. > That way /sbin/init will be able to verify any method for root password when > in non-secure console mode. > > I would suggest a /etc/crypt.conf or something that contains the prefix > and both a static and dynamic plugin. Hmm. This does sound like a good idea - it's much like the PAM system. The new libcrypt code is already very modular internally, so making it pluggable is the logical next step. Having the name token user-specified solves the problem of a third-party module treading on another module's name, at the cost of some extra configuration and non-portability if you want to migrate your passwords to a system which uses the colliding module. The solution I thought up was to have the name token as well as a random magic number (internal to the module and included as an extra field in the password) to statistically protect against collision. So you'd have $name$magic$rounds$salt$hash as your password format Kris > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 5:57:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from unix2.it-datacntr.louisville.edu (unix2.it-datacntr.louisville.edu [136.165.4.28]) by hub.freebsd.org (Postfix) with ESMTP id 4F45C14D79 for ; Wed, 7 Jul 1999 05:57:42 -0700 (PDT) (envelope-from k.stevenson@louisville.edu) Received: from homer.louisville.edu (ktstev01@homer.louisville.edu [136.165.1.20]) by unix2.it-datacntr.louisville.edu (8.8.8/8.8.8) with ESMTP id IAA49040 for ; Wed, 7 Jul 1999 08:57:01 -0400 Received: (from ktstev01@localhost) by homer.louisville.edu (8.8.8/8.8.8) id IAA17398 for freebsd-security@freebsd.org; Wed, 7 Jul 1999 08:57:41 -0400 (EDT) Message-ID: <19990707085741.A17255@homer.louisville.edu> Date: Wed, 7 Jul 1999 08:57:41 -0400 From: Keith Stevenson To: freebsd-security@freebsd.org Subject: Re: Improved libcrypt ready for testing References: <19990707114108.58E8E78@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Kris Kennaway on Wed, Jul 07, 1999 at 10:02:56PM +0930 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jul 07, 1999 at 10:02:56PM +0930, Kris Kennaway wrote: > On Wed, 7 Jul 1999, Peter Wemm wrote: > > > > > I would suggest a /etc/crypt.conf or something that contains the prefix > > and both a static and dynamic plugin. > > Hmm. This does sound like a good idea - it's much like the PAM system. The new > libcrypt code is already very modular internally, so making it pluggable is > the logical next step. Actually, you may want to have a chat with Mark Murray before implementing a new security-related config file. I think that he plans to restart PAM development soon, and this sounds like something that he might be interested in. 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 Jul 7 7:38: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from firewall.f5.com (f5.com [207.17.117.200]) by hub.freebsd.org (Postfix) with ESMTP id E54BA14C99 for ; Wed, 7 Jul 1999 07:37:57 -0700 (PDT) (envelope-from m.barthelow@f5.com) Received: by firewall.f5.com; id HAA27872; Wed, 7 Jul 1999 07:05:08 GMT Received: from klar.f5.com(192.50.100.9) by firewall.f5.com via smap (4.1) id xma027824; Wed, 7 Jul 99 07:04:23 GMT Received: from f5-exchange.win.net by klar.f5.com; (8.8.7/1.1.8.2/18Jul96-1139AM) id GAA11850; Wed, 7 Jul 1999 06:39:16 -0700 Received: by f5-exchange.win.net with Internet Mail Service (5.5.2448.0) id <3NMJ5HXT>; Wed, 7 Jul 1999 07:36:45 -0700 Message-ID: <111627409F79D2119FB100A0C9EEDC3E2E41DB@f5-exchange.win.net> From: Michael Barthelow To: "'Foxfair Hu'" , freebsd-security@FreeBSD.ORG Subject: RE: PGP 6.5.1 has been released Date: Wed, 7 Jul 1999 07:36:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEC886.22A00EF0" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEC886.22A00EF0 Content-Type: text/plain; charset="iso-8859-1" Thanks for the info. When I go to the MIT site and try to download, I get a message saying: 550 failed to get admin key Has anyone successfully downloaded the new software? thx, mb -----Original Message----- From: Foxfair Hu [mailto:foxfair@drago.cert.org.tw] Sent: Wednesday, July 07, 1999 8:36 AM To: freebsd-security@FreeBSD.ORG Subject: Fw: PGP 6.5.1 has been released Just FYI. ---------------- Original message follows ---------------- From: Cody Brownstein To: BUGTRAQ@SECURITYFOCUS.COM Date: Tue, 6 Jul 1999 18:21:39 -0700 Subject: PGP 6.5.1 has been released -- NEW FEATURES IN 6.5.1 PGPnet. PGPnet is a landmark product in the history of PGP. PGPnet secures all TCP/IP communications between itself and any other machine running PGPnet. PGPnet has been successfully tested with Cisco routers(requires Cisco IOS 12.0(4) or later with IPSec TripleDES), Linux FreeS/WAN, and many others. Self-Decrypting Archives. You may now encrypt files or folders into Self-Decrypting Archives (SDA) which can be used by users who do not even have PGP. The archives are completely independent of any application, compressed and protected by PGP's strong cryptography. Integrated PGP Command Line. This version incorporates the popular command line version of PGP for Windows platforms. This product provides you a convenient way to integrate PGP with other Windows applications and automated processes on your desktop system. Please note that this is intended for single user/workstation use. For use on servers, customers are required to purchase the PGP Command Line/Batch Server product. Please contact your local Network Associates Sales representative for more information. Automated Freespace Wiping. PGP's Freespace Wipe feature now allows you to use the Windows Task Scheduler to schedule periodic secure wiping of the freespace on your disk. Hotkeys. The Use Current Window feature has been significantly enhanced by the addition of Hotkeys. By pressing the configured key combination, the Encrypt/Decrypt/Sign functions can be automatically invoked in zero clicks without using PGPtray. Fingerprint Word List. When verifying a PGP public key fingerprint, you can now choose to view the fingerprint as a word list instead of hexadecimal characters. The word list in the fingerprint text box is made up of special authentication words that PGP uses and are carefully selected to be phonetically distinct and easy to understand without phonetic ambiguity. Support for Outlook 2000 and Outlook Express 5.0. This version of PGP adds support for sending and receiving encrypted e-mail in Microsoft Outlook 2000 and Outlook Express 5.0. HTTP Proxy Support. If you are behind a corporate firewall with an HTTP proxy server, PGP now supports accessing HTTP keyservers through the proxy. To use this feature, you must configure the proxy server address in your Internet Explorer preferences. Smart Word Wrapping. The word wrapping in PGP now automatically rewraps paragraphs and even quoted paragraphs resulting in much cleaner signed messages. ----- Cody Brownstein ----- PGP Fingerprint: 291B 5051 B97F 8B30 49F8 A068 15CF 26D6 E4DE 5291 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message ------_=_NextPart_001_01BEC886.22A00EF0 Content-Type: text/html; charset="iso-8859-1" RE: PGP 6.5.1 has been released

Thanks for the info. When I go to the MIT site and try to download, I get a message saying:

550 failed to get admin key

Has anyone successfully downloaded the new software?

thx,

mb

-----Original Message-----
From: Foxfair Hu [mailto:foxfair@drago.cert.org.tw]
Sent: Wednesday, July 07, 1999 8:36 AM
To: freebsd-security@FreeBSD.ORG
Subject: Fw: PGP 6.5.1 has been released




  Just FYI.
 
---------------- Original message follows ----------------
 From: Cody Brownstein <cbrownst@MEDIAONE.NET>
 To: BUGTRAQ@SECURITYFOCUS.COM
 Date: Tue, 6 Jul 1999 18:21:39 -0700
 Subject: PGP 6.5.1 has been released
--

<http://web.mit.edu/network/pgp.html>

NEW FEATURES IN 6.5.1

PGPnet. PGPnet is a landmark product in the history of PGP. PGPnet secures
all TCP/IP communications between itself and any other machine running
PGPnet. PGPnet has been successfully tested with Cisco routers(requires
Cisco IOS 12.0(4) or later with IPSec TripleDES), Linux FreeS/WAN, and many
others.

Self-Decrypting Archives. You may now encrypt files or folders into
Self-Decrypting Archives (SDA) which can be used by users who do not even
have PGP. The archives are completely independent of any application,
compressed and protected by PGP's strong cryptography.

Integrated PGP Command Line. This version incorporates the popular command
line version of PGP for Windows platforms. This product provides you a
convenient way to integrate PGP with other Windows applications and
automated processes on your desktop system. Please note that this is
intended for single user/workstation use. For use on servers, customers are
required to purchase the PGP Command Line/Batch Server product. Please
contact your local Network Associates Sales representative for more
information.

Automated Freespace Wiping. PGP's Freespace Wipe feature now allows you to
use the Windows Task Scheduler to schedule periodic secure wiping of the
freespace on your disk.

Hotkeys. The Use Current Window feature has been significantly enhanced by
the addition of Hotkeys. By pressing the configured key combination, the
Encrypt/Decrypt/Sign functions can be automatically invoked in zero clicks
without using PGPtray.

Fingerprint Word List. When verifying a PGP public key fingerprint, you can
now choose to view the fingerprint as a word list instead of hexadecimal
characters. The word list in the fingerprint text box is made up of special
authentication words that PGP uses and are carefully selected to be
phonetically distinct and easy to understand without phonetic ambiguity.

Support for Outlook 2000 and Outlook Express 5.0. This version of PGP adds
support for sending and receiving encrypted e-mail in Microsoft Outlook 2000
and Outlook Express 5.0.

HTTP Proxy Support. If you are behind a corporate firewall with an HTTP
proxy server, PGP now supports accessing HTTP keyservers through the proxy.
To use this feature, you must configure the proxy server address in your
Internet Explorer preferences.

Smart Word Wrapping. The word wrapping in PGP now automatically rewraps
paragraphs and even quoted paragraphs resulting in much cleaner signed
messages.


-----
Cody Brownstein
<cbrownst@mediaone.net>
-----

PGP Fingerprint:
291B 5051 B97F 8B30 49F8  A068 15CF 26D6 E4DE 5291



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

------_=_NextPart_001_01BEC886.22A00EF0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 7:47:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from vital.bleeding.com (vital.bleeding.com [206.251.12.170]) by hub.freebsd.org (Postfix) with ESMTP id 7BF5F14C99 for ; Wed, 7 Jul 1999 07:47:22 -0700 (PDT) (envelope-from jjwolf@bleeding.com) Received: from crimson (crimson [144.254.195.6]) by vital.bleeding.com (8.9.2/8.9.2) with SMTP id HAA54483; Wed, 7 Jul 1999 07:47:14 -0700 (PDT) (envelope-from jjwolf@bleeding.com) From: "Justin Wolf" To: "Josef Karthauser" , "Stephen D. Spencer" Cc: Subject: RE: your mail Date: Wed, 7 Jul 1999 07:24:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <19990707121408.H30024@pavilion.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Or a simpler method might be to simply statically add his mac to your ARP >> table with a non-routable IP address. Had to do this on a Cisco. Rather >> simple and is quite amusing to observe customer reactions. :) > That doesn't work! One mac can have multiple IP addresses. All this does > is to stop anyone else using the unroutable ip address. Well any IP address outside of their subnet would essentially be unroutable. If you're not using RFC1918 space anywhere, set it to 10.0.0.1 or something - this is generally ignored by other networks' border routers (such as the ISP). You still need to be able to deny an ARP lookup for that MAC that would allow it to resolve to another IP. Is there no provision in routed or ipfw to filter by MAC address? -Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 8:21:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 17C1614D85 for ; Wed, 7 Jul 1999 08:21:17 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id RAA02064; Wed, 7 Jul 1999 17:21:16 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA44576; Wed, 7 Jul 1999 17:21:16 +0200 (MET DST) Date: Wed, 7 Jul 1999 17:21:15 +0200 From: Eivind Eklund To: Peter Wemm Cc: Kris Kennaway , security@FreeBSD.ORG Subject: Re: Improved libcrypt ready for testing Message-ID: <19990707172115.D44021@bitbox.follo.net> References: <19990706175814.3A9CE78@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990706175814.3A9CE78@overcee.netplex.com.au>; from Peter Wemm on Wed, Jul 07, 1999 at 01:58:14AM +0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jul 07, 1999 at 01:58:14AM +0800, Peter Wemm wrote: > Kris Kennaway wrote: > > On Tue, 6 Jul 1999, Peter Wemm wrote: > > > > > I'd strongly suggest encoding the number of rounds as well, ie: > > > $token$salt$rounds$password > > > > For the two algorithms which currently support variable rounds, it's > > already encoded into the password: > > > > $Blowfish$xy$ following the OpenBSD format (xy = log2 rounds) > , > > and > > > > _ for New-DES. ( encoded as a base-64 binary > > value). > > Say... you wouldn't like to impliment an NT-style password hash, would you? > *NOT* the LAN-Manager (LAN-damager?) hash with the 2 chunks of 7 characters > weak method that gets decoded in what seems like seconds according to > bugtraq. The NT hash is 128 character etc. It's also unicode and not case > sensitive, but that shouldn't be a problem to implement. > > The reason I ask is that there are a number of protocols that have this > embedded in it, including PPP's MS-CHAP and SMB. If we want to support protocol-embedded authentication data properly, we need at least the ability to store several different types of hashes for each user in the password file, and the ability to store clear-text passwords. We should also, IMO, be switching our default password file format to SRP or similar - something that allow challenges against it without being the cleartext. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 12:49:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id AD90E15027 for ; Wed, 7 Jul 1999 12:49:39 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id VAA21415; Wed, 7 Jul 1999 21:48:59 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907071948.VAA21415@gratis.grondar.za> To: Keith Stevenson Cc: freebsd-security@FreeBSD.ORG Subject: Re: Improved libcrypt ready for testing Date: Wed, 07 Jul 1999 21:48:58 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > libcrypt code is already very modular internally, so making it pluggable is > > the logical next step. > > Actually, you may want to have a chat with Mark Murray before implementing a > new security-related config file. I think that he plans to restart PAM > development soon, and this sounds like something that he might be interested > in. Absolutely. JDP is going to give me his PAM bits this weekend, and I'll be Full Steam Ahead with them. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 12:53:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id DF5C714C17 for ; Wed, 7 Jul 1999 12:53:10 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id VAA21393; Wed, 7 Jul 1999 21:47:24 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907071947.VAA21393@gratis.grondar.za> To: Kris Kennaway Cc: Peter Wemm , security@FreeBSD.ORG Subject: Re: Improved libcrypt ready for testing Date: Wed, 07 Jul 1999 21:47:22 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > This is worth looking at. Do the password hashes have any distinguishing > characteristics other than being 128 characters long? I'm wondering how they'd > be distinguished in the password file, unless we add a $NT$ prefix. So far, these long(er) hashes crash perl :-(. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 17: 5:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id D7E17154D2; Wed, 7 Jul 1999 17:05:34 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id JAA24352; Thu, 8 Jul 1999 09:35:33 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA10637; Thu, 8 Jul 1999 09:35:29 +0930 Date: Thu, 8 Jul 1999 09:35:29 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Eivind Eklund Cc: Peter Wemm , security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <19990707172115.D44021@bitbox.follo.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 Wed, 7 Jul 1999, Eivind Eklund wrote: > If we want to support protocol-embedded authentication data properly, > we need at least the ability to store several different types of > hashes for each user in the password file, and the ability to store > clear-text passwords. Storing cleartext passwords is easy enough - just define a minimal hash function which base64's the plaintext, and null salt function. I'll have to think about how multiple password hashes could best be implemented - any suggestions? > We should also, IMO, be switching our default password file format to > SRP or similar - something that allow challenges against it without > being the cleartext. I have the SRP reference implementation working at home - it requires changes to clients, though. This would probably best be integrated with a PAM module talking to the crypt backend (such a beast exists already, but I haven't tested it). Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 17: 6:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id B491614FAC for ; Wed, 7 Jul 1999 17:06:51 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id JAA24192; Thu, 8 Jul 1999 09:36:49 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA03479; Thu, 8 Jul 1999 09:36:42 +0930 Date: Thu, 8 Jul 1999 09:36:42 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Mark Murray Cc: Keith Stevenson , freebsd-security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <199907071948.VAA21415@gratis.grondar.za> 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, 7 Jul 1999, Mark Murray wrote: > > Actually, you may want to have a chat with Mark Murray before implementing a > > new security-related config file. I think that he plans to restart PAM > > development soon, and this sounds like something that he might be interested > > in. > > Absolutely. JDP is going to give me his PAM bits this weekend, and I'll be > Full Steam Ahead with them. Cool! There's a lot which could be done with our PAM implementation (for one, upgrading to the most recent version :-) Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jul 7 18:50:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 1D56D14EF1 for ; Wed, 7 Jul 1999 18:50:29 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id LAA25451; Thu, 8 Jul 1999 11:20:16 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA14646; Thu, 8 Jul 1999 11:19:56 +0930 Date: Thu, 8 Jul 1999 11:19:56 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Ladavac Marino Cc: "'Josef Karthauser'" , Brian Somers , Mark Thomas , freebsd-security@freebsd.org, Wayne Self Subject: Credential storage (was RE: userland ppp - startup) In-Reply-To: <55586E7391ACD211B9730000C11002761796DA@r-lmh-wi-100.corpnet.at> 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, 7 Jul 1999, Ladavac Marino wrote: > > Hmm... how to do this then? The sppp setup code in rc.* allows > > username/password > > to be specified. Can it be done in the environment then? (If rc.conf > > is visable > > then the sppp config gives usernames and passwords away as it stands > > today.) > [ML] Don't know about sppp, but the only halfway secure way to > keep this sensitive data is in a file readable by root, and having the > program which needs it setuid root. Sounds a lot like > /etc/ppp/ppp.conf, doesn't it? > > The secure way would be not keeping the info at all :) You know, I wonder if it's time to look at providing a generic credential storage registry; things like password hashes, PPP shared secrets, etc, could be stored here instead of in lots of separate files. So user account passwords could point to a SHA-1 hash in the registry, ppp shared secrets would point to an NT and/or LM hash, samba accounts could have an associated NT/LM hash, etc. More than one hash could be associated with any given entity. The modules which manipulate individual credentials (hashes) would be pluggable along the lines of PAM. What do people think - is this worth pursuing? Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 1:24:26 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 B336E14F34 for ; Thu, 8 Jul 1999 01:24:13 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id EAA17396; Thu, 8 Jul 1999 04:23:29 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 8 Jul 1999 04:23:29 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Kris Kennaway Cc: Ladavac Marino , "'Josef Karthauser'" , Brian Somers , Mark Thomas , freebsd-security@freebsd.org, Wayne Self Subject: Re: Credential storage (was RE: userland ppp - startup) 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, 8 Jul 1999, Kris Kennaway wrote: > You know, I wonder if it's time to look at providing a generic > credential storage registry; things like password hashes, PPP shared > secrets, etc, could be stored here instead of in lots of separate files. > > So user account passwords could point to a SHA-1 hash in the registry, > ppp shared secrets would point to an NT and/or LM hash, samba accounts > could have an associated NT/LM hash, etc. More than one hash could be > associated with any given entity. > > The modules which manipulate individual credentials (hashes) would be > pluggable along the lines of PAM. > > What do people think - is this worth pursuing? It is worth pursuing, but my feeling is that we should wait until IPSEC is integrated so we have some idea of the key management requirements there. I'm also tempted to say that this should not be just a system credential management, but part of a general key-management toolkit and authentication package, but that's fairly heavy-weight, and still a topic of open research. :-) The problem is of course that you need to express policies concerning key strength, provide key management functionality, and support more than just hashes and passwords: ideally also public/private key -- perhaps as a back end to sshd. Which brings up certificate management, ... My feeling is we should let all this stuff settle and work with an interim temporary solution without exerting too much effort. 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, Computing Laboratory at Cambridge University 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 Jul 8 1:26:50 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 4E86A14E8D for ; Thu, 8 Jul 1999 01:26:43 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id EAA17415; Thu, 8 Jul 1999 04:26:26 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 8 Jul 1999 04:26:26 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Mark Murray Cc: freebsd-security@freebsd.org Subject: kerberos version In-Reply-To: <199907071948.VAA21415@gratis.grondar.za> 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 Mark, I bring this up occasionally, and for this nagging I apologize, but I was wondering if you had any version/time estimates for new versions of kerberos being dropped into FreeBSD? Arla requires a newer version of KTH KerberosIV than we currently having, making integration of Arla difficult. And of course, there is strong interesting in KerberosV... 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, Computing Laboratory at Cambridge University 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 Jul 8 2:14:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C7A9F14DB0 for ; Thu, 8 Jul 1999 02:14:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id LAA16754; Thu, 8 Jul 1999 11:14:31 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA49653; Thu, 8 Jul 1999 11:14:30 +0200 (MET DST) Date: Thu, 8 Jul 1999 11:14:30 +0200 From: Eivind Eklund To: Kris Kennaway Cc: Peter Wemm , security@freebsd.org Subject: Re: Improved libcrypt ready for testing Message-ID: <19990708111429.E46370@bitbox.follo.net> References: <19990707172115.D44021@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Kris Kennaway on Thu, Jul 08, 1999 at 09:35:29AM +0930 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jul 08, 1999 at 09:35:29AM +0930, Kris Kennaway wrote: > On Wed, 7 Jul 1999, Eivind Eklund wrote: > > > If we want to support protocol-embedded authentication data properly, > > we need at least the ability to store several different types of > > hashes for each user in the password file, and the ability to store > > clear-text passwords. > > Storing cleartext passwords is easy enough - just define a minimal hash > function which base64's the plaintext, and null salt function. > > I'll have to think about how multiple password hashes could best be > implemented - any suggestions? For the master password file itself, I guess we could just put several hashes in the password field, separated by commas (which I don't think are allowed in any of the present hashes). I don't know how to fit multiple hashes into the databases; I've not looked too carefully at these. > > > We should also, IMO, be switching our default password file format to > > SRP or similar - something that allow challenges against it without > > being the cleartext. > > I have the SRP reference implementation working at home - it requires changes > to clients, though. Does it require changes to clients in order to be used as a normal password hash, not to do challenges against? I can't remember anything about it that would force that? Just using it as a hash format in our password file would give the userbase time to transition, and would poise us perfectly for further use. > This would probably best be integrated with a PAM module talking to > the crypt backend (such a beast exists already, but I haven't tested > it). It would be very, very nice if we were able to support it :) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 2:30:40 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 7C16A14DB0 for ; Thu, 8 Jul 1999 02:30:35 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id FAA17665; Thu, 8 Jul 1999 05:30:22 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 8 Jul 1999 05:30:21 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Nate Williams Cc: Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: <199907061713.LAA14163@mt.sri.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 Tue, 6 Jul 1999, Nate Williams wrote: > [ Intrusion detection ] > > > The problem with KTRACE is that it doesn't have a concept of discrete > > syscalls, it's really more of a log of events, and various kernel calls > > (such as namei) create log entries once in a while, which just happen to > > be in a useful order. > > Which happen to be in a useful order in a UP kernel. On an SMP kernel > all bets are off, and a solution that doesn't work on SMP (or works > because of quirks in the current SMP implementation) aren't acceptable > IMO. My feeling is that perhaps KTRACE should be initially modified so that records for a particular context (that is, when entering kernel mode, a particular syscall) should be buffered in some way associated with the context, and then "commit" could be called in the syscall return (or signal return, etc), resulting in the records being flushed to the KTRACE management routines. This would have the effect of gathering related records. We could then work from there to structure the gathering procedure or tag entries in some useful way. > > We'd like to modify it to generate transactions of > > a sort that are discrete packages of entries in a well-defined and useful > > order, which can then be converted to POSIX.1e-style records for use in > > userland. > > Agreed. However, all ideas that I have come up with (so far) involve > more changes to the kernel sources than I'm comfortable with, so I'm > trying to think of a new strategy that doesn't require large-scale > changes to the entire kernel. If we have too many changes, the chance > of rejection by the kernel gurus are high, and I don't have the time or > desire to spend months/years going through an iterative process to > make them palatable, all the while hand-maintaining them while the > kernel goes through revolutionary changes for SMP support that I forsee > are going to occur. This sounds good to me :-). > > My hope is to put a lot of this code online when I return from the UK in > > early August. I haven't made any forward progress in the KTRACE changes > > and my code largely relies on the hackish hooks in syscalls to gather > > data. > > These are the 'easy' way to do things, and *may* be the only sane way to > do things. However, it requires alot of work for anyone modifying the > kernel to keep things straight (this isn't overly bad), but it requires > anyone adding a new syscall to add this in, and this 'requirement' may > not be followed. It would be nicer if this could somehow be 'automated' > like it is in KTRACE currently, but I haven't thought of a good way > (yet). As I pointed out in a prior email, one immediate problem is that namei submits the KTRACE entry for pathname arguments that undergo name lookups. As a result, my syscall patches end up copying in the argument a second time. This is clearly a problem if shared memory is allows between contexts, as there are race conditions. Similarly, it's also fairly inefficient. It's not clear to me what the best solution is: we could either move the copyin out of namei and submit the path via an argument, or we could provide an argument to namei that allows it to tag its KTRACE submission appropriately. It seems to me that initially two changes, then, are necessary: modifying KTRACE to submit in bundles of records associated with individual events, and modifying KTRACE to allow tagging of submitted entries as particular components of an event. We can then propagate the changes up so that the various locations submitting KTRACE entries tag the entries correctly. > ps. How's Cambridge? Going well. I've been here for a few days now, and am helping to set up their tamper-resistant hardware lab. I'm in the process of learning some new machine languages for some embedded chips. I'll then code some crypto algorithms for the chips and we'll start doing power analysis on the chips during various instructions and see if we can pull data out of the chips based on the power consumption. I don't have much experience with hardware security, so I'm learning a lot. I'm not sure how much they're getting out of this, but it's fun. Should keep me busy for a couple of weeks while I'm here. 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, Computing Laboratory at Cambridge University 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 Jul 8 3:32:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.226]) by hub.freebsd.org (Postfix) with SMTP id 1F89714D14 for ; Thu, 8 Jul 1999 03:32:08 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id GAA06331; Thu, 8 Jul 1999 06:31:54 -0400 From: "Allen Smith" Message-Id: <9907080631.ZM6329@beatrice.rutgers.edu> Date: Thu, 8 Jul 1999 06:31:54 -0400 In-Reply-To: Richard Steenbergen "SYN Floods, some food for thought" (Jun 19, 9:19pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Richard Steenbergen , freebsd-security@freebsd.org Subject: Re: SYN Floods, some food for thought Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jun 19, 9:19pm, Richard Steenbergen (possibly) wrote: > using my flooder and the most optimal techniques I could come up with > (including asm checksum :P) I was about to generate approx 15kpps (a 4.6x I don't suppose you might send this in as a pr for in_cksum.c? Thanks, -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 6:44: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id A0B6314BF5; Thu, 8 Jul 1999 06:44:02 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id XAA29920; Thu, 8 Jul 1999 23:13:57 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA11568; Thu, 8 Jul 1999 23:13:54 +0930 Date: Thu, 8 Jul 1999 23:13:53 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Eivind Eklund Cc: Peter Wemm , security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <19990708111429.E46370@bitbox.follo.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 Thu, 8 Jul 1999, Eivind Eklund wrote: > > I'll have to think about how multiple password hashes could best be > > implemented - any suggestions? > > For the master password file itself, I guess we could just put several > hashes in the password field, separated by commas (which I don't think > are allowed in any of the present hashes). I don't know how to fit > multiple hashes into the databases; I've not looked too carefully at > these. The issue becomes how you retrieve or query the existence of a particular password hash. getpwent() should only return the first hash listed because most consumers will just do a strcmp(crypt(),passwd.pw_passwd) to veryify a password. There should be an interface for testing the existence of a password hash of a certain kind and retrieving it. I'll think about how to implement this... > > I have the SRP reference implementation working at home - it requires changes > > to clients, though. > > Does it require changes to clients in order to be used as a normal > password hash, not to do challenges against? I can't remember > anything about it that would force that? SRP stores a salt and "verifier" (essentially just the hash of the password taken as an exponent of a large integer modulo another large integer) As an interim measure, this could be used as just another hash algorithm like any other which is queried by cleartext passwords, but obviously you wouldn't want to be querying some services using SRP and others using the plaintext of the same password. I should have time this weekend to knock this up together with some of the changes discussed so far in this thread. The simplest way to SRP-ify an application is probably to make both client and server talk PAM and use the pam_srp module (which I haven't checked out yet). Kris > > Eivind. > ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 8:46:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from puffer.quadrunner.com (puffer.quadrunner.com [205.166.195.4]) by hub.freebsd.org (Postfix) with ESMTP id 2C24D154B6 for ; Thu, 8 Jul 1999 08:46:10 -0700 (PDT) (envelope-from humble@quadrunner.com) Received: from localhost (humble@localhost) by puffer.quadrunner.com (8.9.2/QUAD-2.1) with ESMTP id IAA32744; Thu, 8 Jul 1999 08:46:09 -0700 (PDT) X-Authentication-Warning: puffer.quadrunner.com: humble owned process doing -bs Date: Thu, 8 Jul 1999 08:46:09 -0700 (PDT) From: Richard Steenbergen To: Allen Smith Cc: freebsd-security@freebsd.org Subject: Re: SYN Floods, some food for thought In-Reply-To: <9907080631.ZM6329@beatrice.rutgers.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 Thu, 8 Jul 1999, Allen Smith wrote: > On Jun 19, 9:19pm, Richard Steenbergen (possibly) wrote: > > > using my flooder and the most optimal techniques I could come up with > > (including asm checksum :P) I was about to generate approx 15kpps (a 4.6x > > I don't suppose you might send this in as a pr for in_cksum.c? Such already exists, as in_cksum.c in the hardware specific junk (such as /usr/src/sys/i386/i386/in_cksum.c). A more useful feature might be a socket which you can bind to a specific interface and then be able to send raw frames (or whatever the data link layer method might be) without the overhead of raw_output, ip_output, routing table lokups, etc. -- Richard Steenbergen humble@EFNet PGP ID: 0x741D0374 PGP Key Fingerprint: C6EF EFA0 83B2 071F 1AB6 B879 1F70 4303 741D 0374 http://users.quadrunner.com/humble To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 8:46:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 69921154F5 for ; Thu, 8 Jul 1999 08:46:31 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id RAA11136; Thu, 8 Jul 1999 17:46:31 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA51572; Thu, 8 Jul 1999 17:46:23 +0200 (MET DST) Date: Thu, 8 Jul 1999 17:46:23 +0200 From: Eivind Eklund To: Kris Kennaway Cc: Peter Wemm , security@freebsd.org Subject: Re: Improved libcrypt ready for testing Message-ID: <19990708174622.B50609@bitbox.follo.net> References: <19990708111429.E46370@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Kris Kennaway on Thu, Jul 08, 1999 at 11:13:53PM +0930 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jul 08, 1999 at 11:13:53PM +0930, Kris Kennaway wrote: > On Thu, 8 Jul 1999, Eivind Eklund wrote: > > Kris Kennaway wrote: > > > I have the SRP reference implementation working at home - it > > > requires changes to clients, though. > > > > Does it require changes to clients in order to be used as a normal > > password hash, not to do challenges against? I can't remember > > anything about it that would force that? > > SRP stores a salt and "verifier" (essentially just the hash of the password > taken as an exponent of a large integer modulo another large integer) > > As an interim measure, this could be used as just another hash > algorithm like any other which is queried by cleartext passwords, > but obviously you wouldn't want to be querying some services using > SRP and others using the plaintext of the same password. I disagree. In my opinion, you would obviously want to - to give a simple example, I'm willing to type my plaintext password at a login prompt, but I'm not willing to transfer it in the clear using POP3. > I should have time this weekend to knock this up together with some > of the changes discussed so far in this thread. > > The simplest way to SRP-ify an application is probably to make both > client and server talk PAM and use the pam_srp module (which I > haven't checked out yet). This is the next step after actually having the SRP password hashes in the database in the first place :) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 8:59:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 8CA01154AA; Thu, 8 Jul 1999 08:59:15 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id BAA31302; Fri, 9 Jul 1999 01:29:11 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA32198; Fri, 9 Jul 1999 01:29:10 +0930 Date: Fri, 9 Jul 1999 01:29:10 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Eivind Eklund Cc: Peter Wemm , security@freebsd.org Subject: Re: Improved libcrypt ready for testing In-Reply-To: <19990708174622.B50609@bitbox.follo.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 Thu, 8 Jul 1999, Eivind Eklund wrote: > > As an interim measure, this could be used as just another hash > > algorithm like any other which is queried by cleartext passwords, > > but obviously you wouldn't want to be querying some services using > > SRP and others using the plaintext of the same password. > > I disagree. In my opinion, you would obviously want to - to give a > simple example, I'm willing to type my plaintext password at a login > prompt, but I'm not willing to transfer it in the clear using POP3. I was referring to the case of having two remote services, one of which is accessed using the plaintext password using the SRP hash as a traditional password hash on the server (e.g., a non-SRP'ified POP3 client), and one which has a SRP-speaking client and uses the full SRP protocol, but the same password (e.g SRP'ified telnet). SRP only has benefits if you use it exclusively for a given account over the network. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 9:45:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (unknown [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 513F414E1B for ; Thu, 8 Jul 1999 09:45:44 -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.8.8/8.8.8) with SMTP id KAA24591; Thu, 8 Jul 1999 10:45:31 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA29163; Thu, 8 Jul 1999 10:45:25 -0600 Date: Thu, 8 Jul 1999 10:45:25 -0600 Message-Id: <199907081645.KAA29163@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Watson Cc: Nate Williams , Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: References: <199907061713.LAA14163@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > [ Intrusion detection ] > > > > > The problem with KTRACE is that it doesn't have a concept of discrete > > > syscalls, it's really more of a log of events, and various kernel calls > > > (such as namei) create log entries once in a while, which just happen to > > > be in a useful order. > > > > Which happen to be in a useful order in a UP kernel. On an SMP kernel > > all bets are off, and a solution that doesn't work on SMP (or works > > because of quirks in the current SMP implementation) aren't acceptable > > IMO. > > My feeling is that perhaps KTRACE should be initially modified so that > records for a particular context (that is, when entering kernel mode, a > particular syscall) should be buffered in some way associated with the > context, and then "commit" could be called in the syscall return (or > signal return, etc), resulting in the records being flushed to the KTRACE > management routines. There are other issues with the KTRACE facility that have come up. Most notably, for IDS systems, you need a *LOT* more information than KTRACE provides. For example, in the exec() syscall, not only do you want the argument of the file you are exec'ing, you also want the file permissions, size, ownership, gid of the user, mount flags of the FS (it may be NO_EXEC of NO_SUID) so you can do proper detection. None of this information is provided via KTRACE, and according to our IDS expert, it's necessary to do proper detection. > > > We'd like to modify it to generate transactions of > > > a sort that are discrete packages of entries in a well-defined and useful > > > order, which can then be converted to POSIX.1e-style records for use in > > > userland. > > > > Agreed. However, all ideas that I have come up with (so far) involve > > more changes to the kernel sources than I'm comfortable with, so I'm > > trying to think of a new strategy that doesn't require large-scale > > changes to the entire kernel. If we have too many changes, the chance > > of rejection by the kernel gurus are high, and I don't have the time or > > desire to spend months/years going through an iterative process to > > make them palatable, all the while hand-maintaining them while the > > kernel goes through revolutionary changes for SMP support that I forsee > > are going to occur. > > This sounds good to me :-). I'm of the opinion that to make truly useful IDS records, we're going to have to make some significant changes to the FreeBSD kernel. Note, these changes are only going to affect folks who ask for kernel auditing (not KTRACE), but because of the type and quantity of information desired in IDS systems, it will cause a performance hit in those systems that desire it. > > > My hope is to put a lot of this code online when I return from the UK in > > > early August. I haven't made any forward progress in the KTRACE changes > > > and my code largely relies on the hackish hooks in syscalls to gather > > > data. > > > > These are the 'easy' way to do things, and *may* be the only sane way to > > do things. However, it requires alot of work for anyone modifying the > > kernel to keep things straight (this isn't overly bad), but it requires > > anyone adding a new syscall to add this in, and this 'requirement' may > > not be followed. It would be nicer if this could somehow be 'automated' > > like it is in KTRACE currently, but I haven't thought of a good way > > (yet). > > As I pointed out in a prior email, one immediate problem is that namei > submits the KTRACE entry for pathname arguments that undergo name lookups. > As a result, my syscall patches end up copying in the argument a second > time. This is clearly a problem if shared memory is allows between > contexts, as there are race conditions. Similarly, it's also fairly > inefficient. It's not clear to me what the best solution is: we could > either move the copyin out of namei and submit the path via an argument, > or we could provide an argument to namei that allows it to tag its KTRACE > submission appropriately. I'm beginning to think that using KTRACE is not an acceptable way of doing things, and that we need to re-instrument the kernel with IDS auditing on it's own. In other words, your current strategy of instrumenting individual syscalls is the 'correct' approach, although it leaves the potential for modifying large portions of the system and the possibility that as new syscall are added they will not be instrumented correctly, or at all. Unfortunately, I don't see any way around this if we want useful IDS records. I also don't know how well the FreeBSD kernel guys are going to take having almost every kernel source file modified in an attempt to 'slow down' the system to get IDS information. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 9:46:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from mercurio.nar.ufv.br (mercurio.nar.ufv.br [200.18.130.84]) by hub.freebsd.org (Postfix) with SMTP id 61465154E7 for ; Thu, 8 Jul 1999 09:45:39 -0700 (PDT) (envelope-from kernel@tdnet.com.br) Received: (qmail 394 invoked from network); 8 Jul 1999 16:39:29 -0000 Received: from mercurio.nar.ufv.br (HELO tdnet.com.br) (200.18.130.84) by mercurio.nar.ufv.br with SMTP; 8 Jul 1999 16:39:29 -0000 Message-ID: <3784D440.1075EFB3@tdnet.com.br> Date: Thu, 08 Jul 1999 13:39:28 -0300 From: Gustavo V G C Rios X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: security@freebsd.org, bos-owner-br@sekure.org Subject: suid/guid Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Which of the following file should i turn off suid/guid bit flag? I just wanna keep the necessary file tunr on suid/guid! My system is freebsd-3.2Stable Here goes them: /proc/2965/file /bin/df /bin/ps /bin/rcp /sbin/ccdconfig /sbin/dmesg /sbin/dump /sbin/rdump /sbin/ping /sbin/restore /sbin/rrestore /sbin/route /sbin/shutdown /usr/bin/cu /usr/bin/uucp /usr/bin/uuname /usr/bin/uustat /usr/bin/uux /usr/bin/man /usr/bin/suidperl /usr/bin/sperl5.00503 /usr/bin/at /usr/bin/atq /usr/bin/atrm /usr/bin/batch /usr/bin/chpass /usr/bin/chfn /usr/bin/chsh /usr/bin/ypchpass /usr/bin/ypchfn /usr/bin/ypchsh /usr/bin/fstat /usr/bin/ipcs /usr/bin/keyinfo /usr/bin/keyinit /usr/bin/lock /usr/bin/login /usr/bin/netstat /usr/bin/nfsstat /usr/bin/passwd /usr/bin/yppasswd /usr/bin/quota /usr/bin/rlogin /usr/bin/rsh /usr/bin/su /usr/bin/systat /usr/bin/top /usr/bin/vmstat /usr/bin/w /usr/bin/uptime /usr/bin/wall /usr/bin/write /usr/bin/crontab /usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/bin/newaliases /usr/bin/mailq /usr/bin/hoststat /usr/libexec/uucp/uucico /usr/libexec/uucp/uuxqt /usr/libexec/mail.local /usr/local/bin/screen-3.7.6 /usr/local/bin/skill /usr/local/bin/snice /usr/local/bin/icmpinfo /usr/local/sbin/queso /usr/sbin/lpc /usr/sbin/iostat /usr/sbin/mrinfo /usr/sbin/mtrace /usr/sbin/pstat /usr/sbin/swapinfo /usr/sbin/sliplogin /usr/sbin/timedc /usr/sbin/traceroute /usr/sbin/trpt /usr/sbin/sendmail /usr/sbin/purgestat /usr/sbin/ppp /usr/sbin/pppd /usr/games/dm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 9:50:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 386F514FA6 for ; Thu, 8 Jul 1999 09:50:26 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id RAA88186; Thu, 8 Jul 1999 17:50:15 +0100 (BST) (envelope-from joe) Date: Thu, 8 Jul 1999 17:50:15 +0100 From: Josef Karthauser To: Gustavo V G C Rios Cc: security@FreeBSD.ORG, bos-owner-br@sekure.org Subject: Re: suid/guid Message-ID: <19990708175015.C50525@pavilion.net> References: <3784D440.1075EFB3@tdnet.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <3784D440.1075EFB3@tdnet.com.br>; from Gustavo V G C Rios on Thu, Jul 08, 1999 at 01:39:28PM -0300 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Turn them all off and see what happens :) Joe On Thu, Jul 08, 1999 at 01:39:28PM -0300, Gustavo V G C Rios wrote: > Which of the following file should i turn off suid/guid bit flag? > I just wanna keep the necessary file tunr on suid/guid! > > My system is freebsd-3.2Stable > > Here goes them: > > /proc/2965/file > /bin/df > /bin/ps > /bin/rcp > /sbin/ccdconfig > /sbin/dmesg > /sbin/dump > /sbin/rdump > /sbin/ping > /sbin/restore > /sbin/rrestore > /sbin/route > /sbin/shutdown > /usr/bin/cu > /usr/bin/uucp > /usr/bin/uuname > /usr/bin/uustat > /usr/bin/uux > /usr/bin/man > /usr/bin/suidperl > /usr/bin/sperl5.00503 > /usr/bin/at > /usr/bin/atq > /usr/bin/atrm > /usr/bin/batch > /usr/bin/chpass > /usr/bin/chfn > /usr/bin/chsh > /usr/bin/ypchpass > /usr/bin/ypchfn > /usr/bin/ypchsh > /usr/bin/fstat > /usr/bin/ipcs > /usr/bin/keyinfo > /usr/bin/keyinit > /usr/bin/lock > /usr/bin/login > /usr/bin/netstat > /usr/bin/nfsstat > /usr/bin/passwd > /usr/bin/yppasswd > /usr/bin/quota > /usr/bin/rlogin > /usr/bin/rsh > /usr/bin/su > /usr/bin/systat > /usr/bin/top > /usr/bin/vmstat > /usr/bin/w > /usr/bin/uptime > /usr/bin/wall > /usr/bin/write > /usr/bin/crontab > /usr/bin/lpq > /usr/bin/lpr > /usr/bin/lprm > /usr/bin/newaliases > /usr/bin/mailq > /usr/bin/hoststat > /usr/libexec/uucp/uucico > /usr/libexec/uucp/uuxqt > /usr/libexec/mail.local > /usr/local/bin/screen-3.7.6 > /usr/local/bin/skill > /usr/local/bin/snice > /usr/local/bin/icmpinfo > /usr/local/sbin/queso > /usr/sbin/lpc > /usr/sbin/iostat > /usr/sbin/mrinfo > /usr/sbin/mtrace > /usr/sbin/pstat > /usr/sbin/swapinfo > /usr/sbin/sliplogin > /usr/sbin/timedc > /usr/sbin/traceroute > /usr/sbin/trpt > /usr/sbin/sendmail > /usr/sbin/purgestat > /usr/sbin/ppp > /usr/sbin/pppd > /usr/games/dm > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 9:51: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from entic.net (shell.entic.net [209.157.122.66]) by hub.freebsd.org (Postfix) with SMTP id 07E371518D for ; Thu, 8 Jul 1999 09:51:03 -0700 (PDT) (envelope-from aj@entic.net) Received: (qmail 28788 invoked by uid 1000); 8 Jul 1999 16:51:27 -0000 Date: Thu, 8 Jul 1999 09:51:27 -0700 (PDT) From: Anil Jangity To: Gustavo V G C Rios Cc: security@freebsd.org, bos-owner-br@sekure.org Subject: Re: suid/guid In-Reply-To: <3784D440.1075EFB3@tdnet.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 |Which of the following file should i turn off suid/guid bit flag? |I just wanna keep the necessary file tunr on suid/guid! | |My system is freebsd-3.2Stable | |Here goes them: | |/proc/2965/file |/bin/df It depends on what you are using and what you are not. If you are not going to be using a file that has suid/guid then remove that flag. If you don't know what one of those bin's do, just do man and see if you need it or not. Good luck. Kind regards, Anil Jangity aj@entic.net Network Operations/Web Development http://www.entic.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 9:57:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from mercurio.nar.ufv.br (mercurio.nar.ufv.br [200.18.130.84]) by hub.freebsd.org (Postfix) with SMTP id 47CA414BF2 for ; Thu, 8 Jul 1999 09:57:15 -0700 (PDT) (envelope-from kernel@tdnet.com.br) Received: (qmail 414 invoked from network); 8 Jul 1999 16:51:11 -0000 Received: from mercurio.nar.ufv.br (HELO tdnet.com.br) (200.18.130.84) by mercurio.nar.ufv.br with SMTP; 8 Jul 1999 16:51:11 -0000 Message-ID: <3784D6FF.3CCAFEA0@tdnet.com.br> Date: Thu, 08 Jul 1999 13:51:11 -0300 From: Gustavo V G C Rios X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Anil Jangity Cc: security@freebsd.org, bos-owner-br@sekure.org Subject: Re: suid/guid References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anil Jangity wrote: > > |Which of the following file should i turn off suid/guid bit flag? > |I just wanna keep the necessary file tunr on suid/guid! > | > |My system is freebsd-3.2Stable > | > |Here goes them: > | > |/proc/2965/file > |/bin/df > > It depends on what you are using and what you are not. If you are not > going to be using a file that has suid/guid then remove that flag. > > If you don't know what one of those bin's do, just do man and see if > you need it or not. > > Good luck. > > Kind regards, > > Anil Jangity > > aj@entic.net > Network Operations/Web Development > http://www.entic.net Than a lot, but i am using this machine as a shell account server, so probably i only need passwd, cron*, and ... (which more?). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 10:14:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 0AEE514C02 for ; Thu, 8 Jul 1999 10:14:24 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id SAA93170; Thu, 8 Jul 1999 18:14:17 +0100 (BST) (envelope-from joe) Date: Thu, 8 Jul 1999 18:14:17 +0100 From: Josef Karthauser To: Gustavo V G C Rios Cc: security@freebsd.org Subject: Re: suid/guid Message-ID: <19990708181416.D50525@pavilion.net> References: <3784D440.1075EFB3@tdnet.com.br> <19990708175015.C50525@pavilion.net> <3784D697.63C8FD3E@tdnet.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <3784D697.63C8FD3E@tdnet.com.br>; from Gustavo V G C Rios on Thu, Jul 08, 1999 at 01:49:27PM -0300 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jul 08, 1999 at 01:49:27PM -0300, Gustavo V G C Rios wrote: > Josef Karthauser wrote: > > > > Turn them all off and see what happens :) > > > > Joe > > thanks, good solution, but not pratical. > This is a shell account server, so i believe i only need passwd,cron*, > and .... > Is there any other necessary file? Ah! There's are others out there better positioned to answer that one. None of my customers have shell access at all :) :) Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 10:53:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from bachue.usc.unal.edu.co (bachue.usc.unal.edu.co [168.176.3.20]) by hub.freebsd.org (Postfix) with ESMTP id C592C14F1E for ; Thu, 8 Jul 1999 10:53:05 -0700 (PDT) (envelope-from pfgiffun@bachue.usc.unal.edu.co) Received: from bachue.usc.unal.edu.co ([168.176.3.32]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.6) with ESMTP id AAA2E44 for ; Thu, 8 Jul 1999 12:50:51 -0400 Message-ID: <3784E58C.3A0CA882@bachue.usc.unal.edu.co> Date: Thu, 08 Jul 1999 12:53:16 -0500 From: "Pedro F. Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: it,es-CO MIME-Version: 1.0 To: freebsd-security@FreeBSD.org Subject: Dante: a free socks implementation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have been very busy lately, and I understand if no one has time to look into this, but if someone needs socks, take a look at: http://www.inet.no/dante/ cheers, Pedro. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 11: 0:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 52B09155F8 for ; Thu, 8 Jul 1999 11:00:00 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id TAA01212; Thu, 8 Jul 1999 19:59:04 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907081759.TAA01212@gratis.grondar.za> To: Robert Watson Cc: freebsd-security@freebsd.org Subject: Re: kerberos version Date: Thu, 08 Jul 1999 19:59:03 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I bring this up occasionally, and for this nagging I apologize, but I was > wondering if you had any version/time estimates for new versions of > kerberos being dropped into FreeBSD? Arla requires a newer version of KTH > KerberosIV than we currently having, making integration of Arla difficult. > And of course, there is strong interesting in KerberosV... No problem. I'll give it a push and see if I can get it done in a week or three. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 13:35:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from shift-f1.com (unknown [208.152.204.161]) by hub.freebsd.org (Postfix) with ESMTP id 3885914FF9 for ; Thu, 8 Jul 1999 13:35:29 -0700 (PDT) (envelope-from shashi@shift-f1.com) Received: (from shashi) by shift-f1.com (8.8.5/8.8.5) id PAA02409; Thu, 8 Jul 1999 15:30:01 -0500 (EST) Message-ID: <19990708163001.A2364@Shift-F1.com> Date: Thu, 8 Jul 1999 16:30:01 -0400 From: System Admin To: Richard Steenbergen , Allen Smith Cc: freebsd-security@freebsd.org Subject: Mailing List Problems? Multiple copies! References: <9907080631.ZM6329@beatrice.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Richard Steenbergen on Thu, Jul 08, 1999 at 08:46:09AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does any one know why I have been getting 9 copies of EVERY MAIL FROM FREEBSD? Shashi Richard Steenbergen worked magic with the keyboard on Thu, Jul 08, 1999 at 08:46:09AM -0700: > On Thu, 8 Jul 1999, Allen Smith wrote: > > > On Jun 19, 9:19pm, Richard Steenbergen (possibly) wrote: > > > > > using my flooder and the most optimal techniques I could come up with > > > (including asm checksum :P) I was about to generate approx 15kpps (a 4.6x > > > > I don't suppose you might send this in as a pr for in_cksum.c? > > Such already exists, as in_cksum.c in the hardware specific junk (such as > /usr/src/sys/i386/i386/in_cksum.c). A more useful feature might be a > socket which you can bind to a specific interface and then be able to send > raw frames (or whatever the data link layer method might be) without the > overhead of raw_output, ip_output, routing table lokups, etc. > > -- > Richard Steenbergen humble@EFNet PGP ID: 0x741D0374 > PGP Key Fingerprint: C6EF EFA0 83B2 071F 1AB6 B879 1F70 4303 741D 0374 > http://users.quadrunner.com/humble > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message <-------------- End of Included Original Message ------> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 13:36:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 845AF151B9 for ; Thu, 8 Jul 1999 13:36:49 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id NAA71228; Thu, 8 Jul 1999 13:36:43 -0700 (PDT) From: Archie Cobbs Message-Id: <199907082036.NAA71228@bubba.whistle.com> Subject: Re: SYN Floods, some food for thought In-Reply-To: from Richard Steenbergen at "Jul 8, 99 08:46:09 am" To: humble@quadrunner.com (Richard Steenbergen) Date: Thu, 8 Jul 1999 13:36:43 -0700 (PDT) Cc: easmith@beatrice.rutgers.edu, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Richard Steenbergen writes: > A more useful feature might be a > socket which you can bind to a specific interface and then be able to send > raw frames (or whatever the data link layer method might be) without the > overhead of raw_output, ip_output, routing table lokups, etc. Doing this is easy with netgraph-enabled Ethernet interfaces... ftp://ftp.whistle.com/pub/archie/netgraph/index.html -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 17:41:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 1D56F14E67 for ; Thu, 8 Jul 1999 17:41:39 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id KAA01941; Fri, 9 Jul 1999 10:11:37 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA06610; Fri, 9 Jul 1999 10:11:31 +0930 Date: Fri, 9 Jul 1999 10:11:28 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: "Pedro F. Giffuni" Cc: freebsd-security@freebsd.org Subject: Re: Dante: a free socks implementation In-Reply-To: <3784E58C.3A0CA882@bachue.usc.unal.edu.co> 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, 8 Jul 1999, Pedro F. Giffuni wrote: > I have been very busy lately, and I understand if no one has time to > look into this, but if someone needs socks, take a look at: > > http://www.inet.no/dante/ gethostbyname() proxy resolution doesn't work under FreeBSD (unless they fixed it recently). The service itself seems to work fine if you stick to IP addresses. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 22:52:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id B042A14D0C for ; Thu, 8 Jul 1999 22:52:21 -0700 (PDT) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (1681 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Fri, 9 Jul 1999 00:32:39 -0500 (CDT) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Fri, 9 Jul 1999 00:32:23 -0500 (CDT) From: James Wyatt To: Gustavo V G C Rios Cc: security@freebsd.org, bos-owner-br@sekure.org Subject: Re: suid/guid In-Reply-To: <3784D440.1075EFB3@tdnet.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 On Thu, 8 Jul 1999, Gustavo V G C Rios wrote: > Which of the following file should i turn off suid/guid bit flag? > I just wanna keep the necessary file tunr on suid/guid! > > My system is freebsd-3.2Stable > > Here goes them: > > /proc/2965/file I can't find this one on my system; is it still there on yours? 8{) > /bin/df > /bin/ps > /bin/rcp [ ... removed ... use 'find' for s/g-id executables ... ] Some of them are very important for all users (sendmail, passwd, ...) , many are useful to most users (chfn, man, ...), others you can 'chgrp' the s/g-id bits away if you run them only as root (at, shutdown, ping, ...). Some are infrequently used (ipcs, ccdconfig) or only on NIS-managed netdowns (yp*). If you want to learn more, try trolling man pages before trolling mailing lists: 8{P find / -type f \( -perm -4000 -o -perm -2000 \) -print | \ awk '{print"man `basename "$1"`"}' | more I learned almost from doing it as I did *reading* the c library function list. (echoes of "Wow, I didn't know there was a command/function to do *that*!"...) Hope this helps - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 8 23:49:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from buddy.sovlink.ru (buddy.sovlink.ru [194.186.12.9]) by hub.freebsd.org (Postfix) with ESMTP id AD8DE14CE9 for ; Thu, 8 Jul 1999 23:49:21 -0700 (PDT) (envelope-from alla@sovlink.ru) Received: from sovlink.ru (punk.sovlink.ru [194.186.12.133]) by buddy.sovlink.ru (8.9.1/8.9.1) with ESMTP id LAA03791 for ; Fri, 9 Jul 1999 11:00:46 +0400 (MSD) Message-ID: <37859B74.7528C158@sovlink.ru> Date: Fri, 09 Jul 1999 10:49:24 +0400 From: Alla Bezroutchko X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: FreeBSD Security Subject: Syslog alternatives? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is not exactly FreeBSD security question. More like general Unix security. Hope it is not completely off topic. I was looking at several syslogd alternatives (BTW, I don't think I have a complete list, can you suggest something?) and found out that I don't understand what is wrong with traditional syslogd from security standpoint. Could someone explain me or point me to some resources that explain why syslogd is bad? -- Alla Bezroutchko Sovlink LLC Systems Administrator Moscow, Russia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 0: 8:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 63CB914BDB for ; Fri, 9 Jul 1999 00:08:19 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id RAA16350; Fri, 9 Jul 1999 17:07:05 +1000 (EST) From: Darren Reed Message-Id: <199907090707.RAA16350@cheops.anu.edu.au> Subject: Re: Syslog alternatives? To: alla@sovlink.ru (Alla Bezroutchko) Date: Fri, 9 Jul 1999 17:07:04 +1000 (EST) Cc: security@FreeBSD.ORG In-Reply-To: <37859B74.7528C158@sovlink.ru> from "Alla Bezroutchko" at Jul 9, 99 10:49:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Alla Bezroutchko, sie said: > > This is not exactly FreeBSD security question. More like general > Unix security. Hope it is not completely off topic. > > I was looking at several syslogd alternatives (BTW, I don't think > I have a complete list, can you suggest something?) and found out > that I don't understand what is wrong with traditional syslogd from > security standpoint. > > Could someone explain me or point me to some resources that explain > why syslogd is bad? Prove to me that your log files have any integrity, in such a way that I cannot dispute it. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 0:49:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from mordor.xti.org (mordor.xti.org [193.212.232.254]) by hub.freebsd.org (Postfix) with SMTP id 2A95B14DA6 for ; Fri, 9 Jul 1999 00:49:55 -0700 (PDT) (envelope-from delta@xti.org) Received: (qmail 27406 invoked by alias); 9 Jul 1999 07:49:56 -0000 Received: from mordor.xti.org (193.212.232.254) by login.xti.org with SMTP; 9 Jul 1999 07:49:56 -0000 Date: Fri, 9 Jul 1999 09:49:56 +0200 (CEST) From: Terje Elde To: Darren Reed Cc: Alla Bezroutchko , security@FreeBSD.ORG Subject: Re: Syslog alternatives? In-Reply-To: <199907090707.RAA16350@cheops.anu.edu.au> Message-ID: Question: Do you know where *your* towel is? 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, 9 Jul 1999, Darren Reed wrote: >> Could someone explain me or point me to some resources that explain >> why syslogd is bad? > >Prove to me that your log files have any integrity, in such a way that >I cannot dispute it. This is esp fun when you do remote loggin and such. But now that we've establiseh what's wrong with the old one, anyone know of a new one which attempts to fix this issue somewhat? Friendly greetings, Terje Elde "One world, one web, one program" - Microsoft Promo ad. "Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 0:57:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from buddy.sovlink.ru (buddy.sovlink.ru [194.186.12.9]) by hub.freebsd.org (Postfix) with ESMTP id 94AEB14DA6 for ; Fri, 9 Jul 1999 00:57:36 -0700 (PDT) (envelope-from alla@sovlink.ru) Received: from sovlink.ru (punk.sovlink.ru [194.186.12.133]) by buddy.sovlink.ru (8.9.1/8.9.1) with ESMTP id MAA04288; Fri, 9 Jul 1999 12:08:37 +0400 (MSD) Message-ID: <3785AB58.2B3D8F05@sovlink.ru> Date: Fri, 09 Jul 1999 11:57:12 +0400 From: Alla Bezroutchko X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: Darren Reed Cc: security@FreeBSD.ORG Subject: Re: Syslog alternatives? References: <199907090707.RAA16350@cheops.anu.edu.au> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Darren Reed wrote: > In some mail from Alla Bezroutchko, sie said: > > Could someone explain me or point me to some resources that explain > > why syslogd is bad? > > Prove to me that your log files have any integrity, in such a way that > I cannot dispute it. How integrity is achieved with syslog's alternatives? Alla. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 1: 9:10 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 44BE614C19 for ; Fri, 9 Jul 1999 01:09:03 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id EAA24317; Fri, 9 Jul 1999 04:08:41 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 9 Jul 1999 04:08:41 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Nate Williams Cc: Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: <199907081645.KAA29163@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 8 Jul 1999, Nate Williams wrote: > > > [ Intrusion detection ] > > ... > > > > My feeling is that perhaps KTRACE should be initially modified so that > > records for a particular context (that is, when entering kernel mode, a > > particular syscall) should be buffered in some way associated with the > > context, and then "commit" could be called in the syscall return (or > > signal return, etc), resulting in the records being flushed to the KTRACE > > management routines. > > There are other issues with the KTRACE facility that have come up. Most > notably, for IDS systems, you need a *LOT* more information than KTRACE > provides. > > For example, in the exec() syscall, not only do you want the argument of > the file you are exec'ing, you also want the file permissions, size, > ownership, gid of the user, mount flags of the FS (it may be NO_EXEC of > NO_SUID) so you can do proper detection. None of this information is > provided via KTRACE, and according to our IDS expert, it's necessary to > do proper detection. This is certainly true--I believe KTRACE also does not provide the environmental variables, also desirable at exec-time. I suppose what we should really be doing, in line with what we've discussed thus far, as assembling an API for submitting IDS information. Hopefully one a little more general and cleaner than the hack I have been using. Something exposed enough in syscalls that it is clear to the casual syscall implementer how to apply it in their own code. Maybe something on the order of: #ifdef POSIX_AUD /* declare a record context */ audrec_t audrec; #endif ... #ifdef POSIX_AUD /* allocate the record */ if (!audrec = k_aud_new_record()) return(...appropriate error...) k_aud_settype(audrec, AUD_AEV_CHMOD); k_aud_setcred(audrec, p->p_cred); ... #endif The problem raised here again, of course, is the copyin of string arguments. Another problem is error-handling: at any possible exit point from the syscall, we need to commit an audit record describing the exit (in error, success, etc). This suggests instead making auditing to some extent implicit to the syscall: a record is created associated with the process structure (or thread or whatevr) when entering kernel mode, and committed when returning to userland (or explicitely committed if we are never going to return, i.e., the process called _exit). Kernel code in the syscall may optionally add additional information about the kernel entry point using a set of calls that automatically modify the implicit audit record state associated with the proc, meaning no need to allocate an audrec or pass it into all the routines, as it might be in p->p_curaudrec. #ifdef POSIX_AUD AUD_SET_SYSCALL(AUD_AEV_CHMOD); AUD_ADD_ARG(AUD_PATHNAME, ...); AUD_ADD_ARG(AUD_MODE, SC(args, mdoe)); ... #endif Information like credentials, pid, return code, syscall number would automatically be inserted when available by the syscall handler. Syscall number could be overriden by an explicit call. This still leaves us with dealing with the arguments, especially pathnames and arrays of strings (e.g., argv[] or env[]). > I'm of the opinion that to make truly useful IDS records, we're going to > have to make some significant changes to the FreeBSD kernel. Note, > these changes are only going to affect folks who ask for kernel auditing > (not KTRACE), but because of the type and quantity of information > desired in IDS systems, it will cause a performance hit in those systems > that desire it. The difference between "don't want any auditing" and "interested in auditing" is easily enough dealt with by #ifdef POSIX_AUD. The difference between "some auditing" and "all auditing" is more challenging: to what degree is filtering of records in the kernel appropriate, and to what degree should that be done by a userland audit daemon or audit record manager? A large volume stream of records in the kernel bloats the kernel and cuts into preemptible execution time. But adding too much filtering in kernel is costly also, and requires a lot more bloat in the kernel. POSIX.1E only defines a way to tell whether auditing is turned on or off for a specific process, and to toggle that (so that, for example, the audit daemon can turn off auditing so as to prevent feedback on audit record delivery). This seems to broad to me. Suppose active IDS modules only require fork(), exec() and exit() tracing--then delivering the 20,000 calls to gettimeofday() is a waste of resources. For my userland audit daemon, I currently have a simple propositional logic matching language, essentially providing boolean matching on record features (requiring certain named entries to exist, perhaps requiring certain things of their value) for the audit daemon to pass a record to a particular dynamically linked module. That seems like too much overhead to go in the kernel, perhaps, and also too late as a fairly large amount of the effort goes in to copying around strings and allocating space: once it's all been collected, you've expended the energy you hoped to save. > > > > My hope is to put a lot of this code online when I return from the UK in > > > > early August. I haven't made any forward progress in the KTRACE changes > > > > and my code largely relies on the hackish hooks in syscalls to gather > > > > data. > > > > > > These are the 'easy' way to do things, and *may* be the only sane way to > > > do things. However, it requires alot of work for anyone modifying the > > > kernel to keep things straight (this isn't overly bad), but it requires > > > anyone adding a new syscall to add this in, and this 'requirement' may > > > not be followed. It would be nicer if this could somehow be 'automated' > > > like it is in KTRACE currently, but I haven't thought of a good way > > > (yet). > > > > As I pointed out in a prior email, one immediate problem is that namei > > submits the KTRACE entry for pathname arguments that undergo name lookups. > > As a result, my syscall patches end up copying in the argument a second > > time. This is clearly a problem if shared memory is allows between > > contexts, as there are race conditions. Similarly, it's also fairly > > inefficient. It's not clear to me what the best solution is: we could > > either move the copyin out of namei and submit the path via an argument, > > or we could provide an argument to namei that allows it to tag its KTRACE > > submission appropriately. > > I'm beginning to think that using KTRACE is not an acceptable way of > doing things, and that we need to re-instrument the kernel with IDS > auditing on it's own. In other words, your current strategy of > instrumenting individual syscalls is the 'correct' approach, although it > leaves the potential for modifying large portions of the system and the > possibility that as new syscall are added they will not be instrumented > correctly, or at all. > > Unfortunately, I don't see any way around this if we want useful IDS > records. I also don't know how well the FreeBSD kernel guys are going > to take having almost every kernel source file modified in an attempt to > 'slow down' the system to get IDS information. :) My comments on all this are above--I had hoped KTRACE could ease introduction, but I'm concerned it cannot without significant overhead and modification. 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, Computing Laboratory at Cambridge University 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 Jul 9 1:20:32 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 1279415234 for ; Fri, 9 Jul 1999 01:20:28 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id EAA24352; Fri, 9 Jul 1999 04:20:13 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 9 Jul 1999 04:20:13 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Darren Reed Cc: Alla Bezroutchko , security@FreeBSD.ORG Subject: Re: Syslog alternatives? In-Reply-To: <199907090707.RAA16350@cheops.anu.edu.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 On Fri, 9 Jul 1999, Darren Reed wrote: > In some mail from Alla Bezroutchko, sie said: > > > > This is not exactly FreeBSD security question. More like general > > Unix security. Hope it is not completely off topic. > > > > I was looking at several syslogd alternatives (BTW, I don't think > > I have a complete list, can you suggest something?) and found out > > that I don't understand what is wrong with traditional syslogd from > > security standpoint. > > > > Could someone explain me or point me to some resources that explain > > why syslogd is bad? > > Prove to me that your log files have any integrity, in such a way that > I cannot dispute it. Or even less interesting: What happens to log records being sent over the network to a host that is in the process of rebooting? Or: What happens to network logging if you send an ICMP connection refused to the client syslog host? I noticed the other day that unlike our newsyslog, BSD/OS 3.0 actually loses lots of records when they perform log rotation, as they gzip the rotated file before sending the HUP to syslogd! I don't know if BSD/OS 4.0 does this also. We were upset to find that 3 hours of log records were missing from our maillog following the rotation. Clearly syslogd leaves much to be desired. However, it works fairly well if configured carefully. There have been discussions of alternatives, and I think someone claimed to have written a secure syslog at one point; I don't have a reference for it. I believe Schneier coauthored a paper on some of the cryptographic issues, also. Again, no references here as I'm out of town. If you can rely on kernel integrity due to securelevels, then presumably you can have it hold onto secrets and provide certain cryptographic integrity services. 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, Computing Laboratory at Cambridge University 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 Jul 9 2: 6:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from outpost.cpmc.net (outpost.lukarcos.com [195.239.240.132]) by hub.freebsd.org (Postfix) with SMTP id 77D1715540 for ; Fri, 9 Jul 1999 02:06:42 -0700 (PDT) (envelope-from sgk@outpost.cpmc.net) Received: (qmail 72927 invoked by uid 911); 9 Jul 1999 09:05:30 -0000 Date: Fri, 9 Jul 1999 13:05:30 +0400 From: Sergei Kolobov To: Robert Watson Cc: Darren Reed , Alla Bezroutchko , security@FreeBSD.ORG Subject: Re: Syslog alternatives? Message-ID: <19990709130530.A72919@cpmc.net> References: <199907090707.RAA16350@cheops.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: ; from Robert Watson on Fri, Jul 09, 1999 at 04:20:13AM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson wrote: > if configured carefully. There have been discussions of alternatives, and > I think someone claimed to have written a secure syslog at one point; I > don't have a reference for it. I believe Schneier coauthored a paper on I guess you were referring to nsyslogd by Darren Reed: 06/01/1999 - Darren Reed, the author of IP Filter, announced the release of Nsyslog, a syslog implementation that * supports TCP connections * can be used with SSL to encrypt delivery of syslog messages * can be used with libwrap and /etc/hosts.{allow,deny} to only accept log connections from given hosts * allows you to set a desired fsync rate for given log files More information is available at: http://coombs.anu.edu.au/~avalon/nsyslog.html --sgk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 2: 7:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from outpost.cpmc.net (outpost.lukarcos.com [195.239.240.132]) by hub.freebsd.org (Postfix) with SMTP id E82C61554F for ; Fri, 9 Jul 1999 02:06:38 -0700 (PDT) (envelope-from sgk@outpost.cpmc.net) Received: (qmail 72927 invoked by uid 911); 9 Jul 1999 09:05:30 -0000 Date: Fri, 9 Jul 1999 13:05:30 +0400 From: Sergei Kolobov To: Robert Watson Cc: Darren Reed , Alla Bezroutchko , security@FreeBSD.ORG Subject: Re: Syslog alternatives? Message-ID: <19990709130530.A72919@cpmc.net> References: <199907090707.RAA16350@cheops.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: ; from Robert Watson on Fri, Jul 09, 1999 at 04:20:13AM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson wrote: > if configured carefully. There have been discussions of alternatives, and > I think someone claimed to have written a secure syslog at one point; I > don't have a reference for it. I believe Schneier coauthored a paper on I guess you were referring to nsyslogd by Darren Reed: 06/01/1999 - Darren Reed, the author of IP Filter, announced the release of Nsyslog, a syslog implementation that * supports TCP connections * can be used with SSL to encrypt delivery of syslog messages * can be used with libwrap and /etc/hosts.{allow,deny} to only accept log connections from given hosts * allows you to set a desired fsync rate for given log files More information is available at: http://coombs.anu.edu.au/~avalon/nsyslog.html --sgk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 2:43: 4 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 1295514E0A for ; Fri, 9 Jul 1999 02:43:00 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id FAA24588; Fri, 9 Jul 1999 05:42:26 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 9 Jul 1999 05:42:26 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Sergei Kolobov Cc: Darren Reed , Alla Bezroutchko , security@FreeBSD.ORG Subject: Re: Syslog alternatives? In-Reply-To: <19990709130530.A72919@cpmc.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 Fri, 9 Jul 1999, Sergei Kolobov wrote: > Robert Watson wrote: > > if configured carefully. There have been discussions of alternatives, and > > I think someone claimed to have written a secure syslog at one point; I > > don't have a reference for it. I believe Schneier coauthored a paper on > > I guess you were referring to nsyslogd by Darren Reed: > > 06/01/1999 - Darren Reed, the author of IP Filter, announced the release of > Nsyslog, a syslog implementation that > > * supports TCP connections > * can be used with SSL to encrypt delivery of syslog messages > * can be used with libwrap and /etc/hosts.{allow,deny} to only accept log > connections from given hosts > * allows you to set a desired fsync rate for given log files > > More information is available at: > http://coombs.anu.edu.au/~avalon/nsyslog.html Wasn't the one I was thinking of, but it certainly qualifies :-). Does it actually authenticate the log data, or only the connection? I had in mind a protected process or kernel integrity protection service perhaps involving key management for signing of log records, plus rotation of key material, etc. I'll have to dig up the secure logging paper. 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, Computing Laboratory at Cambridge University 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 Jul 9 3:29:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id DFC431524E for ; Fri, 9 Jul 1999 03:28:59 -0700 (PDT) (envelope-from fjoe@iclub.nsu.ru) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id RAA29440; Fri, 9 Jul 1999 17:25:05 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Date: Fri, 9 Jul 1999 17:25:04 +0700 (NSS) From: Max Khon To: Mark Murray Cc: Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: Re: Improved libcrypt ready for testing In-Reply-To: <199907071948.VAA21415@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi, there! On Wed, 7 Jul 1999, Mark Murray wrote: > > > libcrypt code is already very modular internally, so making it pluggable is > > > the logical next step. > > > > Actually, you may want to have a chat with Mark Murray before implementing a > > new security-related config file. I think that he plans to restart PAM > > development soon, and this sounds like something that he might be interested > > in. > > Absolutely. JDP is going to give me his PAM bits this weekend, and I'll be > Full Steam Ahead with them. is there anybody interested in NSS (Name Service Switch) implementation? /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 7:31:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id C2B2A14F23 for ; Fri, 9 Jul 1999 07:31:34 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id AAA07721; Sat, 10 Jul 1999 00:01:30 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA21706; Sat, 10 Jul 1999 00:01:14 +0930 Date: Sat, 10 Jul 1999 00:01:13 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Max Khon Cc: Mark Murray , Keith Stevenson , freebsd-security@freebsd.org Subject: Re: Improved libcrypt ready for testing 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 Fri, 9 Jul 1999, Max Khon wrote: > > Absolutely. JDP is going to give me his PAM bits this weekend, and I'll be > > Full Steam Ahead with them. > > is there anybody interested in NSS (Name Service Switch) implementation? Terry Lambert, almost certainly :-) I think it would be a good idea too, but it's really a separate initiative to PAM and the stuff I'm working on with modularizing libcrypt. Not to say it shouldn't be done if you're looking for a project - this kind of base modularity is always good, IMO. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 9:10: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (unknown [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id F1B8415632 for ; Fri, 9 Jul 1999 09:09:59 -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.8.8/8.8.8) with SMTP id KAA11085; Fri, 9 Jul 1999 10:09:47 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA06341; Fri, 9 Jul 1999 10:09:45 -0600 Date: Fri, 9 Jul 1999 10:09:45 -0600 Message-Id: <199907091609.KAA06341@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Watson Cc: Nate Williams , Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: References: <199907081645.KAA29163@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > There are other issues with the KTRACE facility that have come up. Most > > notably, for IDS systems, you need a *LOT* more information than KTRACE > > provides. .... > > This is certainly true--I believe KTRACE also does not provide the > environmental variables, also desirable at exec-time. I suppose what we > should really be doing, in line with what we've discussed thus far, as > assembling an API for submitting IDS information. Hopefully one a little > more general and cleaner than the hack I have been using. Something > exposed enough in syscalls that it is clear to the casual syscall > implementer how to apply it in their own code. Maybe something on the > order of: > > #ifdef POSIX_AUD > /* declare a record context */ > audrec_t audrec; > #endif > > ... > > #ifdef POSIX_AUD > /* allocate the record */ > if (!audrec = k_aud_new_record()) > return(...appropriate error...) Or not. No being able to create an audit record should not cause the syscall to fail, but that's another discussion in itself. :) > > k_aud_settype(audrec, AUD_AEV_CHMOD); > k_aud_setcred(audrec, p->p_cred); > > ... > #endif Agreed. This is a *good* thing, and appears to be what Solaris does in it's BSM module. > The problem raised here again, of course, is the copyin of string > arguments. I don't see any way around this, given the audit record needs to exist as a discrete record that has a lifetime outside of the syscall, so the information must be copied in. Yes, it does mean that it will have to be copied in to stored in the kernel, and then copied out, but given that the time difference between in/out could be long (in terms of computer time) I can't think of another solution. Does anyone else have any ideas? > Another problem is error-handling: at any possible exit point > from the syscall, we need to commit an audit record describing the exit > (in error, success, etc). Again, I am in total agreement with you. Especially given that we have already agreed that the type of information gathered is already syscall specific. Adding exit hooks isn't that much more difficult. > This suggests instead making auditing to some > extent implicit to the syscall: a record is created associated with the > process structure (or thread or whatevr) when entering kernel mode, and > committed when returning to userland (or explicitely committed if we are > never going to return, i.e., the process called _exit). Kernel code in > the syscall may optionally add additional information about the kernel > entry point using a set of calls that automatically modify the implicit > audit record state associated with the proc, meaning no need to allocate > an audrec or pass it into all the routines, as it might be in > p->p_curaudrec. > > #ifdef POSIX_AUD > AUD_SET_SYSCALL(AUD_AEV_CHMOD); > AUD_ADD_ARG(AUD_PATHNAME, ...); > AUD_ADD_ARG(AUD_MODE, SC(args, mdoe)); > ... > #endif I don't think this will work, simply because how do we differentiate between different syscall that will eventually be running in parallel in the kernel? > Information like credentials, pid, return code, syscall number would > automatically be inserted when available by the syscall handler. Why not just add it at the entry point to the syscall? We're going to have to instrument them all anyway, so why not make things consistant by instrumenting at the syscall entry/exit points? > Syscall > number could be overriden by an explicit call. This still leaves us with > dealing with the arguments, especially pathnames and arrays of strings > (e.g., argv[] or env[]). See above. We can properly deal with the arguments if we have the context of these arguments, which of course we do at particular syscall entry point (execve, chmod, link, etc...) > > I'm of the opinion that to make truly useful IDS records, we're going to > > have to make some significant changes to the FreeBSD kernel. Note, > > these changes are only going to affect folks who ask for kernel auditing > > (not KTRACE), but because of the type and quantity of information > > desired in IDS systems, it will cause a performance hit in those systems > > that desire it. > > The difference between "don't want any auditing" and "interested in > auditing" is easily enough dealt with by #ifdef POSIX_AUD. Agreed. > The difference > between "some auditing" and "all auditing" is more challenging: to what > degree is filtering of records in the kernel appropriate, and to what > degree should that be done by a userland audit daemon or audit record > manager? A large volume stream of records in the kernel bloats the kernel > and cuts into preemptible execution time. But adding too much filtering > in kernel is costly also, and requires a lot more bloat in the kernel. I believe there is a trade-off that allows us to somehow 'reduce' creation of records with a simple filtering scheme that should be much more effecient than generating records that the benefits are easily seen. However, this is probably not needed for IDS-V1. :) > POSIX.1E only defines a way to tell whether auditing is turned on or off > for a specific process, and to toggle that (so that, for example, the > audit daemon can turn off auditing so as to prevent feedback on audit > record delivery). This seems to broad to me. Suppose active IDS modules > only require fork(), exec() and exit() tracing--then delivering the > 20,000 calls to gettimeofday() is a waste of resources. See above. However, building a truly generic filtering mechanism would be 'hard to do', so for now I think we can live with no filtering, or a very simple filtering scheme. But, will the FreeBSD kernel maintainers allow this is another story. :( > For my userland audit daemon, I currently have a simple propositional > logic matching language, essentially providing boolean matching on record > features (requiring certain named entries to exist, perhaps requiring > certain things of their value) for the audit daemon to pass a record to a > particular dynamically linked module. That seems like too much overhead > to go in the kernel, perhaps, and also too late as a fairly large amount > of the effort goes in to copying around strings and allocating space: once > it's all been collected, you've expended the energy you hoped to save. See above. > > Unfortunately, I don't see any way around this if we want useful IDS > > records. I also don't know how well the FreeBSD kernel guys are going > > to take having almost every kernel source file modified in an attempt to > > 'slow down' the system to get IDS information. :) > > My comments on all this are above--I had hoped KTRACE could ease > introduction, but I'm concerned it cannot without significant overhead and > modification. We're in complete agreement here. KTRACE has insufficient information to provide adequate IDS information. Therefore, in order to do this correctly, it will require instrumenting the kernel. How that is accomplished is still up for discussion, and it must be OK'd by the FreeBSD maintainers, but I hope we can come up with a workable solution that satisfies all parties. Nate ps. I'm on vacation all next week, so I'll be away from email. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 9:20:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7891314BF8 for ; Fri, 9 Jul 1999 09:20:23 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id MAA16574; Fri, 9 Jul 1999 12:20:05 -0400 (EDT) (envelope-from wollman) Date: Fri, 9 Jul 1999 12:20:05 -0400 (EDT) From: Garrett Wollman Message-Id: <199907091620.MAA16574@khavrinen.lcs.mit.edu> To: Nate Williams Cc: Robert Watson , Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: <199907091609.KAA06341@mt.sri.com> References: <199907081645.KAA29163@mt.sri.com> <199907091609.KAA06341@mt.sri.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: >> The problem raised here again, of course, is the copyin of string >> arguments. > Does anyone else have any ideas? Add auditing data in struct nameidata, and continue to track the information inside of namei. > I don't think this will work, simply because how do we differentiate > between different syscall that will eventually be running in parallel in > the kernel? They will be running in different execution contexts (i.e., processes, at least in the CS-theoretic sense). > I believe there is a trade-off that allows us to somehow 'reduce' > creation of records with a simple filtering scheme that should be much > more effecient than generating records that the benefits are easily > seen. BAF (``Berkeley auditing filter'') -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 9:25: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7232C14BE1 for ; Fri, 9 Jul 1999 09:25:03 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA05101; Fri, 9 Jul 1999 10:24:56 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA20280; Fri, 9 Jul 1999 10:22:45 -0600 (MDT) Message-Id: <199907091622.KAA20280@harmony.village.org> To: Gustavo V G C Rios Subject: Re: suid/guid Cc: security@FreeBSD.ORG, bos-owner-br@sekure.org In-reply-to: Your message of "Thu, 08 Jul 1999 13:39:28 -0300." <3784D440.1075EFB3@tdnet.com.br> References: <3784D440.1075EFB3@tdnet.com.br> Date: Fri, 09 Jul 1999 10:22:45 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <3784D440.1075EFB3@tdnet.com.br> Gustavo V G C Rios writes: : /bin/df This is setgid operator. It is that so that it can report the amount of disk space free on unmounted partitions, assuming those disks are group readable by operator (which is the default). If it makes you nervous, you can remove its setgid-ness. Idea: Would it make sense to document in the makefiles of these programs why it is set[ug]id? I think it would... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 9:27:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (unknown [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 7B91515146 for ; Fri, 9 Jul 1999 09:27:39 -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.8.8/8.8.8) with SMTP id KAA11332; Fri, 9 Jul 1999 10:27:26 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA06672; Fri, 9 Jul 1999 10:27:25 -0600 Date: Fri, 9 Jul 1999 10:27:25 -0600 Message-Id: <199907091627.KAA06672@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Garrett Wollman Cc: Nate Williams , Robert Watson , Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: <199907091620.MAA16574@khavrinen.lcs.mit.edu> References: <199907081645.KAA29163@mt.sri.com> <199907091609.KAA06341@mt.sri.com> <199907091620.MAA16574@khavrinen.lcs.mit.edu> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> The problem raised here again, of course, is the copyin of string > >> arguments. > > > Does anyone else have any ideas? > > Add auditing data in struct nameidata, and continue to track the > information inside of namei. Should we bloat the struct to include all of the necessary information? What happens when the kernel generates 'too much' information and the information must be expired from the cache *before* the userland process gets a hold of it. > > I don't think this will work, simply because how do we differentiate > > between different syscall that will eventually be running in parallel in > > the kernel? > > They will be running in different execution contexts (i.e., processes, > at least in the CS-theoretic sense). With the arguments that were given to the MACRO, there was no way to differentiate between different 'processes'. How do you know what 'process' you're in in the FreeBSD kernel. p-curproc only works if you have p, and may not be accurate in an SMP kernel. > > I believe there is a trade-off that allows us to somehow 'reduce' > > creation of records with a simple filtering scheme that should be much > > more effecient than generating records that the benefits are easily > > seen. > > BAF (``Berkeley auditing filter'') Agreed. I've spoken on this subject with my employers about this already in months past, but doing this is non-trivial. But I agree that eventually we should do something like this. Not today though. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 9:28: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2AC32156ED for ; Fri, 9 Jul 1999 09:27:57 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA05111; Fri, 9 Jul 1999 10:28:04 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA20308; Fri, 9 Jul 1999 10:25:55 -0600 (MDT) Message-Id: <199907091625.KAA20308@harmony.village.org> To: Alla Bezroutchko Subject: Re: Syslog alternatives? Cc: FreeBSD Security In-reply-to: Your message of "Fri, 09 Jul 1999 10:49:24 +0400." <37859B74.7528C158@sovlink.ru> References: <37859B74.7528C158@sovlink.ru> Date: Fri, 09 Jul 1999 10:25:55 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <37859B74.7528C158@sovlink.ru> Alla Bezroutchko writes: : Could someone explain me or point me to some resources that explain : why syslogd is bad? By default, syslogd will accept messages from anybody. DoS implications in doing that are ignored, so it remains vulnerable to a fill up the disk attack. Secure switches make it less vulnerable. I don't think that there is anything major enough wrong with syslogd to actually try to replace it. If there are bad things that can happen when -s is specified, I'd sure like to know about them. Warner FreeBSD Security Officer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 9:30:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 64F9A15641 for ; Fri, 9 Jul 1999 09:30:17 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA05121; Fri, 9 Jul 1999 10:30:24 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA20328; Fri, 9 Jul 1999 10:28:16 -0600 (MDT) Message-Id: <199907091628.KAA20328@harmony.village.org> To: Alla Bezroutchko Subject: Re: Syslog alternatives? Cc: Darren Reed , security@FreeBSD.ORG In-reply-to: Your message of "Fri, 09 Jul 1999 11:57:12 +0400." <3785AB58.2B3D8F05@sovlink.ru> References: <3785AB58.2B3D8F05@sovlink.ru> <199907090707.RAA16350@cheops.anu.edu.au> Date: Fri, 09 Jul 1999 10:28:15 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <3785AB58.2B3D8F05@sovlink.ru> Alla Bezroutchko writes: : > Prove to me that your log files have any integrity, in such a way that : > I cannot dispute it. : : How integrity is achieved with syslog's alternatives? That's a good question.... In order to do that, you'd have to have some kind of public-key private-key mechanism based on shared secrets to be sure. I'm not sure how you can really achieve a secure log file integrity when things like VI exist... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 9:37:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from suburbia.net (gw.iq.org [203.4.184.233]) by hub.freebsd.org (Postfix) with SMTP id 6A2BE155CB for ; Fri, 9 Jul 1999 09:37:21 -0700 (PDT) (envelope-from proff@suburbia.net) Received: (qmail 22244 invoked by uid 110); 9 Jul 1999 16:34:59 -0000 Message-ID: <19990709163459.22243.qmail@suburbia.net> From: proff@suburbia.net Subject: Re: Syslog alternatives? In-Reply-To: <199907091628.KAA20328@harmony.village.org> from Warner Losh at "Jul 9, 99 10:28:15 am" To: imp@village.org (Warner Losh) Date: Sat, 10 Jul 1999 02:34:59 +1000 (EST) Cc: alla@sovlink.ru, avalon@coombs.anu.edu.au, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In message <3785AB58.2B3D8F05@sovlink.ru> Alla Bezroutchko writes: > : > Prove to me that your log files have any integrity, in such a way that > : > I cannot dispute it. > : > : How integrity is achieved with syslog's alternatives? > > That's a good question.... In order to do that, you'd have to have > some kind of public-key private-key mechanism based on shared secrets > to be sure. I'm not sure how you can really achieve a secure log file > integrity when things like VI exist... > > Warner Just because you can't think of an answer doesn't mean there isn't one :) Cheers, Julian. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 9:40:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2CE0714BE1 for ; Fri, 9 Jul 1999 09:40:22 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA05159; Fri, 9 Jul 1999 10:40:25 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA20428; Fri, 9 Jul 1999 10:38:17 -0600 (MDT) Message-Id: <199907091638.KAA20428@harmony.village.org> To: proff@suburbia.net Subject: Re: Syslog alternatives? Cc: alla@sovlink.ru, avalon@coombs.anu.edu.au, security@FreeBSD.ORG In-reply-to: Your message of "Sat, 10 Jul 1999 02:34:59 +1000." <19990709163459.22243.qmail@suburbia.net> References: <19990709163459.22243.qmail@suburbia.net> Date: Fri, 09 Jul 1999 10:38:16 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19990709163459.22243.qmail@suburbia.net> proff@suburbia.net writes: : Just because you can't think of an answer doesn't mean there isn't one :) So elighten me :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 9:43: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 6C935155CB for ; Fri, 9 Jul 1999 09:43:11 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA25970; Fri, 9 Jul 1999 12:42:52 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 9 Jul 1999 12:42:52 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Nate Williams Cc: Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: <199907091609.KAA06341@mt.sri.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 Fri, 9 Jul 1999, Nate Williams wrote: > > #ifdef POSIX_AUD > > /* allocate the record */ > > if (!audrec = k_aud_new_record()) > > return(...appropriate error...) > > Or not. No being able to create an audit record should not cause the > syscall to fail, but that's another discussion in itself. :) Indeed it is--offhand I see two choices: 1) you don't let a syscall succeed unless you can audit it, as otherwise you won't set off your IDS as they can overload the system, or 2) an IDS module recognizes that a congested audit system may be an attack. Blocking for an available record might be a problem if it results in deadlock... > > The problem raised here again, of course, is the copyin of string > > arguments. > > I don't see any way around this, given the audit record needs to exist > as a discrete record that has a lifetime outside of the syscall, so the > information must be copied in. Yes, it does mean that it will have to > be copied in to stored in the kernel, and then copied out, but given > that the time difference between in/out could be long (in terms of > computer time) I can't think of another solution. > > Does anyone else have any ideas? My concern was that it was being copied in twice, as opposed to that it was being copied in. I'm tempted to pull the copyin out of namei and instead pass in a string buffer to namei, stored in kernel space. > > Another problem is error-handling: at any possible exit point > > from the syscall, we need to commit an audit record describing the exit > > (in error, success, etc). > > Again, I am in total agreement with you. Especially given that we have > already agreed that the type of information gathered is already > syscall specific. Adding exit hooks isn't that much more difficult. I did something like this to add speculative process execution to FreeBSD/i386 a few months ago (that is, generating disk prefetch hints based on speculatively executing a sandboxed process copy), and it proved quite straightforward. However, I believe the architecture-dependent code is what sits directly below the syscall code: we should perhaps insert another architecture-independent layer that wraps the syscall, where things like this can be placed. Similarly, auditing signal delivery would need to happen the same way: currently signal deliver lives in architecture-dependent-land, and we'd want the auditing wrapper to sit somewhere independent of architecture, I suspect. > > This suggests instead making auditing to some > > extent implicit to the syscall: a record is created associated with the > > process structure (or thread or whatevr) when entering kernel mode, and > > committed when returning to userland (or explicitely committed if we are > > never going to return, i.e., the process called _exit). Kernel code in > > the syscall may optionally add additional information about the kernel > > entry point using a set of calls that automatically modify the implicit > > audit record state associated with the proc, meaning no need to allocate > > an audrec or pass it into all the routines, as it might be in > > p->p_curaudrec. > > > > #ifdef POSIX_AUD > > AUD_SET_SYSCALL(AUD_AEV_CHMOD); > > AUD_ADD_ARG(AUD_PATHNAME, ...); > > AUD_ADD_ARG(AUD_MODE, SC(args, mdoe)); > > ... > > #endif > > I don't think this will work, simply because how do we differentiate > between different syscall that will eventually be running in parallel in > the kernel? As Garrett mentions, there will still be a context record from somewhere that could be extended to carry an active audit record for the activities of that context. Presumably that is the place to put it? > > Information like credentials, pid, return code, syscall number would > > automatically be inserted when available by the syscall handler. > > Why not just add it at the entry point to the syscall? We're going to > have to instrument them all anyway, so why not make things consistant by > instrumenting at the syscall entry/exit points? Yes. > > Syscall > > number could be overriden by an explicit call. This still leaves us with > > dealing with the arguments, especially pathnames and arrays of strings > > (e.g., argv[] or env[]). > > See above. We can properly deal with the arguments if we have the > context of these arguments, which of course we do at particular syscall > entry point (execve, chmod, link, etc...) But we do have to know what the syscall is, otherwise we don't understand the arguments. I think the argument sniffing should happen inside the current syscall code so that it's obvious to people changing the syscall that they need to update the auditing behavior--otherwise we have inconsistent sources of argument data? (perhaps this could go in syscalls.master and be assembled as part of that?) > > The difference > > between "some auditing" and "all auditing" is more challenging: to what > > degree is filtering of records in the kernel appropriate, and to what > > degree should that be done by a userland audit daemon or audit record > > manager? A large volume stream of records in the kernel bloats the kernel > > and cuts into preemptible execution time. But adding too much filtering > > in kernel is costly also, and requires a lot more bloat in the kernel. > > I believe there is a trade-off that allows us to somehow 'reduce' > creation of records with a simple filtering scheme that should be much > more effecient than generating records that the benefits are easily > seen. > > However, this is probably not needed for IDS-V1. :) I agree. Currently I have a userland matching mechanism, but it's not very efficient as this is really just an initial exploration. My feeling is that some very simple limiting mechanisms would be quite sufficient to block the majority of the unneeded record generation. For example, per-syscall-number and per-pid, per-uid, etc, plus a per-process enable flag on auditing. This can be caught quite early, and all submissions become no-ops on the record. > > POSIX.1E only defines a way to tell whether auditing is turned on or off > > for a specific process, and to toggle that (so that, for example, the > > audit daemon can turn off auditing so as to prevent feedback on audit > > record delivery). This seems to broad to me. Suppose active IDS modules > > only require fork(), exec() and exit() tracing--then delivering the > > 20,000 calls to gettimeofday() is a waste of resources. > > See above. However, building a truly generic filtering mechanism would > be 'hard to do', so for now I think we can live with no filtering, or a > very simple filtering scheme. But, will the FreeBSD kernel maintainers > allow this is another story. :( See above: simple stuff in kernel may be the optimum approach, and I suspect a little bit of simple goes a long way. > Nate > > ps. I'm on vacation all next week, so I'll be away from email. Have a great time. 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, Computing Laboratory at Cambridge University 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 Jul 9 9:46: 9 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 EC9C11563D for ; Fri, 9 Jul 1999 09:46:03 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA25989; Fri, 9 Jul 1999 12:45:32 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 9 Jul 1999 12:45:32 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: proff@suburbia.net Cc: Warner Losh , alla@sovlink.ru, avalon@coombs.anu.edu.au, security@FreeBSD.ORG Subject: Re: Syslog alternatives? In-Reply-To: <19990709163459.22243.qmail@suburbia.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 Sat, 10 Jul 1999 proff@suburbia.net wrote: > > In message <3785AB58.2B3D8F05@sovlink.ru> Alla Bezroutchko writes: > > : > Prove to me that your log files have any integrity, in such a way that > > : > I cannot dispute it. > > : > > : How integrity is achieved with syslog's alternatives? > > > > That's a good question.... In order to do that, you'd have to have > > some kind of public-key private-key mechanism based on shared secrets > > to be sure. I'm not sure how you can really achieve a secure log file > > integrity when things like VI exist... > > > > Warner > > Just because you can't think of an answer doesn't mean there isn't one :) I still lean towards a combination of existing securelevel code, and a protected process flag indicating that the process may not be intefered with by unauthorized userland code (i.e., no debugging, signaling, etc). Alternatively a kernel thread, but the lack of preemption is unappealing. Also, a kernel-based "integrity stamper" that MAC's a log entry along with some noise, and a date-time stamp, would at least prevent individual records from being modified or reordered. It doesn't prevent removal, but as long as the kernel is ok, it's worth something. 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, Computing Laboratory at Cambridge University 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 Jul 9 9:55:49 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 6849314C0D for ; Fri, 9 Jul 1999 09:55:46 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id SAA53727; Fri, 9 Jul 1999 18:55:13 +0200 (CEST) (envelope-from des) To: Warner Losh Cc: Gustavo V G C Rios , security@FreeBSD.ORG, bos-owner-br@sekure.org Subject: Re: suid/guid References: <3784D440.1075EFB3@tdnet.com.br> <199907091622.KAA20280@harmony.village.org> From: Dag-Erling Smorgrav Date: 09 Jul 1999 18:55:12 +0200 In-Reply-To: Warner Losh's message of "Fri, 09 Jul 1999 10:22:45 -0600" Message-ID: Lines: 11 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh writes: > Idea: Would it make sense to document in the makefiles of these > programs why it is set[ug]id? I think it would... I think it would be an excellent idea... it would also make sense to document how the program will behave if it is not s[ug]id and how much of the functionality will be lost. 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 Jul 9 10: 0:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id EAB2B15645 for ; Fri, 9 Jul 1999 10:00:16 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA05212; Fri, 9 Jul 1999 11:00:17 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA20551; Fri, 9 Jul 1999 10:58:08 -0600 (MDT) Message-Id: <199907091658.KAA20551@harmony.village.org> To: Dag-Erling Smorgrav Subject: Re: suid/guid Cc: Gustavo V G C Rios , security@FreeBSD.ORG, bos-owner-br@sekure.org In-reply-to: Your message of "09 Jul 1999 18:55:12 +0200." References: <3784D440.1075EFB3@tdnet.com.br> <199907091622.KAA20280@harmony.village.org> Date: Fri, 09 Jul 1999 10:58:08 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Dag-Erling Smorgrav writes: : I think it would be an excellent idea... it would also make sense to : document how the program will behave if it is not s[ug]id and how much : of the functionality will be lost. Agreed. I'm also starting to think that a system-wide tunable that would turn off almost all of the set[ug]id installation. Almost nobody needs setuidperl, for example. If df is installed w/o setgid operator, almost no functionality is lost. etc. Of course exatly what would be lost would be documented. Comments? Warner P.S. This is more of a failsafe option. As far as I know there are no bugs that will result in an elevated level of privs in the set*id programs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 10:11:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (unknown [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 39DA415645 for ; Fri, 9 Jul 1999 10:11:51 -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.8.8/8.8.8) with SMTP id LAA11951; Fri, 9 Jul 1999 11:11:33 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA07208; Fri, 9 Jul 1999 11:11:32 -0600 Date: Fri, 9 Jul 1999 11:11:32 -0600 Message-Id: <199907091711.LAA07208@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Watson Cc: Nate Williams , Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: References: <199907091609.KAA06341@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > #ifdef POSIX_AUD > > > /* allocate the record */ > > > if (!audrec = k_aud_new_record()) > > > return(...appropriate error...) > > > > Or not. No being able to create an audit record should not cause the > > syscall to fail, but that's another discussion in itself. :) > > Indeed it is--offhand I see two choices: 1) you don't let a syscall > succeed unless you can audit it, as otherwise you won't set off your IDS > as they can overload the system, or 2) an IDS module recognizes that a > congested audit system may be an attack. Blocking for an available record > might be a problem if it results in deadlock... My thinking is that we 'pre-allocate' a AUDIT_RECORD_FAILED record, and use it to inform the system that a record was unable to be generated. Therefore, you have an idea that something is missing, but you don't slow down the the system or cause deadlock. > > > The problem raised here again, of course, is the copyin of string > > > arguments. > > > > I don't see any way around this, given the audit record needs to exist > > as a discrete record that has a lifetime outside of the syscall, so the > > information must be copied in. Yes, it does mean that it will have to > > be copied in to stored in the kernel, and then copied out, but given > > that the time difference between in/out could be long (in terms of > > computer time) I can't think of another solution. > > > > Does anyone else have any ideas? > > My concern was that it was being copied in twice, as opposed to that it > was being copied in. I'm tempted to pull the copyin out of namei and > instead pass in a string buffer to namei, stored in kernel space. Ahh, I understand now. You are worried about one or the other of namei/audit copyin being redundant. I misunderstood both you and Garrett. Would it be possible to copy the string from the namei buffer, thus avoiding the issue of modifying namei? > > > Another problem is error-handling: at any possible exit point > > > from the syscall, we need to commit an audit record describing the exit > > > (in error, success, etc). > > > > Again, I am in total agreement with you. Especially given that we have > > already agreed that the type of information gathered is already > > syscall specific. Adding exit hooks isn't that much more difficult. > > I did something like this to add speculative process execution to > FreeBSD/i386 a few months ago (that is, generating disk prefetch hints > based on speculatively executing a sandboxed process copy), and it proved > quite straightforward. However, I believe the architecture-dependent code > is what sits directly below the syscall code: we should perhaps insert > another architecture-independent layer that wraps the syscall, where > things like this can be placed. However, in the 'generic' code, it may not be obvious why the error occured, and this makes it more difficult to generate an audit record 'atomically' since the creation of the record happens in a completely different code-base from the 'end' of the record. We'd need to design some sort of even model in the audit record generation code, as well as pass in information in each sub-record to identify which record the sub-record belongs to. > Similarly, auditing signal delivery would > need to happen the same way: currently signal deliver lives in > architecture-dependent-land, and we'd want the auditing wrapper to sit > somewhere independent of architecture, I suspect. Are signals required for IDS? (Showing my ignorance here...) > > > This suggests instead making auditing to some > > > extent implicit to the syscall: a record is created associated with the > > > process structure (or thread or whatevr) when entering kernel mode, and > > > committed when returning to userland (or explicitely committed if we are > > > never going to return, i.e., the process called _exit). Kernel code in > > > the syscall may optionally add additional information about the kernel > > > entry point using a set of calls that automatically modify the implicit > > > audit record state associated with the proc, meaning no need to allocate > > > an audrec or pass it into all the routines, as it might be in > > > p->p_curaudrec. > > > > > > #ifdef POSIX_AUD > > > AUD_SET_SYSCALL(AUD_AEV_CHMOD); > > > AUD_ADD_ARG(AUD_PATHNAME, ...); > > > AUD_ADD_ARG(AUD_MODE, SC(args, mdoe)); > > > ... > > > #endif > > > > I don't think this will work, simply because how do we differentiate > > between different syscall that will eventually be running in parallel in > > the kernel? > > As Garrett mentions, there will still be a context record from somewhere > that could be extended to carry an active audit record for the activities > of that context. Presumably that is the place to put it? How is this record 'identified' from the other records being generated in parallel by the other CPUs? (In other words, what identifies this process from other process in the above code. We're not passing the proc structure around....) > > > Information like credentials, pid, return code, syscall number would > > > automatically be inserted when available by the syscall handler. > > > > Why not just add it at the entry point to the syscall? We're going to > > have to instrument them all anyway, so why not make things consistant by > > instrumenting at the syscall entry/exit points? > > Yes. > > > > Syscall > > > number could be overriden by an explicit call. This still leaves us with > > > dealing with the arguments, especially pathnames and arrays of strings > > > (e.g., argv[] or env[]). > > > > See above. We can properly deal with the arguments if we have the > > context of these arguments, which of course we do at particular syscall > > entry point (execve, chmod, link, etc...) > > But we do have to know what the syscall is, otherwise we don't understand > the arguments. We have a miscommunication. When I say syscall entry/exit points, I'm *NOT* talking about the machine dependant points, I'm talking about the machine independant points. n /sys/kern/kern_exec.c, the syscall 'entry/exit' point is in the routine is: /* * execve() system call. */ int execve(p, uap, retval) struct proc *p; register struct execve_args *uap; int *retval; { This is the code that needs to be instrumented, otherwise we have a nightmare on our hands. We need to know that kind of information anyway, so why not put in in the most likely place. This also buys us the cross-platform compatability (not MD code), and makes it *very* obvious what information is gathered. Unfortunately, it means changing lots of kernel files, but to do this correctly and in a way that is understandable, I don't see a better solution. Trying to 'sniff' what the syscall is at a lower layer and generating the necessary information means we may end up doing the same sort of information gathering that already exists in the real system call implementation. In other words, I think we're in violent agreement, but I'm not sure. ;) [ Kernel filtering ] > > However, this is probably not needed for IDS-V1. :) > > I agree. Currently I have a userland matching mechanism, but it's not > very efficient as this is really just an initial exploration. My feeling > is that some very simple limiting mechanisms would be quite sufficient to > block the majority of the unneeded record generation. For example, > per-syscall-number and per-pid, per-uid, etc, plus a per-process enable > flag on auditing. This can be caught quite early, and all submissions > become no-ops on the record. > > > > POSIX.1E only defines a way to tell whether auditing is turned on or off > > > for a specific process, and to toggle that (so that, for example, the > > > audit daemon can turn off auditing so as to prevent feedback on audit > > > record delivery). This seems to broad to me. Suppose active IDS modules > > > only require fork(), exec() and exit() tracing--then delivering the > > > 20,000 calls to gettimeofday() is a waste of resources. > > > > See above. However, building a truly generic filtering mechanism would > > be 'hard to do', so for now I think we can live with no filtering, or a > > very simple filtering scheme. But, will the FreeBSD kernel maintainers > > allow this is another story. :( > > See above: simple stuff in kernel may be the optimum approach, and I > suspect a little bit of simple goes a long way. Agreed, although a mechanism similar to BPF may allow for more 'complex' filtering mechanisms and still be quite effecient at the kernel. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 10:38:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from phoenix (phoenix.aye.net [206.185.8.134]) by hub.freebsd.org (Postfix) with SMTP id 964BA15665 for ; Fri, 9 Jul 1999 10:38:21 -0700 (PDT) (envelope-from barrett@phoenix.aye.net) Received: (qmail 3734 invoked by uid 1000); 9 Jul 1999 17:35:16 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jul 1999 17:35:16 -0000 Date: Fri, 9 Jul 1999 13:35:16 -0400 (EDT) From: Barrett Richardson To: Gustavo V G C Rios Cc: security@freebsd.org, bos-owner-br@sekure.org Subject: Re: suid/guid In-Reply-To: <3784D440.1075EFB3@tdnet.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 On Thu, 8 Jul 1999, Gustavo V G C Rios wrote: > Which of the following file should i turn off suid/guid bit flag? > I just wanna keep the necessary file tunr on suid/guid! I am surviving with just these and I've recompiled them with a stackguard compiler. I've omitted sendmail from the list because I'm using qmail (it has some suid/guid stuff too). Some of the items in your list are duplicates because they have hard links (passwd and chpass in particular come to mine). I think ps works ok without suid for the most part, just missing some minor bits of information here and there. I probably (at the risk of irritating users and admins alike) could remove suid/guid from w (uptime), traceroute, ping and df. I *could* get by with the bare minimum of passwd, man, login and su (plus an SMTP agent like sendmail or qmail). /usr/bin/passwd /usr/bin/man /usr/bin/chpass /usr/bin/login /usr/bin/su /usr/bin/w /usr/sbin/traceroute /sbin/ping /bin/df /bin/ps - Barrett > > My system is freebsd-3.2Stable > > Here goes them: > > /proc/2965/file > /bin/df > /bin/ps > /bin/rcp > /sbin/ccdconfig > /sbin/dmesg > /sbin/dump > /sbin/rdump > /sbin/ping > /sbin/restore > /sbin/rrestore > /sbin/route > /sbin/shutdown > /usr/bin/cu > /usr/bin/uucp > /usr/bin/uuname > /usr/bin/uustat > /usr/bin/uux > /usr/bin/man > /usr/bin/suidperl > /usr/bin/sperl5.00503 > /usr/bin/at > /usr/bin/atq > /usr/bin/atrm > /usr/bin/batch > /usr/bin/chpass > /usr/bin/chfn > /usr/bin/chsh > /usr/bin/ypchpass > /usr/bin/ypchfn > /usr/bin/ypchsh > /usr/bin/fstat > /usr/bin/ipcs > /usr/bin/keyinfo > /usr/bin/keyinit > /usr/bin/lock > /usr/bin/login > /usr/bin/netstat > /usr/bin/nfsstat > /usr/bin/passwd > /usr/bin/yppasswd > /usr/bin/quota > /usr/bin/rlogin > /usr/bin/rsh > /usr/bin/su > /usr/bin/systat > /usr/bin/top > /usr/bin/vmstat > /usr/bin/w > /usr/bin/uptime > /usr/bin/wall > /usr/bin/write > /usr/bin/crontab > /usr/bin/lpq > /usr/bin/lpr > /usr/bin/lprm > /usr/bin/newaliases > /usr/bin/mailq > /usr/bin/hoststat > /usr/libexec/uucp/uucico > /usr/libexec/uucp/uuxqt > /usr/libexec/mail.local > /usr/local/bin/screen-3.7.6 > /usr/local/bin/skill > /usr/local/bin/snice > /usr/local/bin/icmpinfo > /usr/local/sbin/queso > /usr/sbin/lpc > /usr/sbin/iostat > /usr/sbin/mrinfo > /usr/sbin/mtrace > /usr/sbin/pstat > /usr/sbin/swapinfo > /usr/sbin/sliplogin > /usr/sbin/timedc > /usr/sbin/traceroute > /usr/sbin/trpt > /usr/sbin/sendmail > /usr/sbin/purgestat > /usr/sbin/ppp > /usr/sbin/pppd > /usr/games/dm > > > 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 Jul 9 11:38:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from a.servers.aozilla.com (unknown [216.22.145.8]) by hub.freebsd.org (Postfix) with ESMTP id 52ACF15651 for ; Fri, 9 Jul 1999 11:38:33 -0700 (PDT) (envelope-from bsd@a.servers.aozilla.com) Received: from localhost (bsd@localhost) by a.servers.aozilla.com (8.8.7/8.8.8) with ESMTP id OAA14183; Fri, 9 Jul 1999 14:37:55 -0400 (EDT) Date: Fri, 9 Jul 1999 14:37:55 -0400 (EDT) From: "Mr. K." To: Warner Losh Cc: proff@suburbia.net, alla@sovlink.ru, avalon@coombs.anu.edu.au, security@FreeBSD.ORG Subject: Re: Syslog alternatives? In-Reply-To: <199907091638.KAA20428@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 9 Jul 1999, Warner Losh wrote: > In message <19990709163459.22243.qmail@suburbia.net> proff@suburbia.net writes: > : Just because you can't think of an answer doesn't mean there isn't one :) > > So elighten me :-) > just because ey can't think of one either doesn't mean there isn't one :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 13: 3:55 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 A729314FC7 for ; Fri, 9 Jul 1999 13:03:51 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id WAA57984; Fri, 9 Jul 1999 22:03:35 +0200 (CEST) (envelope-from des) To: Warner Losh Cc: Dag-Erling Smorgrav , Gustavo V G C Rios , security@FreeBSD.ORG, bos-owner-br@sekure.org Subject: Re: suid/guid References: <3784D440.1075EFB3@tdnet.com.br> <199907091622.KAA20280@harmony.village.org> <199907091658.KAA20551@harmony.village.org> From: Dag-Erling Smorgrav Date: 09 Jul 1999 22:03:35 +0200 In-Reply-To: Warner Losh's message of "Fri, 09 Jul 1999 10:58:08 -0600" Message-ID: Lines: 13 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh writes: > Agreed. I'm also starting to think that a system-wide tunable that > would turn off almost all of the set[ug]id installation. Almost > nobody needs setuidperl, for example. If df is installed w/o setgid > operator, almost no functionality is lost. etc. Of course exatly > what would be lost would be documented. Comments? None on the general concept - but one on the specific example: who except root needs to know what df(1) can report when sgid operator? 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 Jul 9 13: 9:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 3A71214EA2 for ; Fri, 9 Jul 1999 13:09:47 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA05605; Fri, 9 Jul 1999 14:09:49 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA21400; Fri, 9 Jul 1999 14:07:43 -0600 (MDT) Message-Id: <199907092007.OAA21400@harmony.village.org> To: Dag-Erling Smorgrav Subject: Re: suid/guid Cc: Gustavo V G C Rios , security@FreeBSD.ORG In-reply-to: Your message of "09 Jul 1999 22:03:35 +0200." References: <3784D440.1075EFB3@tdnet.com.br> <199907091622.KAA20280@harmony.village.org> <199907091658.KAA20551@harmony.village.org> Date: Fri, 09 Jul 1999 14:07:42 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Dag-Erling Smorgrav writes: : None on the general concept - but one on the specific example: who : except root needs to know what df(1) can report when sgid operator? There is only one case that I can think of. That case is when someone has a jaz disk that isn't mounted that they want to see how much space is available on it. Not a great example, and this person will need root to actually mount it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 14:29: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from mercurio.nar.ufv.br (mercurio.nar.ufv.br [200.18.130.84]) by hub.freebsd.org (Postfix) with SMTP id 096BF14E2C for ; Fri, 9 Jul 1999 14:28:49 -0700 (PDT) (envelope-from kernel@tdnet.com.br) Received: (qmail 412 invoked from network); 9 Jul 1999 21:22:37 -0000 Received: from mercurio.nar.ufv.br (HELO tdnet.com.br) (200.18.130.84) by mercurio.nar.ufv.br with SMTP; 9 Jul 1999 21:22:37 -0000 Message-ID: <3786681C.3882C645@tdnet.com.br> Date: Fri, 09 Jul 1999 18:22:36 -0300 From: Gustavo V G C Rios X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Dag-Erling Smorgrav , security@FreeBSD.ORG, bos-owner-br@sekure.org Subject: Re: suid/guid References: <3784D440.1075EFB3@tdnet.com.br> <199907091622.KAA20280@harmony.village.org> <199907091658.KAA20551@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yeah, it sounds great. IMHO, Common users should not be concerned about things related to admin. A good approach would be to design software in which no special privilegies should be required for common users use it. It would be nice to have one system just installed not many s/guid flags seted. So, if it's necessary to have any other thing, you (Sysadmin) should enable by himself. In 5 words: DENY every thing by default. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 15: 9:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from lazlo.internal.steam.com (lazlo.steam.com [199.108.84.37]) by hub.freebsd.org (Postfix) with ESMTP id 527FA14E8F for ; Fri, 9 Jul 1999 15:09:17 -0700 (PDT) (envelope-from cliff@steam.com) Received: from lazlo.internal.steam.com (cliff@lazlo.internal.steam.com [192.168.32.2]) by lazlo.internal.steam.com (8.9.3/8.9.3) with ESMTP id PAA05907; Fri, 9 Jul 1999 15:10:39 -0700 (PDT) Date: Fri, 9 Jul 1999 15:10:39 -0700 (PDT) From: Cliff Skolnick X-Sender: cliff@lazlo.internal.steam.com To: Dag-Erling Smorgrav Cc: Warner Losh , Gustavo V G C Rios , security@FreeBSD.ORG, bos-owner-br@sekure.org Subject: Re: suid/guid 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 I have cron jobs that want this info, and I would rather not run my cron jobs as root. IMHO a few setuid root, or setgid something executables are way better than setuid root cron scripts. I usually run my cron jobs as normal user like accounts, but I guess I could add groups to these specific accounts if needed. Better than root, but the account now has a higher class that normal users so it becomes an attractive target. Cliff On 9 Jul 1999, Dag-Erling Smorgrav wrote: > Warner Losh writes: > > Agreed. I'm also starting to think that a system-wide tunable that > > would turn off almost all of the set[ug]id installation. Almost > > nobody needs setuidperl, for example. If df is installed w/o setgid > > operator, almost no functionality is lost. etc. Of course exatly > > what would be lost would be documented. Comments? > > None on the general concept - but one on the specific example: who > except root needs to know what df(1) can report when sgid operator? > > 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 > -- Cliff Skolnick | "They that can give up essential liberty to obtain Steam Tunnel Operations | a little temporary safety deserve neither liberty cliff@steam.com | nor safety." http://www.steam.com/ | -- Benjamin Franklin, 1759 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 15:59: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 8ACC9150D9 for ; Fri, 9 Jul 1999 15:58:45 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA05987; Fri, 9 Jul 1999 16:58:43 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA22095; Fri, 9 Jul 1999 16:56:38 -0600 (MDT) Message-Id: <199907092256.QAA22095@harmony.village.org> To: Gustavo V G C Rios Subject: Re: suid/guid Cc: Dag-Erling Smorgrav , security@FreeBSD.ORG, bos-owner-br@sekure.org In-reply-to: Your message of "Fri, 09 Jul 1999 18:22:36 -0300." <3786681C.3882C645@tdnet.com.br> References: <3786681C.3882C645@tdnet.com.br> <3784D440.1075EFB3@tdnet.com.br> <199907091622.KAA20280@harmony.village.org> <199907091658.KAA20551@harmony.village.org> Date: Fri, 09 Jul 1999 16:56:38 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <3786681C.3882C645@tdnet.com.br> Gustavo V G C Rios writes: : A good approach would be to design software in which no special : privilegies should be required for common users use it. Generally that is the approach that has been taken. However, before the big push for these things, programs had been written with the group operator fuynctionality in mind... Hmmm, maybe that is a good way to partion things in /etc/make.conf... : In 5 words: DENY every thing by default. All things not explicitly allowed are forbidden. :-) I believe that in 1984 by George Orwell it was stated as "All things not compusory are forbidden" but I no longer have quick access to that book to check on the accuracy of the quote. We certainly don't wan to get into the Animal Farm (also by George Orwell) situation where all animals are created equal, its just that some animals are more equal than others... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 16:15:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7D816150E2 for ; Fri, 9 Jul 1999 16:15:22 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA06023; Fri, 9 Jul 1999 17:15:21 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA22161; Fri, 9 Jul 1999 17:13:16 -0600 (MDT) Message-Id: <199907092313.RAA22161@harmony.village.org> To: Cliff Skolnick Subject: Re: suid/guid Cc: Dag-Erling Smorgrav , Gustavo V G C Rios , security@FreeBSD.ORG, bos-owner-br@sekure.org In-reply-to: Your message of "Fri, 09 Jul 1999 15:10:39 PDT." References: Date: Fri, 09 Jul 1999 17:13:16 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Cliff Skolnick writes: : I have cron jobs that want this info, and I would rather not run my cron : jobs as root. IMHO a few setuid root, or setgid something executables are : way better than setuid root cron scripts. You have cron jobs that do a DF on unmounted file systems? That's the only thing that removing the setgid bit will impact. Generally, only root will want to do this. df on other file systems is unaffected as that information is available to non-priviledged users. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 9 19:13:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id BCFBF14D72 for ; Fri, 9 Jul 1999 19:13:35 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id EAA05870 for security@FreeBSD.ORG; Sat, 10 Jul 1999 04:13:33 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 07551885F; Sat, 10 Jul 1999 01:39:37 +0200 (CEST) (envelope-from roberto) Date: Sat, 10 Jul 1999 01:39:37 +0200 From: Ollivier Robert To: security@FreeBSD.ORG Subject: Re: Syslog alternatives? Message-ID: <19990710013937.A9554@keltia.freenix.fr> Mail-Followup-To: security@FreeBSD.ORG References: <199907090707.RAA16350@cheops.anu.edu.au> <19990709130530.A72919@cpmc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <19990709130530.A72919@cpmc.net>; from Sergei Kolobov on Fri, Jul 09, 1999 at 01:05:30PM +0400 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5443 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Sergei Kolobov: > More information is available at: > http://coombs.anu.edu.au/~avalon/nsyslog.html Don't forget the other one, Secure Syslog, by Brazilian guys. ============================================================================== Secure Syslog package INSTALL file (C)1998 Core-SDI. Buenos Aires, Argentina. ============================================================================== ... 1.a. Getting the last version The last version of the secure syslog package will always be available at http://www.core-sdi.com/ssyslog. You may want to check out for a new release before installing. The distribution file should look like 'ssyslog-X.XX.tar.gz'. Where X.XX stands for version number (i.e. 'ssyslog-0.99.tar.gz'). You will need also the GNU gunzip command in order to decompress it. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May 9 20:16:32 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message