From owner-freebsd-security Mon Jan 22 02:48:38 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA29162 for security-outgoing; Mon, 22 Jan 1996 02:48:38 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA29083 Mon, 22 Jan 1996 02:48:01 -0800 (PST) Received: by sequent.kiae.su id AA23739 (5.65.kiae-2 ); Mon, 22 Jan 1996 13:31:51 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 22 Jan 96 13:31:48 +0300 Received: (from ache@localhost) by ache.dialup.ru (8.7.3/8.7.3) id NAA00986; Mon, 22 Jan 1996 13:13:02 +0300 (MSK) To: Peter Wemm , ports@freebsd.org Cc: security@freebsd.org References: In-Reply-To: ; from Peter Wemm at Mon, 22 Jan 1996 17:14:24 +0800 (WST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 22 Jan 1996 13:13:02 +0300 (MSK) X-Mailer: Mail/@ [v2.42 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ssh /etc config files location.. Lines: 48 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk In message Peter Wemm writes: >I am still somewhat disturbed with the location of some rather critical >"per site" info from ssh in /usr/local/etc.. Specifically the ssh host >secret keys, and the per-site config files. >This is (IMHO) rather dangerous. If you NFS mount /usr/local, this will >screw you rather badly. >There are precedents against this too.. gated keeps it's config files in >/etc. There are precedent _for_ this, tcp_wrapper uses /usr/local/etc. Using NFS for /usr/local/bin/{security_binaries} is big risk too because they can be changes (like config files). I don't see the point to move security-related configs to /etc and _not_ to move security binaries from /usr/local. So there is two normal solutions: 1) Leave all as is in /usr/local, but not mount it over NFS 2) Move configs & binaries _both_ off /usr/local. I disagree with proposed solution (moving configs only to /etc). >PS: IMHO, it was a mistake adding the BUILD_DEPENDS in wish and perl5. it >build's fine without them. It seems silly to require X11 to be installed >in order to build the port.. It builds fine, but incomplete, namely: ssh-askpass needs wish make-ssh-known-hosts needs perl5 So here is two variants: 1) They are essential, so BUILD_DEPENDS is essential too. 2) They don't play big role. In this case they need to be controlled via USE_* variables like other stuff in ssh Makefile. I.e. corresponding BUILD_DEPENDS must be ifdefed. Removing BUILD_DEPENDS is bad in any case. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Mon Jan 22 05:00:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA09149 for security-outgoing; Mon, 22 Jan 1996 05:00:55 -0800 (PST) Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA09139 Mon, 22 Jan 1996 05:00:46 -0800 (PST) Received: from localhost.DIALix.oz.au (peter@localhost.DIALix.oz.au [127.0.0.1]) by jhome.DIALix.COM (8.7.3/8.7.3) with SMTP id UAA04035; Mon, 22 Jan 1996 20:59:22 +0800 (WST) Message-Id: <199601221259.UAA04035@jhome.DIALix.COM> X-Authentication-Warning: jhome.DIALix.COM: Host peter@localhost.DIALix.oz.au [127.0.0.1] didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: ports@freebsd.org, security@freebsd.org Subject: Re: ssh /etc config files location.. In-reply-to: Your message of "Mon, 22 Jan 1996 13:13:02 +0300." Date: Mon, 22 Jan 1996 20:59:21 +0800 From: Peter Wemm Sender: owner-security@freebsd.org Precedence: bulk >>I am still somewhat disturbed with the location of some rather critical >>"per site" info from ssh in /usr/local/etc.. Specifically the ssh host >>secret keys, and the per-site config files. > >>This is (IMHO) rather dangerous. If you NFS mount /usr/local, this will >>screw you rather badly. > >>There are precedents against this too.. gated keeps it's config files in >>/etc. > >There are precedent _for_ this, tcp_wrapper uses /usr/local/etc. True, but in the most likely case of having /usr/local shared (ie: a small group of machines) tcp_wrapper configs are most likely to be the same for all the hosts anyway. However, tcp_wrapper does not need to constantly write to any files in /usr/local/etc like sshd has been configured to do. >Using NFS for /usr/local/bin/{security_binaries} is big risk too >because they can be changes (like config files). >I don't see the point to move security-related configs to /etc >and _not_ to move security binaries from /usr/local. If you choose to run binaries off a machine, you are choosing to trust the security of your network and that machine. If I have two machines sitting right next to each other with 6 feet of ethernet cable, and not enough disk space, why shouldn't I be able to NFS share some things (like X11R6 and /usr/local). >So there is two normal solutions: >1) Leave all as is in /usr/local, but not mount it over NFS >2) Move configs & binaries _both_ off /usr/local. > >I disagree with proposed solution (moving configs only to /etc). I'm not worried so much about the config files, but I am worried about the run-time data generated by sshd that is written to the etcdir, and I'm also concerned about the critical public and private host keys. sshd_config and ssh_config could stay in /usr/local/etc for all I care. :-) I'm not complaining about this from a "security" point of view, I'm complaining about this from a "functionality" point of view. Remember, we still support mounting all of /usr via NFS. There's no need to make a special case for /usr/local with regard to running "security sensative" programs. If somebody has hacked your fileserver and replaced /usr/bin/login, it wont be long before some root process runs the fake "login" as root. (Hell, the hacker can telnet to your machine, and telnetd will run the hacked "login" as root right then..) >>PS: IMHO, it was a mistake adding the BUILD_DEPENDS in wish and perl5. it >>build's fine without them. It seems silly to require X11 to be installed >>in order to build the port.. > >It builds fine, but incomplete, namely: > >ssh-askpass needs wish >make-ssh-known-hosts needs perl5 Exactly.. It "builds fine". It probes to see if the tools exist, and codes in the exact pathnames if they are there, and puts in default pathnames if they are not. >So here is two variants: >1) They are essential, so BUILD_DEPENDS is essential too. >2) They don't play big role. In this case they need to be controlled >via USE_* variables like other stuff in ssh Makefile. I.e. corresponding >BUILD_DEPENDS must be ifdefed. > >Removing BUILD_DEPENDS is bad in any case. Why? If I dont have X11 installed on the target system (and NEVER will, because it's a dialup box), and hence will not have wish, and ssh does not need wish and will happily build without it, why should I be prevented from building the non-X11 port? As far as I can see, they are used like this: if "wish" on $PATH WISH=`location of wish` else WISH=/usr/local/bin/wish echo "Wish not installed, ssh-askpass will not work." fi ..... echo "#! $WISH" > ssh-askpass cat ssh-askpass.in >> ssh-askpass If you build ssh and later install wish, the ssh-askpass will then work. It's a runtime dependency, not a BUILD_DEPENDS. What I think should be done there, is that the default $PERL and $WISH should be patched to specify the correct "default" location for FreeBSD. Then, when the port is built, it will search the path and use the exact location of the binaries in case they are in non-standard locations, and will still build a functional result if it's not currently installed. ie: it'll be #! /usr/X11R6/bin/wish line in the ssh-askpass script. If you later want to run it, you merely need to install a wish package and it all works. ssh-make-known-hosts does not work correctly when probing anything other than a FreeBSD box with ssh build from this port, because it's looking for /etc/ssh_host_key.pub in the wrong location. The SSH author complained to me that we were doing this. Hmm, I just re-ran the "make" to build the port. I can see that there are a few things that "configure" has got wrong... It should also use the system libgmp and the zlib port rather than building it's own.... >-- >Andrey A. Chernov : And I rest so composedly, /Now, in my bed, >ache@astral.msk.su : That any beholder /Might fancy me dead - >http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. >RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 Cheers, -Peter From owner-freebsd-security Mon Jan 22 06:34:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA16321 for security-outgoing; Mon, 22 Jan 1996 06:34:09 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA16282 Mon, 22 Jan 1996 06:33:34 -0800 (PST) Received: by sovcom.kiae.su id AA07144 (5.65.kiae-1 ); Mon, 22 Jan 1996 17:17:17 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 22 Jan 96 17:17:16 +0300 Received: (from ache@localhost) by ache.dialup.ru (8.7.3/8.7.3) id QAA01830; Mon, 22 Jan 1996 16:57:59 +0300 (MSK) To: Peter Wemm Cc: ports@freebsd.org, security@freebsd.org References: <199601221259.UAA04035@jhome.DIALix.COM> In-Reply-To: <199601221259.UAA04035@jhome.DIALix.COM>; from Peter Wemm at Mon, 22 Jan 1996 20:59:21 +0800 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 22 Jan 1996 16:57:58 +0300 (MSK) X-Mailer: Mail/@ [v2.42 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: ssh /etc config files location.. Lines: 74 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk In message <199601221259.UAA04035@jhome.DIALix.COM> Peter Wemm writes: >I'm not complaining about this from a "security" point of view, I'm >complaining about this from a "functionality" point of view. Well, I accept this point of view. >I'm not worried so much about the config files, but I am worried about the >run-time data generated by sshd that is written to the etcdir, and I'm also >concerned about the critical public and private host keys. sshd_config and >ssh_config could stay in /usr/local/etc for all I care. :-) I remember, we plan to make /etc read-only, no runtime data should be written there, we need to choose another place, maybe /var/run.... So, I still disagree but the reason is different... >Exactly.. It "builds fine". It probes to see if the tools exist, and codes >in the exact pathnames if they are there, and puts in default pathnames >if they are not. It isn't acceptable for security tool, PREFIX can be != /usr/local in general case which can cause wrong version picked from /usr/local. So, I repeat my variant: >>In this case they need to be controlled >>via USE_* variables like other stuff in ssh Makefile. I.e. corresponding >>BUILD_DEPENDS must be ifdefed. >Why? If I dont have X11 installed on the target system (and NEVER will, >because it's a dialup box), and hence will not have wish, and ssh does not >need wish and will happily build without it, why should I be prevented >from building the non-X11 port? If you don't have X11, don't install ssh-askpass. If you install X11 - reinstall ssh port and setenv USE_WISH before. >As far as I can see, they are used like this: >if "wish" on $PATH > WISH=`location of wish` >else > WISH=/usr/local/bin/wish > echo "Wish not installed, ssh-askpass will not work." >fi >..... >echo "#! $WISH" > ssh-askpass >cat ssh-askpass.in >> ssh-askpass >If you build ssh and later install wish, the ssh-askpass will then work. >It's a runtime dependency, not a BUILD_DEPENDS. It isn't acceptable to guess path for security tools, path must be exact. Better way is reinstall ssh when additional soft will be available. The same words about perl5 & ssh-make-known-hosts, ether path must be known exactly or this script must not be installed. There is yet one problem related to this: building package (PLIST), it is unclear does it must have minimal ssh scripts set. >Hmm, I just re-ran the "make" to build the port. I can see that there >are a few things that "configure" has got wrong... >It should also use the system libgmp and the zlib port rather than >building it's own.... Ssh may depends of libgmp/zlib version used. Configure even not tries to find them in the system. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Mon Jan 22 08:14:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA23873 for security-outgoing; Mon, 22 Jan 1996 08:14:10 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA23863 for ; Mon, 22 Jan 1996 08:14:03 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA21985; Mon, 22 Jan 1996 09:15:10 -0700 Date: Mon, 22 Jan 1996 09:15:10 -0700 From: Nate Williams Message-Id: <199601221615.JAA21985@rocky.sri.MT.net> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) Cc: Peter Wemm , security@freebsd.org Subject: Re: ssh /etc config files location.. In-Reply-To: References: Sender: owner-security@freebsd.org Precedence: bulk KOI8-R writes: > In message > Peter Wemm writes: > > >I am still somewhat disturbed with the location of some rather critical > >"per site" info from ssh in /usr/local/etc.. Specifically the ssh host > >secret keys, and the per-site config files. > > >This is (IMHO) rather dangerous. If you NFS mount /usr/local, this will > >screw you rather badly. This bit me when I installed it on a Sun cluster. > >There are precedents against this too.. gated keeps it's config files in > >/etc. > > There are precedent _for_ this, tcp_wrapper uses /usr/local/etc. Actually, we patch tcp_wrapper to have it use /usr/local. It uses /etc files by default. > Using NFS for /usr/local/bin/{security_binaries} is big risk too > because they can be changes (like config files). Not on my systems, except by local folk who are trusted. The reasons for ssh are for outside attacks, and none of my NFS traffic goes over the wire. > I don't see the point to move security-related configs to /etc > and _not_ to move security binaries from /usr/local. Because not everyone has worries about NFS security. > So there is two normal solutions: > 1) Leave all as is in /usr/local, but not mount it over NFS > 2) Move configs & binaries _both_ off /usr/local. 3) Leave the binaries on /usr/local and move config onto somewhere that's not exported. > I disagree with proposed solution (moving configs only to /etc). I agree. > >PS: IMHO, it was a mistake adding the BUILD_DEPENDS in wish and perl5. it > >build's fine without them. It seems silly to require X11 to be installed > >in order to build the port.. > > It builds fine, but incomplete, namely: > > ssh-askpass needs wish > make-ssh-known-hosts needs perl5 Hmm, on all the machines I have built it on, I haven't use either one of these. What do they do? Nate From owner-freebsd-security Mon Jan 22 08:31:51 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA24605 for security-outgoing; Mon, 22 Jan 1996 08:31:51 -0800 (PST) Received: from nevis.oss.uswest.net (nevis.oss.uswest.net [204.147.85.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA24580 Mon, 22 Jan 1996 08:31:36 -0800 (PST) Received: (from greg@localhost) by nevis.oss.uswest.net (8.6.12/8.6.12) id KAA29506; Mon, 22 Jan 1996 10:31:01 -0600 From: "Greg Rowe" Message-Id: <9601221031.ZM29504@nevis.oss.uswest.net> Date: Mon, 22 Jan 1996 10:31:00 -0600 X-Mailer: Z-Mail (3.2.1 10oct95) To: freebsd-security@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Netscape & S/Key Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-security@FreeBSD.ORG Precedence: bulk I currently have a FreeBSD system that allows users to update/create their WEB pages via S/Key access to a virtual FTP server. I'm now looking at creating another similar system that allows a Netscape user to retrieve files based on a one time password. I currently use the Apache server. Since users would only access the server once to download updates, and I need to control the access, none of the HTTPD password utilities really apply. It's much nicer to just print out a list of one time passwords once and a while and not have to worry about managing databases. The virtual FTP seems to be out due to Netscape setting "annonymous" as the default login user. Has anyone tried to interface the Apache server to FreeBSD's S/Key login so that rather than use the htpassword routines it uses S/Key? Thanks, Greg Rowe -- Greg Rowe | U S West - Interact Services | INTERNET greg@uswest.net 111 Washington Ave. South | Fax: (612) 672-8537 Minneapolis, MN USA 55401 | Voice: (612) 672-8535 Never trust an operating system you don't have source for.... From owner-freebsd-security Mon Jan 22 09:06:04 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA27306 for security-outgoing; Mon, 22 Jan 1996 09:06:04 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA27291 for ; Mon, 22 Jan 1996 09:06:01 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id RAA21403 for ; Mon, 22 Jan 1996 17:04:05 GMT Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Mon, 22 Jan 1996 17:04:18 +0000 Received: (from dpr@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id RAA09129 for security@FreeBSD.org; Mon, 22 Jan 1996 17:04:16 GMT From: Paul Richards Message-Id: <199601221704.RAA09129@cadair.elsevier.co.uk> Subject: Re: ssh /etc config files location.. To: security@FreeBSD.org Date: Mon, 22 Jan 1996 17:04:16 +0000 (GMT) In-Reply-To: <199601221615.JAA21985@rocky.sri.MT.net> from "Nate Williams" at Jan 22, 96 09:15:10 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.org Precedence: bulk In reply to Nate Williams who said > > > I don't see the point to move security-related configs to /etc > > and _not_ to move security binaries from /usr/local. > > Because not everyone has worries about NFS security. I don't think the security issue is the main one anyway. Like you said, you either trust NFS or you simply don't use it and moving ssh files off /usr/local because it might use NFS from a security point of view is rather bogus. The fact that the ssh files are *host specific* is a far more important consideration. They should therefore be in a *genuinely* local part of the filesystem. > > I disagree with proposed solution (moving configs only to /etc). > > I agree. I disagree with /etc. These are not configuration files, they are runtime modifiable files and should go in /var. -- Paul Richards. Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-security Mon Jan 22 09:26:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA29137 for security-outgoing; Mon, 22 Jan 1996 09:26:54 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA29032 Mon, 22 Jan 1996 09:25:48 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id RAA21441; Mon, 22 Jan 1996 17:24:01 GMT Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Mon, 22 Jan 1996 17:24:11 +0000 Received: (from dpr@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id RAA09401; Mon, 22 Jan 1996 17:24:12 GMT From: Paul Richards Message-Id: <199601221724.RAA09401@cadair.elsevier.co.uk> Subject: Re: Netscape & S/Key To: greg@uswest.net (Greg Rowe) Date: Mon, 22 Jan 1996 17:24:12 +0000 (GMT) Cc: freebsd-security@FreeBSD.org, freebsd-isp@FreeBSD.org In-Reply-To: <9601221031.ZM29504@nevis.oss.uswest.net> from "Greg Rowe" at Jan 22, 96 10:31:00 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.org Precedence: bulk In reply to Greg Rowe who said > > The virtual FTP seems to be out due to Netscape setting "annonymous" as the > default login user. Has anyone tried to interface the Apache server to > FreeBSD's S/Key login so that rather than use the htpassword routines it uses > S/Key? You would be better off talking to the apache guys about this. Apache has a nice modular approach so you can replace the existing authentication with a module based on what you want fairly easily I think. Take a look at the Apache home page (apache.org) and find out how to contact them. I don't think the development list allows open mailing but the web pages should explain how to contact the group. -- Paul Richards. Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-security Mon Jan 22 09:49:30 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA01100 for security-outgoing; Mon, 22 Jan 1996 09:49:30 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA01092 for ; Mon, 22 Jan 1996 09:49:27 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id KAA22368; Mon, 22 Jan 1996 10:50:21 -0700 Date: Mon, 22 Jan 1996 10:50:21 -0700 From: Nate Williams Message-Id: <199601221750.KAA22368@rocky.sri.MT.net> To: Paul Richards Cc: security@FreeBSD.org Subject: Re: ssh /etc config files location.. In-Reply-To: <199601221704.RAA09129@cadair.elsevier.co.uk> References: <199601221615.JAA21985@rocky.sri.MT.net> <199601221704.RAA09129@cadair.elsevier.co.uk> Sender: owner-security@FreeBSD.org Precedence: bulk > The fact that the ssh files are *host specific* is a far more important > consideration. They should therefore be in a *genuinely* local part > of the filesystem. That's what I was trying to say. Basically, they ssh config files (most notably the keys) are host-specific, so they must exist in a host-specific portion of the disk. > > > I disagree with proposed solution (moving configs only to /etc). > > > > I agree. > > I disagree with /etc. These are not configuration files, they are > runtime modifiable files and should go in /var. Huh? They are most certainly configuration files. The public/private keys as well as ssh_config and sshd_config are not (any more so than any other config file ) runtime modifiable once they are initially installed, and once they are installed (as with any configuration file) they shouldn't be touched, unlike the files in /var/run. Now, sshd.pid is a file that should get stuck in /var/run, but I think we'd all agree on that move. Nate From owner-freebsd-security Mon Jan 22 10:24:14 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA03447 for security-outgoing; Mon, 22 Jan 1996 10:24:14 -0800 (PST) Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA03423 Mon, 22 Jan 1996 10:24:04 -0800 (PST) Received: from localhost.DIALix.oz.au (peter@localhost.DIALix.oz.au [127.0.0.1]) by jhome.DIALix.COM (8.7.3/8.7.3) with SMTP id CAA11303; Tue, 23 Jan 1996 02:21:23 +0800 (WST) Message-Id: <199601221821.CAA11303@jhome.DIALix.COM> X-Authentication-Warning: jhome.DIALix.COM: Host peter@localhost.DIALix.oz.au [127.0.0.1] didn't use HELO protocol To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: ports@freebsd.org, security@freebsd.org Subject: Re: ssh /etc config files location.. In-reply-to: Your message of "Mon, 22 Jan 1996 16:57:58 +0300." Date: Tue, 23 Jan 1996 02:21:22 +0800 From: Peter Wemm Sender: owner-security@freebsd.org Precedence: bulk >>I'm not worried so much about the config files, but I am worried about the >>run-time data generated by sshd that is written to the etcdir, and I'm also >>concerned about the critical public and private host keys. sshd_config and >>ssh_config could stay in /usr/local/etc for all I care. :-) > >I remember, we plan to make /etc read-only, no runtime data should >be written there, we need to choose another place, maybe /var/run.... >So, I still disagree but the reason is different... The /etc/ssh_host_key is the signature for the host itself. it's like the host's password for doing .rhosts authentication... If that file ever gets corrupted, or changed, it is a serious problem, because all the ssh programs that talk to your host have saved a copy of the public key, and if your host cannot prove it is the same machine, all the ssh's out there will scream "SECURITY ALERT" and refuse to authenticate because of potential "man in the middle" attacks. Those three files are vital to the correct functioning of ssh. You wouldn't put /etc/passwd and /etc/master.passwd in /var/run or /usr/local/etc. >>Exactly.. It "builds fine". It probes to see if the tools exist, and codes >>in the exact pathnames if they are there, and puts in default pathnames >>if they are not. > >It isn't acceptable for security tool, PREFIX can be != /usr/local >in general case which can cause wrong version picked from /usr/local. >So, I repeat my variant: The two programs in question (ssh-askpass and make-known-hosts) are not exactly security tools. They run without privilege. Incidently, ssh-1.2.12a.tar.gz is rather broken. In the announcement, it also said "ssh-askpass is currently broken"... Arguing about whether or not to install the broken tool is not exactly my idea of "productive". We should ignore it and not install it until it's fixed again. >>>In this case they need to be controlled >>>via USE_* variables like other stuff in ssh Makefile. I.e. corresponding >>>BUILD_DEPENDS must be ifdefed. > >>Why? If I dont have X11 installed on the target system (and NEVER will, >>because it's a dialup box), and hence will not have wish, and ssh does not >>need wish and will happily build without it, why should I be prevented >>from building the non-X11 port? > >If you don't have X11, don't install ssh-askpass. >If you install X11 - reinstall ssh port and setenv USE_WISH before. yes, but if you dont have X11, you currently CANNOT EVEN BUILD THE PORT. Also, if you have tcl74 and tk4 installed, you cannot build either because wish is installed as "wish4.0". This is not one of the files it probes for (it checks wish, wishx and wish4.1), and tcl74 / tcl and tk4 / tk are both mutually exclusive. Forcing the ssh build to be dependent on one of the two mutually exclusive packages is very bad. >>As far as I can see, they are used like this: >>if "wish" on $PATH >> WISH=`location of wish` >>else >> WISH=/usr/local/bin/wish >> echo "Wish not installed, ssh-askpass will not work." >>fi >>..... >>echo "#! $WISH" > ssh-askpass >>cat ssh-askpass.in >> ssh-askpass > >>If you build ssh and later install wish, the ssh-askpass will then work. >>It's a runtime dependency, not a BUILD_DEPENDS. > >It isn't acceptable to guess path for security tools, >path must be exact. Better way is reinstall ssh when additional >soft will be available. >The same words about perl5 & ssh-make-known-hosts, >ether path must be known exactly or this script must not be installed. ssh-askpass never used to be installed, until patch-ad. Since it's not working, it probably should not be installed for now. I would agree to not installing them if the run-time tools are missing, but I dont see how you can prevent ssh-askpass and make-known-hosts from being installed from a package if perl5/wish are missing. >There is yet one problem related to this: building package (PLIST), >it is unclear does it must have minimal ssh scripts set. Currently, there are no packages built for ssh for US-export stupidity. Satoshi once said something like this: "We can only build packages to assume standard locations of things. We can't take responsibility for not using default locations." What can you do? The odds are that the building machine has a complete system, with X11, tcl/tk/wish etc. If you build a package, it will have the complete kit, with hard coded paths in it, and a path to /usr/X11R6/bin/xauth. There's no guarantee that the machine that installs the package will have them in the same place, or even if it will have them. Requiring X11 and/or wish is not the answer there either, as it only makes everybody's life difficult. Also, since we are installing into /usr/local/bin and /usr/local/sbin, there is no more risk of having paths coded to /usr/local/bin/wish and /usr/local/bin/perl. If a hacker could place in a fake /usr/local/bin/wish, they could just as easily put in a fake /usr/local/bin/ssh and wait for you to run it. >>Hmm, I just re-ran the "make" to build the port. I can see that there >>are a few things that "configure" has got wrong... > >>It should also use the system libgmp and the zlib port rather than >>building it's own.... > >Ssh may depends of libgmp/zlib version used. Configure even >not tries to find them in the system. I spoke to the SSH author about this a few weeks ago. He said "send me working patches and I'll consider putting support for that in". I never got around to it... (I see that Mark has done the first part) >-- >Andrey A. Chernov : And I rest so composedly, /Now, in my bed, >ache@astral.msk.su : That any beholder /Might fancy me dead - >http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. >RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 BTW: ssh-1.2.12a is SERIOUSLY crippled. It is damaged in several ways as part of the "emergency patch", and still not secure because it installed /usr/local/bin/ssh setuid-root. It now creates files in your home directory while running as root, causing potential new holes and races. :-( Cheers, -Peter From owner-freebsd-security Mon Jan 22 10:32:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA04029 for security-outgoing; Mon, 22 Jan 1996 10:32:57 -0800 (PST) Received: from cyber1.cyberhall.com (cyber1.cyberhall.com [206.41.142.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA04017 for ; Mon, 22 Jan 1996 10:32:51 -0800 (PST) Received: (from dbrockus@localhost) by cyber1.cyberhall.com (8.6.11/8.6.9) id MAA00698; Mon, 22 Jan 1996 12:32:17 GMT Date: Mon, 22 Jan 1996 12:32:17 +0000 () From: David Brockus To: freebsd-security@freebsd.org Subject: Logging user activity Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk I am running FreeBSD 2.0.5R system. I believe there is a "hacked" account on the system I maintain. I would to extensively monitor this users activity. I want to log everything. Any there any suggestion on how to set this up or can anybody recommend any packages to do this? Thanks in advance. David Brockus From owner-freebsd-security Mon Jan 22 11:08:17 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA06444 for security-outgoing; Mon, 22 Jan 1996 11:08:17 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA06438 for ; Mon, 22 Jan 1996 11:08:12 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id TAA21569 for ; Mon, 22 Jan 1996 19:06:24 GMT Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Mon, 22 Jan 1996 19:06:35 +0000 Received: (from dpr@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id TAA09960; Mon, 22 Jan 1996 19:06:36 GMT From: Paul Richards Message-Id: <199601221906.TAA09960@cadair.elsevier.co.uk> Subject: Re: ssh /etc config files location.. To: nate@sri.MT.net (Nate Williams) Date: Mon, 22 Jan 1996 19:06:35 +0000 (GMT) Cc: security@FreeBSD.org In-Reply-To: <199601221750.KAA22368@rocky.sri.MT.net> from "Nate Williams" at Jan 22, 96 10:50:21 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.org Precedence: bulk In reply to Nate Williams who said > > > I disagree with /etc. These are not configuration files, they are > > runtime modifiable files and should go in /var. > > Huh? They are most certainly configuration files. The public/private > keys as well as ssh_config and sshd_config are not (any more so than any > other config file ) runtime modifiable once they are initially > installed, and once they are installed (as with any configuration file) > they shouldn't be touched, unlike the files in /var/run. Now, sshd.pid > is a file that should get stuck in /var/run, but I think we'd all agree > on that move. Oh, silly me. I was thinking of the .ssh files, like known_hosts. I I still don't like things touching /etc though. I don't see why we should make exceptions for ports that install into /usr/local if they happen to have host specific configurations, that's something that the local NFS admin should sort out. You'll have exactly the same problem if you administer diskless machines. Now, on a related note, how about replacing rsh with ssh in our main tree. It's backwards compatible and rsh needs to die anyway for all the same reasons that ssh exists in the first place. I tend to find most sites I'm at these days disable r* commands for security reasons anyway amd if rsh is a needed tool they install ssh instead. Having it come as default in FreeBSD would be yet another "feature" in FreeBSD's favour. -- Paul Richards. Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-security Mon Jan 22 11:26:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA07643 for security-outgoing; Mon, 22 Jan 1996 11:26:10 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA07635 for ; Mon, 22 Jan 1996 11:26:05 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA22649; Mon, 22 Jan 1996 12:27:22 -0700 Date: Mon, 22 Jan 1996 12:27:22 -0700 From: Nate Williams Message-Id: <199601221927.MAA22649@rocky.sri.MT.net> To: Paul Richards Cc: nate@sri.MT.net (Nate Williams), security@FreeBSD.org Subject: Re: ssh /etc config files location.. In-Reply-To: <199601221906.TAA09960@cadair.elsevier.co.uk> References: <199601221750.KAA22368@rocky.sri.MT.net> <199601221906.TAA09960@cadair.elsevier.co.uk> Sender: owner-security@FreeBSD.org Precedence: bulk > I > still don't like things touching /etc though. I don't see why we > should make exceptions for ports that install into /usr/local if they > happen to have host specific configurations, that's something that the > local NFS admin should sort out. You'll have exactly the same problem > if you administer diskless machines. Agreed. I don't see an easy answer to this, but the current system is unacceptable for hosts that share /usr/local. > Now, on a related note, how about replacing rsh with ssh in our main tree. > It's backwards compatible and rsh needs to die anyway for all the same > reasons that ssh exists in the first place. I'm not sure that bringing in another non-exportable piece of software is a good thing, even for all the benefits it brings. Nate From owner-freebsd-security Mon Jan 22 12:39:07 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA12084 for security-outgoing; Mon, 22 Jan 1996 12:39:07 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA12079 for ; Mon, 22 Jan 1996 12:39:04 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA27062; Mon, 22 Jan 1996 15:38:20 -0500 Date: Mon, 22 Jan 1996 15:38:20 -0500 From: "Garrett A. Wollman" Message-Id: <9601222038.AA27062@halloran-eldar.lcs.mit.edu> To: Nate Williams Cc: security@FreeBSD.org Subject: Re: ssh /etc config files location.. In-Reply-To: <199601221927.MAA22649@rocky.sri.MT.net> References: <199601221750.KAA22368@rocky.sri.MT.net> <199601221906.TAA09960@cadair.elsevier.co.uk> <199601221927.MAA22649@rocky.sri.MT.net> Sender: owner-security@FreeBSD.org Precedence: bulk < said: >> Now, on a related note, how about replacing rsh with ssh in our main tree. >> It's backwards compatible and rsh needs to die anyway for all the same >> reasons that ssh exists in the first place. > I'm not sure that bringing in another non-exportable piece of software > is a good thing, even for all the benefits it brings. It is a very bad thing, for Nate's reason and others. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-security Mon Jan 22 13:45:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA17288 for security-outgoing; Mon, 22 Jan 1996 13:45:34 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA17253 for ; Mon, 22 Jan 1996 13:45:13 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA23067; Mon, 22 Jan 1996 14:47:44 -0700 Date: Mon, 22 Jan 1996 14:47:44 -0700 From: Nate Williams Message-Id: <199601222147.OAA23067@rocky.sri.MT.net> To: Peter Wemm Cc: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) , security@freebsd.org Subject: Re: ssh /etc config files location.. In-Reply-To: <199601221821.CAA11303@jhome.DIALix.COM> References: <199601221821.CAA11303@jhome.DIALix.COM> Sender: owner-security@freebsd.org Precedence: bulk Peter Wemm writes: > BTW: ssh-1.2.12a is SERIOUSLY crippled. It is damaged in several ways > as part of the "emergency patch", and still not secure because it > installed /usr/local/bin/ssh setuid-root. It now creates files in > your home directory while running as root, causing potential new holes > and races. :-( For those of us who use ssh and don't keep on the security lists outside this one, can you explain what hold the 'emergency patch' is trying to fix, and if there is some way of working around it? Thanks! Nate From owner-freebsd-security Mon Jan 22 13:47:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA17510 for security-outgoing; Mon, 22 Jan 1996 13:47:55 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA17503 for ; Mon, 22 Jan 1996 13:47:53 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id NAA09887; Mon, 22 Jan 1996 13:47:41 -0800 From: Nathan Lawson Message-Id: <199601222147.NAA09887@statler.csc.calpoly.edu> Subject: Ownership of files/tcp_wrappers port To: security@freebsd.org Date: Mon, 22 Jan 1996 13:47:40 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk Hi there. Two issues that I have been considering. First, I don't mean to beat a dead horse, but I think this issue has never been adequately considered: less "bin" ownership of files and directories. The advantages of more root-owned directories and files are that root is usually mapped to nobody on NFS, so that would add a small amount of security for people who carelessly misuse NFS. Secondly, and more importantly, the root UID is treated much much differently than all other uids (including bin). Programs like "login" almost never allow root logins from remote. However, since bin is a normal user, it can log in from anywhere (yes, I know about login.access, but perhaps you should be putting bin in the "never log in" configuration then). What are the advantages of making files owned by bin? Well, it looks nice when you're doing an ls and you'd like to know if you're in a binaries directory or not. Are there any more? I really have not heard a convincing argument for bin ownership other than "too many files are owned by root". Remember that the Unix environment is bipolar: root and everyone else. Making files owned by bin does NOT provide multiple levels of security, it only puts them in the user domain (yes, again, bin should be protected, but there are nowhere near as many checks to protect the bin account as there are for root). I say to put all your eggs in the root basket and guard that basket very carefully. Secondly, I was wondering why the tcp_wrappers distribution didn't make it into the source tree instead of being a port. It's a pretty small program that hasn't received too many changes recently. It's very worthwhile and libwrap.a can be linked into portmap and ypserv a lot more easily (even making this the default, perhaps). I think it would be a good idea to move it into the main distribution and provide it with some sample, wide-open access rules (permit everything, but perhaps have some comments that indicate some sample rules). That way, a fresh FreeBSD install would have the option of adding access control just by editting /somedir-to-be-argued/hosts.{allow,deny}. People who didn't care about access control would not find it limiting because all services would be allowed (and logged). The only argument I can see against doing this is that clueless first-time users might screw up the allow files, and post tons of "TELNETD NOT WORKING" questions, but as long as the files are default permit-everything, they'd have to go out of their way to screw things up. I don't see the port as being hard to move into the source tree because Wietse uses FreeBSD as a development platform and the code is well-written. Also, you've already used his logdaemon and portmap code, so why not tcp_wrappers? Thanks for considering my suggestions and producing such a good product. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Mon Jan 22 14:07:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA19953 for security-outgoing; Mon, 22 Jan 1996 14:07:18 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA19945 for ; Mon, 22 Jan 1996 14:07:15 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.7.3) with SMTP id OAA06279; Mon, 22 Jan 1996 14:05:59 -0800 (PST) Message-Id: <199601222205.OAA06279@precipice.shockwave.com> To: David Brockus cc: freebsd-security@freebsd.org Subject: Re: Logging user activity In-reply-to: Your message of "Mon, 22 Jan 1996 12:32:17 GMT." Date: Mon, 22 Jan 1996 14:05:59 -0800 From: Paul Traina Sender: owner-security@freebsd.org Precedence: bulk You may want to compile in the snoop drivers and the watch program, which should be at least semi-functional in 2.0.5 (I don't recall when I made this stuff more robust). Other than that, I don't recall the state of accounting. Paul From: David Brockus Subject: Logging user activity I am running FreeBSD 2.0.5R system. I believe there is a "hacked" account on the system I maintain. I would to extensively monitor this users activity. I want to log everything. Any there any suggestion on how to set this up or can anybody recommend any packages to do this? Thanks in advance. David Brockus From owner-freebsd-security Mon Jan 22 14:41:25 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA23279 for security-outgoing; Mon, 22 Jan 1996 14:41:25 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA23274 for ; Mon, 22 Jan 1996 14:41:18 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id XAA04397 ; Mon, 22 Jan 1996 23:41:06 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id XAA15458 ; Mon, 22 Jan 1996 23:41:05 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id XAA05768; Mon, 22 Jan 1996 23:27:49 +0100 (MET) From: Ollivier Robert Message-Id: <199601222227.XAA05768@keltia.freenix.fr> Subject: Re: ssh /etc config files location.. To: p.richards@elsevier.co.uk (Paul Richards) Date: Mon, 22 Jan 1996 23:27:49 +0100 (MET) Cc: security@FreeBSD.org In-Reply-To: <199601221704.RAA09129@cadair.elsevier.co.uk> from "Paul Richards" at Jan 22, 96 05:04:16 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1586 X-Mailer: ELM [version 2.4ME+ PL0 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org Precedence: bulk It seems that Paul Richards said: > I disagree with /etc. These are not configuration files, they are > runtime modifiable files and should go in /var. When you take ssh out-of-the-box on a FreeBSD system, you'll have the following data at the following locations: 1. the ssh client and server configuration file are in /etc unless you have changed it with configure --with-etcdir. I use /etc/ssh personally to avoid cluttering /etc. I use /etc/mail for the same reasons. 2. the sshd.pid has been put in /var/run as many daemons. It used to be in $etcdir but I asked Tatu change it because it is more consistent with current BSD behaviour. 3. the host private and public are in $etcdir. I really think they should be on a local disk but it cannot be /var/run as it is whipped clean at reboot. 4. the ssh_random_seed file could eventually be in /var/run but it is better to maintain it between reboot. We have /dev/random so maybe it is less an issue... Putting everything in /usr/local is standard and a good thing but I feel that some things like ssh don't have to follow it. PS for those who are using the # Location of local startup files. local_startup=/etc/rc.d feature of sysconfig, here the script I use: sshd.sh ------------------------------------------------------------ #! /bin/sh SSHDIR=/etc/ssh PIDDIR=/var/run if [ X"$1" = Xstart ]; then if [ -f /usr/local/sbin/sshd -a -f $SSHDIR/sshd_config ]; then echo 'Starting sshd.' /usr/local/sbin/sshd fi fi if [ X"$1" = Xstop ]; then if [ -f $PIDDIR/sshd.pid ]; then echo 'Stopping sshd.' kill `cat $PIDDIR/sshd.pid` fi fi ------------------------------------------------------------ -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Sun Jan 14 20:23:45 MET 1996 From owner-freebsd-security Mon Jan 22 16:01:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA02092 for security-outgoing; Mon, 22 Jan 1996 16:01:20 -0800 (PST) Received: from fslg8.fsl.noaa.gov (fslg8.fsl.noaa.gov [137.75.131.171]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA02087 for ; Mon, 22 Jan 1996 16:01:15 -0800 (PST) Received: by fslg8.fsl.noaa.gov (5.57/Ultrix3.0-C) id AA20159; Mon, 22 Jan 96 18:01:07 -0600 Received: by emu.fsl.noaa.gov (1.38.193.4/SMI-4.1 (1.38.193.4)) id AA03547; Mon, 22 Jan 1996 17:01:05 -0700 Date: Mon, 22 Jan 1996 17:01:05 -0700 From: kelly@fsl.noaa.gov (Sean Kelly) Message-Id: <9601230001.AA03547@emu.fsl.noaa.gov> To: pst@shockwave.com Cc: dbrockus@cyberhall.com, freebsd-security@freebsd.org In-Reply-To: <199601222205.OAA06279@precipice.shockwave.com> (message from Paul Traina on Mon, 22 Jan 1996 14:05:59 -0800) Subject: Re: Logging user activity Sender: owner-security@freebsd.org Precedence: bulk >>>>> "Paul" == Paul Traina writes: Paul> You may want to compile in the snoop drivers and the watch Paul> program, which should be at least semi-functional in 2.0.5 Paul> (I don't recall when I made this stuff more robust). Other Paul> than that, I don't recall the state of accounting. I've been using accounting since 2.0 and have never encountered any problems---at least, none that I could link to accounting. I have great uptimes with 2.1 now and am still using it, so I'd go ahead and turn it on. It's another nice tool when you're not actively watch'ing. -- Sean Kelly NOAA Forecast Systems Laboratory, Boulder Colorado USA Isn't it funny how we'll look out the window at the moon, and then we notice it's not the moon but a streetlight? Also what's funny is how we do this every night. -- Deep Thoughts, by Jack Handey From owner-freebsd-security Mon Jan 22 16:37:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA04974 for security-outgoing; Mon, 22 Jan 1996 16:37:31 -0800 (PST) Received: from toadflax.cs.ucdavis.edu (toadflax.cs.ucdavis.edu [128.120.56.188]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA04948 Mon, 22 Jan 1996 16:37:26 -0800 (PST) Received: by toadflax.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA13736; Mon, 22 Jan 96 16:37:22 PST From: obrien@cs.ucdavis.edu (David E. O'Brien) Message-Id: <9601230037.AA13736@toadflax.cs.ucdavis.edu> Subject: Re: ssh /etc config files location.. To: ports@FreeBSD.ORG, security@FreeBSD.ORG Date: Mon, 22 Jan 1996 16:37:20 -0800 (PST) In-Reply-To: <199601221259.UAA04035@jhome.DIALix.COM> from "Peter Wemm" at Jan 22, 96 08:59:21 pm X-Mailer: ELM [version 2.4 PL24 ME8b] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG Precedence: bulk > >>I am still somewhat disturbed with the location of some rather critical > >>"per site" info from ssh in /usr/local/etc.. Specifically the ssh host > >>secret keys, and the per-site config files. > > > >>This is (IMHO) rather dangerous. If you NFS mount /usr/local, this will > >>screw you rather badly. > > > >>There are precedents against this too.. gated keeps it's config files in > >>/etc. > > > >There are precedent _for_ this, tcp_wrapper uses /usr/local/etc. Just because the tcp wrapper's porter picked this location doesn't make it correct. In fact from looking at hier(7), I'd say most ports abuse lib (where etc should be used) and man & etc (where share/* should be used). > True, but in the most likely case of having /usr/local shared (ie: a small > group of machines) tcp_wrapper configs are most likely to be the same > for all the hosts anyway. However, tcp_wrapper does not need to constantly Agreed, all most hosts w/in the same local net have the same tcp_wrappers setup. > write to any files in /usr/local/etc like sshd has been configured to do. If files are written suggests /var is the place for them then. > >Using NFS for /usr/local/bin/{security_binaries} is big risk too > >because they can be changes (like config files). > >I don't see the point to move security-related configs to /etc > >and _not_ to move security binaries from /usr/local. It's a pratical nature. On most my previous sites, we read-only NFS mounted most non-OS released files. Only admins had login's on the file servers. Mostly because of disk space and simple administrative reasons. I don't think you can agure that right or wrong, this is a typical practice. > I'm not worried so much about the config files, but I am worried about the > run-time data generated by sshd that is written to the etcdir, and I'm also > concerned about the critical public and private host keys. sshd_config and > ssh_config could stay in /usr/local/etc for all I care. :-) Agreed. -- David (obrien@cs.ucdavis.edu) From owner-freebsd-security Mon Jan 22 16:58:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA06990 for security-outgoing; Mon, 22 Jan 1996 16:58:18 -0800 (PST) Received: (from dima@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA06967 Mon, 22 Jan 1996 16:58:11 -0800 (PST) Message-Id: <199601230058.QAA06967@freefall.freebsd.org> Subject: Re: ssh /etc config files location.. To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 22 Jan 1996 16:58:10 -0800 (PST) Cc: peter@jhome.DIALix.COM, ports@FreeBSD.org, security@FreeBSD.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Jan 22, 96 01:13:02 pm From: dima@FreeBSD.org (Dima Ruban) X-Class: Fast Organization: HackerDome X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.org Precedence: bulk =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= writes: > > In message > Peter Wemm writes: > > >I am still somewhat disturbed with the location of some rather critical > >"per site" info from ssh in /usr/local/etc.. Specifically the ssh host > >secret keys, and the per-site config files. > > >This is (IMHO) rather dangerous. If you NFS mount /usr/local, this will > >screw you rather badly. > > >There are precedents against this too.. gated keeps it's config files in > >/etc. > > There are precedent _for_ this, tcp_wrapper uses /usr/local/etc. > > Using NFS for /usr/local/bin/{security_binaries} is big risk too > because they can be changes (like config files). > I don't see the point to move security-related configs to /etc > and _not_ to move security binaries from /usr/local. This is more complicated. Because sometimes you don't need to modify something to get in. I mean, for example with tcp_wrapper, you can try to break from trusted computer. And if someone knows, from which computer he should try, it will increase his chances. And finaly it will depend on security on this trusted computer, and not on yours. > So there is two normal solutions: > 1) Leave all as is in /usr/local, but not mount it over NFS > 2) Move configs & binaries _both_ off /usr/local. > > I disagree with proposed solution (moving configs only to /etc). That's what I'm doing on my machine, because I forced to export /usr/local/ to other computers. Even if I'm exporting 'em read-only. > >PS: IMHO, it was a mistake adding the BUILD_DEPENDS in wish and perl5. it > >build's fine without them. It seems silly to require X11 to be installed > >in order to build the port.. > > It builds fine, but incomplete, namely: > > ssh-askpass needs wish > make-ssh-known-hosts needs perl5 > > So here is two variants: > 1) They are essential, so BUILD_DEPENDS is essential too. > 2) They don't play big role. In this case they need to be controlled > via USE_* variables like other stuff in ssh Makefile. I.e. corresponding > BUILD_DEPENDS must be ifdefed. > > Removing BUILD_DEPENDS is bad in any case. > > -- > Andrey A. Chernov : And I rest so composedly, /Now, in my bed, > ache@astral.msk.su : That any beholder /Might fancy me dead - > http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. > RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 > -- dima From owner-freebsd-security Mon Jan 22 18:07:51 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA14325 for security-outgoing; Mon, 22 Jan 1996 18:07:51 -0800 (PST) Received: from multivac.orthanc.com (root@multivac.orthanc.com [206.12.238.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA14304 for ; Mon, 22 Jan 1996 18:07:36 -0800 (PST) Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7.3/8.7.3) with SMTP id SAA15978 for ; Mon, 22 Jan 1996 18:07:28 -0800 (PST) Message-Id: <199601230207.SAA15978@multivac.orthanc.com> X-Authentication-Warning: multivac.orthanc.com: Host lyndon@localhost didn't use HELO protocol From: Lyndon Nerenberg VE7TCP To: security@freebsd.org Subject: Re: ssh /etc config files location.. In-reply-to: Your message of "Mon, 22 Jan 1996 10:50:21 MST." <199601221750.KAA22368@rocky.sri.MT.net> Date: Mon, 22 Jan 1996 18:07:28 -0800 Sender: owner-security@freebsd.org Precedence: bulk Is /etc/master.passwd a configuration file or a runtime modifiable file? I think the distinction is that /var/foo files are dynamic-runtime whereas /etc files are configuration. Clear as mud? Yes. If something is missing from /etc, the box breaks. If it's missing from /var, it limps. There's no cut-and-dried distinction here. However I do agree that all SSH non-binaries do NOT belong under /usr. The shared-/usr precident is entrenched enough that this shouldn't be an issue. --lyndon From owner-freebsd-security Mon Jan 22 18:55:12 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA19586 for security-outgoing; Mon, 22 Jan 1996 18:55:12 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA19571 for ; Mon, 22 Jan 1996 18:55:05 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id NAA21521; Tue, 23 Jan 1996 13:32:55 +1030 From: Michael Smith Message-Id: <199601230302.NAA21521@genesis.atrad.adelaide.edu.au> Subject: Re: Logging user activity To: dbrockus@cyberhall.com (David Brockus) Date: Tue, 23 Jan 1996 13:32:54 +1030 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: from "David Brockus" at Jan 22, 96 12:32:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk David Brockus stands accused of saying: > > I am running FreeBSD 2.0.5R system. I believe there is a "hacked" > account on the system I maintain. I would to extensively monitor this > users activity. I want to log everything. Any there any suggestion on > how to set this up or can anybody recommend any packages to do this? A couple of things you can do; if their shell is one of the csh flavours, (most particularly tcsh) then you can set their history up (savehist in particular) controlled by readonly shell variables. Set the history length (first word in the 'savehist' variable) really high, say around the 10,000 mark. Then you can set the append-only flag on their .history file, and they're screwed. Bear in mind that this will immediately make them nervous. An alternative would be to use the process accounting stuff; look at 'ac' and 'accton' and 'lastcomm'. > David Brockus -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-security Mon Jan 22 19:11:24 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA20892 for security-outgoing; Mon, 22 Jan 1996 19:11:24 -0800 (PST) Received: from tulpi.interconnect.com.au (root@tulpi.interconnect.com.au [192.189.54.18]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA20771 for ; Mon, 22 Jan 1996 19:09:39 -0800 (PST) Received: (from ahill@localhost) by tulpi.interconnect.com.au id OAA02122 (8.6.11/IDA-1.6); Tue, 23 Jan 1996 14:08:22 +1100 Date: Tue, 23 Jan 1996 14:08:18 +1100 (EST) From: Anthony Hill To: David Brockus cc: freebsd-security@freebsd.org Subject: Re: Logging user activity In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk Anthony Hill ahill@connect.com.au On Mon, 22 Jan 1996, David Brockus wrote: > I am running FreeBSD 2.0.5R system. I believe there is a "hacked" > account on the system I maintain. I would to extensively monitor this > users activity. I want to log everything. Any there any suggestion on > how to set this up or can anybody recommend any packages to do this? > Thanks in advance. Not for 2.05, but 2.1 has the really evil/cool "watch", which lets you view/log EVERYTHING that goes through any other tty. You have to compile the "snoop" device into you kernel, then just type "watch 'tty'" ! You can even control the other guys tty. (Dont let the bad guys get hold of this one !) Anthony Hill From owner-freebsd-security Mon Jan 22 22:13:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA03409 for security-outgoing; Mon, 22 Jan 1996 22:13:41 -0800 (PST) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA03391 for ; Mon, 22 Jan 1996 22:13:28 -0800 (PST) Received: by haven.uniserve.com id <30754-3>; Mon, 22 Jan 1996 22:15:31 -0000 Date: Mon, 22 Jan 1996 22:15:28 -0800 (PST) From: Tom Samplonius To: Nathan Lawson cc: security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <199601222147.NAA09887@statler.csc.calpoly.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Mon, 22 Jan 1996, Nathan Lawson wrote: > Secondly, I was wondering why the tcp_wrappers distribution didn't make it > into the source tree instead of being a port. It's a pretty small program > that hasn't received too many changes recently. It's very worthwhile and > libwrap.a can be linked into portmap and ypserv a lot more easily (even > making this the default, perhaps). Personally, I've always considered xinetd to the be the superior solution to the access control problem, since it doesn't incur the extra overhead of a fork+exec for every connection. Tom From owner-freebsd-security Mon Jan 22 22:29:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA04435 for security-outgoing; Mon, 22 Jan 1996 22:29:16 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA04419 for ; Mon, 22 Jan 1996 22:28:49 -0800 (PST) Received: from localhost (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with SMTP id IAA25371; Tue, 23 Jan 1996 08:27:31 +0200 (SAT) Message-Id: <199601230627.IAA25371@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host mark@localhost [127.0.0.1] didn't use HELO protocol To: Nathan Lawson cc: security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port Date: Tue, 23 Jan 1996 08:27:30 +0200 From: Mark Murray Sender: owner-security@FreeBSD.ORG Precedence: bulk Nathan Lawson wrote: > Secondly, I was wondering why the tcp_wrappers distribution didn't make it > into the source tree instead of being a port. It's a pretty small program > that hasn't received too many changes recently. It's very worthwhile and > libwrap.a can be linked into portmap and ypserv a lot more easily (even > making this the default, perhaps). I think this is a damn fine idea. Seconded. Any ISP who does not have wrappers, and any user who does not consider their use when connecting to the 'net has a serious problem. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Mon Jan 22 23:31:44 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA10277 for security-outgoing; Mon, 22 Jan 1996 23:31:44 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA10267 for ; Mon, 22 Jan 1996 23:31:41 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id XAA10321; Mon, 22 Jan 1996 23:30:57 -0800 From: Nathan Lawson Message-Id: <199601230730.XAA10321@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: tom@uniserve.com (Tom Samplonius) Date: Mon, 22 Jan 1996 23:30:56 -0800 (PST) Cc: security@freebsd.org In-Reply-To: from "Tom Samplonius" at Jan 22, 96 10:15:28 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > On Mon, 22 Jan 1996, Nathan Lawson wrote: > > > Secondly, I was wondering why the tcp_wrappers distribution didn't make it > > into the source tree instead of being a port. It's a pretty small program > > that hasn't received too many changes recently. It's very worthwhile and > > libwrap.a can be linked into portmap and ypserv a lot more easily (even > > making this the default, perhaps). > > Personally, I've always considered xinetd to the be the superior > solution to the access control problem, since it doesn't incur the extra > overhead of a fork+exec for every connection. This is a good idea, but I'd still like the libwrap.a or an equivalent library to link ypserv and portmap against by default. I think xinetd is a bit too big and possibly buggy, whereas tcp_wrappers is a bit smaller, but requires some fork overhead. I'd _prefer_ to see tcp_wrappers in the standard dist, with xinetd as a port, but that is my opinion only. Let's not have this distract us from my main point, which is that some kind of access control (whether xinetd or tcp_wrappers) should be installed by default, with easy-to-uncomment rules there for those people that need to get access control done quickly. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Tue Jan 23 00:10:14 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA13535 for security-outgoing; Tue, 23 Jan 1996 00:10:14 -0800 (PST) Received: from fire.stf.org.sg (jseng@fire.stf.org.sg [137.132.19.134]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA13415 for ; Tue, 23 Jan 1996 00:09:13 -0800 (PST) Received: (from jseng@localhost) by fire.stf.org.sg (8.6.12/8.6.9) id QAA15948; Tue, 23 Jan 1996 16:08:07 +0800 Date: Tue, 23 Jan 1996 16:08:06 +0800 (SGT) From: James Seng To: Mark Murray cc: Nathan Lawson , security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <199601230627.IAA25371@grumble.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk On Tue, 23 Jan 1996, Mark Murray wrote: > I think this is a damn fine idea. Seconded. Any ISP who does not have > wrappers, and any user who does not consider their use when connecting > to the 'net has a serious problem. Pardon me, but i think otherwise. tcp_wrapper is a fine product. libwrap.a is good to use and could possibly go into the /usr/src/lib path. But tcp_wrapper as itself shouldnt come by default. There are a few reasons, mainly, there are a few ways which tcp_wrapper could be compile (-DPARANOID -DRFC931 etc) which all could affect the behavior of the system and performance. Some site which doesnt run identd might find it worthwhile to turn off reverse auth. Some site which runs machine behind firewall may not be even interested in tcpd. Just remember that it is a good security tools doesnt means everyone would be interested to use it, for some reasons. And there are too many varities of tcpd and i believe each site should customise tcpd to their need. Just some food for thoughts. -James Seng (jseng@stf.org.sg) From owner-freebsd-security Tue Jan 23 00:18:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA14050 for security-outgoing; Tue, 23 Jan 1996 00:18:21 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA14041 for ; Tue, 23 Jan 1996 00:18:13 -0800 (PST) Received: from localhost (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with SMTP id KAA00547; Tue, 23 Jan 1996 10:12:31 +0200 (SAT) Message-Id: <199601230812.KAA00547@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host mark@localhost [127.0.0.1] didn't use HELO protocol To: James Seng cc: Mark Murray , Nathan Lawson , security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port Date: Tue, 23 Jan 1996 10:12:30 +0200 From: Mark Murray Sender: owner-security@FreeBSD.ORG Precedence: bulk James Seng wrote: > On Tue, 23 Jan 1996, Mark Murray wrote: > > I think this is a damn fine idea. Seconded. Any ISP who does not have > > wrappers, and any user who does not consider their use when connecting > > to the 'net has a serious problem. > > Pardon me, but i think otherwise. > > tcp_wrapper is a fine product. libwrap.a is good to use and could > possibly go into the /usr/src/lib path. But tcp_wrapper as itself > shouldnt come by default. There are a few reasons, mainly, there are a > few ways which tcp_wrapper could be compile (-DPARANOID -DRFC931 etc) > which all could affect the behavior of the system and performance. Some > site which doesnt run identd might find it worthwhile to turn off reverse > auth. Some site which runs machine behind firewall may not be even > interested in tcpd. Just remember that it is a good security tools doesnt > means everyone would be interested to use it, for some reasons. And > there are too many varities of tcpd and i believe each site should > customise tcpd to their need. If you go through all the utils in FreeBSD, you will find _many_ that are seldom if ever used by some individuals. This does not mean they should not be there. TCP wrappers are ubiquitous enough IMO for them to be included. Many of our utilities have different ways they can be compiled. The trick is to choose the most general one, and fix the code if necessary. (I would quite like to see identd in there as well, but at a _MUCH_ lower priority.) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Tue Jan 23 00:42:19 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA15576 for security-outgoing; Tue, 23 Jan 1996 00:42:19 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA15571 for ; Tue, 23 Jan 1996 00:42:15 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.7.3) with SMTP id AAA02300; Tue, 23 Jan 1996 00:40:54 -0800 (PST) Message-Id: <199601230840.AAA02300@precipice.shockwave.com> To: Tom Samplonius cc: Nathan Lawson , security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Mon, 22 Jan 1996 22:15:28 PST." Date: Tue, 23 Jan 1996 00:40:54 -0800 From: Paul Traina Sender: owner-security@freebsd.org Precedence: bulk Not every piece of software out there that people deem worthwhile BELONGS as part of the base system. Most people couldn't give a darn about the logging or wrapping that either xinetd or tcp-wrappers perform, both programs are welcome as ports, but not welcome as part of the core system, thankyouverymuch. We have PORTS for a reason, they're easy to install, what more can you ask for? From: Tom Samplonius Subject: Re: Ownership of files/tcp_wrappers port On Mon, 22 Jan 1996, Nathan Lawson wrote: > Secondly, I was wondering why the tcp_wrappers distribution didn't make it > into the source tree instead of being a port. It's a pretty small program > that hasn't received too many changes recently. It's very worthwhile and > libwrap.a can be linked into portmap and ypserv a lot more easily (even > making this the default, perhaps). Personally, I've always considered xinetd to the be the superior solution to the access control problem, since it doesn't incur the extra overhead of a fork+exec for every connection. Tom From owner-freebsd-security Tue Jan 23 00:45:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA15730 for security-outgoing; Tue, 23 Jan 1996 00:45:01 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA15719 for ; Tue, 23 Jan 1996 00:44:58 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.7.3) with SMTP id AAA02318; Tue, 23 Jan 1996 00:43:11 -0800 (PST) Message-Id: <199601230843.AAA02318@precipice.shockwave.com> To: Mark Murray cc: Nathan Lawson , security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Tue, 23 Jan 1996 08:27:30 +0200." <199601230627.IAA25371@grumble.grondar.za> Date: Tue, 23 Jan 1996 00:43:11 -0800 From: Paul Traina Sender: owner-security@FreeBSD.ORG Precedence: bulk From: Mark Murray Subject: Re: Ownership of files/tcp_wrappers port Nathan Lawson wrote: > Secondly, I was wondering why the tcp_wrappers distribution didn't make it > into the source tree instead of being a port. It's a pretty small program > that hasn't received too many changes recently. It's very worthwhile and > libwrap.a can be linked into portmap and ypserv a lot more easily (even > making this the default, perhaps). I think this is a damn fine idea. Seconded. Any ISP who does not have wrappers, and any user who does not consider their use when connecting to the 'net has a serious problem. I totally and completely disagree. I do not want to be bound by your idea of what's proper for the core part of the system. That's why we have a generic source distribution and you can personalize your system to your hearts content. Read: I will wish seriously bad karma on anyone who unilaterally bloats out the system with the wrapper code. There is NO good reason to make it anything other than a port -- which makes it OPTIONAL to install and easy to track 3rd party changes. From owner-freebsd-security Tue Jan 23 00:49:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA16005 for security-outgoing; Tue, 23 Jan 1996 00:49:46 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA15779 for ; Tue, 23 Jan 1996 00:45:44 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id JAA10249 ; Tue, 23 Jan 1996 09:44:31 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id JAA17646 ; Tue, 23 Jan 1996 09:44:31 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id JAA06930; Tue, 23 Jan 1996 09:42:35 +0100 (MET) From: Ollivier Robert Message-Id: <199601230842.JAA06930@keltia.freenix.fr> Subject: Re: Ownership of files/tcp_wrappers port To: nlawson@statler.csc.calpoly.edu (Nathan Lawson) Date: Tue, 23 Jan 1996 09:42:35 +0100 (MET) Cc: security@FreeBSD.org In-Reply-To: <199601222147.NAA09887@statler.csc.calpoly.edu> from "Nathan Lawson" at Jan 22, 96 01:47:40 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1586 X-Mailer: ELM [version 2.4ME+ PL0 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org Precedence: bulk It seems that Nathan Lawson said: > First, I don't mean to beat a dead horse, but I think this issue has never > been adequately considered: less "bin" ownership of files and directories. > The advantages of more root-owned directories and files are that root is I already tried to change the ownership long ago, even with a patch but I was told it was the traditional BSD way so I changed it on my box. Another reason is that it is usually more difficult to break into root than into another user so ownership by root should prevent most modifications of the system binaries. > Secondly, I was wondering why the tcp_wrappers distribution didn't make it > into the source tree instead of being a port. It's a pretty small program > that hasn't received too many changes recently. It's very worthwhile and > libwrap.a can be linked into portmap and ypserv a lot more easily (even > making this the default, perhaps). That would be nice too. Many Linux dists ship the system with TCP_Wrapper installed. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Sun Jan 14 20:23:45 MET 1996 From owner-freebsd-security Tue Jan 23 00:51:02 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA16188 for security-outgoing; Tue, 23 Jan 1996 00:51:02 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA16175 for ; Tue, 23 Jan 1996 00:50:49 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id JAA10245 ; Tue, 23 Jan 1996 09:44:30 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id JAA17643 ; Tue, 23 Jan 1996 09:44:30 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id JAA06916; Tue, 23 Jan 1996 09:38:04 +0100 (MET) From: Ollivier Robert Message-Id: <199601230838.JAA06916@keltia.freenix.fr> Subject: Re: ssh /etc config files location.. To: nate@sri.MT.net (Nate Williams) Date: Tue, 23 Jan 1996 09:38:04 +0100 (MET) Cc: peter@jhome.DIALix.COM, ache@astral.msk.su, security@FreeBSD.org In-Reply-To: <199601222147.OAA23067@rocky.sri.MT.net> from "Nate Williams" at Jan 22, 96 02:47:44 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1586 X-Mailer: ELM [version 2.4ME+ PL0 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org Precedence: bulk It seems that Nate Williams said: > For those of us who use ssh and don't keep on the security lists outside > this one, can you explain what hold the 'emergency patch' is trying to > fix, and if there is some way of working around it? The discussion is probably too long to send by mail but you can get all of it by WWW at http://www.cs.hut.fi/ssh/ssh-archive or http://www.cs.hut.fi/ssh/archive I don't remember which but there is a link in http://www.cs.hut.fi/ssh/ -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Sun Jan 14 20:23:45 MET 1996 From owner-freebsd-security Tue Jan 23 01:07:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA17221 for security-outgoing; Tue, 23 Jan 1996 01:07:09 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA17204 for ; Tue, 23 Jan 1996 01:07:01 -0800 (PST) Received: from localhost (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with SMTP id LAA00703; Tue, 23 Jan 1996 11:05:19 +0200 (SAT) Message-Id: <199601230905.LAA00703@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host mark@localhost [127.0.0.1] didn't use HELO protocol To: Paul Traina cc: Mark Murray , Nathan Lawson , security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port Date: Tue, 23 Jan 1996 11:05:19 +0200 From: Mark Murray Sender: owner-security@FreeBSD.ORG Precedence: bulk Paul Traina wrote: > I think this is a damn fine idea. Seconded. Any ISP who does not have > wrappers, and any user who does not consider their use when connecting > to the 'net has a serious problem. > > I totally and completely disagree. I do not want to be bound by your > idea of what's proper for the core part of the system. That's why we > have a generic source distribution and you can personalize your system > to your hearts content. Errrm, I am not trying to bind anyone. I am putting in a strong vote. As a net engineer for an ISP, I have seen enough cracking attempts in my life to believe that some form of protection is necessary. IMVHO this is no more bloat that shadow passwords (or our equivalent). Before my current job I worked in a University's computer centre, and _every_ Un*x box I ever got to work on had wrappers installed. I thus formed the opinion that most (wise) folks install them immediately, and such folks would appreciate having them as part of the base system. (I say this also as an anti-bloatist - my record speaks for itself.) > Read: I will wish seriously bad karma on anyone who unilaterally bloats > out the system with the wrapper code. There is NO good reason to > make it anything other than a port -- which makes it OPTIONAL to > install and easy to track 3rd party changes. Who said anything about unilateral? What is the difference between wrappers, bootp and the various eBones bits that got brought in with hardly a squeak? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Tue Jan 23 01:59:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA21905 for security-outgoing; Tue, 23 Jan 1996 01:59:52 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA21894 for ; Tue, 23 Jan 1996 01:59:49 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.7.3) with SMTP id BAA03233; Tue, 23 Jan 1996 01:58:03 -0800 (PST) Message-Id: <199601230958.BAA03233@precipice.shockwave.com> To: Mark Murray cc: Nathan Lawson , security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Tue, 23 Jan 1996 11:05:19 +0200." <199601230905.LAA00703@grumble.grondar.za> Date: Tue, 23 Jan 1996 01:58:03 -0800 From: Paul Traina Sender: owner-security@FreeBSD.ORG Precedence: bulk From: Mark Murray Subject: Re: Ownership of files/tcp_wrappers port Before my current job I worked in a University's computer centre, and _every_ Un*x box I ever got to work on had wrappers installed. And the organization that I work in uses a firewall because the systems are maintained by over 200 separate people who have varrying degrees of capability as system administrators. I thus formed the opinion that most (wise) folks install them immediately, and such folks would appreciate having them as part of the base system. (I say this also as an anti-bloatist - my record speaks for itself.) > Read: I will wish seriously bad karma on anyone who unilaterally bloats > out the system with the wrapper code. There is NO good reason to > make it anything other than a port -- which makes it OPTIONAL to > install and easy to track 3rd party changes. Who said anything about unilateral? What is the difference between wrappers, bootp and the various eBones bits that got brought in with hardly a squeak? If it was my call, they'd be ports too! I spent over 3 hours today futzing around checking all of the different changes from NetBSD and from the distribution code to insure that we got the right lineage of code and all of the bug fixes and insure they ended up on the right branches. All of this just as a precursor to adding DHCP support. Likewise, with eBones, we've hacked the sources to the point that its now a HUGE job to upgrade to patch level 10. I know this, because I started it and gave up in disgust 2 months ago. Both of your examples dove-tail perfectly with my point: You say why not? I say why? We have to find a better way to maintain software than bring it into the source distribution. It just becomes a bitch to maintain. eBones is one of the few hunks of code that is easy to dyke out of the rest of the distribution, and look at the effort we have to go to do it? A totally separate heirarchy and kludges in all of the system makefiles. Let me state, completely, my objections to adding the tcp wrapper code: (a) there are several similar competing bits of code out there that do similar things -- wrappers is not the only way to go (b) it's already trivial for a user to add this support into the base system should they desire it (c) incorporating it into the base system means more work to support, test, debug, and maintain the code (d) the wrapper changes duplicate much of the access logging and control we have already included directly in the system (e) they don't cover the case of UDP programs If you can address these issues, then I will withdraw my objections. Paul From owner-freebsd-security Tue Jan 23 02:06:40 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA22583 for security-outgoing; Tue, 23 Jan 1996 02:06:40 -0800 (PST) Received: from silver.sms.fi (silver.sms.fi [194.111.122.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA22564 for ; Tue, 23 Jan 1996 02:06:31 -0800 (PST) Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id MAA17990; Tue, 23 Jan 1996 12:04:45 +0200 Date: Tue, 23 Jan 1996 12:04:45 +0200 Message-Id: <199601231004.MAA17990@silver.sms.fi> From: Petri Helenius To: Paul Traina Cc: Mark Murray , Nathan Lawson , security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <199601230843.AAA02318@precipice.shockwave.com> References: <199601230627.IAA25371@grumble.grondar.za> <199601230843.AAA02318@precipice.shockwave.com> Sender: owner-security@freebsd.org Precedence: bulk Paul Traina writes: > > I totally and completely disagree. I do not want to be bound by your > idea of what's proper for the core part of the system. That's why we > have a generic source distribution and you can personalize your system > to your hearts content. > > Read: I will wish seriously bad karma on anyone who unilaterally bloats > out the system with the wrapper code. There is NO good reason to > make it anything other than a port -- which makes it OPTIONAL to > install and easy to track 3rd party changes. I couldn't agree more. Many places do have adequate firewalling procedures already in place and wrappers would do only more administrative overhead with no additional security. Pete From owner-freebsd-security Tue Jan 23 02:23:36 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA23972 for security-outgoing; Tue, 23 Jan 1996 02:23:36 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA23928 for ; Tue, 23 Jan 1996 02:23:23 -0800 (PST) Received: from localhost (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with SMTP id MAA01048; Tue, 23 Jan 1996 12:21:39 +0200 (SAT) Message-Id: <199601231021.MAA01048@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host mark@localhost [127.0.0.1] didn't use HELO protocol To: Paul Traina cc: Mark Murray , Nathan Lawson , security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port Date: Tue, 23 Jan 1996 12:21:39 +0200 From: Mark Murray Sender: owner-security@FreeBSD.ORG Precedence: bulk Paul Traina wrote: > Likewise, with eBones, we've hacked the sources to the point that its now a > HUGE job to upgrade to patch level 10. I know this, because I started it > and gave up in disgust 2 months ago. Please send me the patches, and I'll do it. I have some leave right now. > Let me state, completely, my objections to adding the tcp wrapper code: > > (a) there are several similar competing bits of code out there > that do similar things -- wrappers is not the only way to go None of them in regular use, and none as well-trusted (ubiquitous) as tcp_wrappers. None even in ports. > (b) it's already trivial for a user to add this support into the > base system should they desire it Sorta. I have seen some badly fouled up inetd.conf's with either total lossage (didn't work after being maimed) or massive security holes from misunderstanding. This is really a doumentation problem. we need a wrappers/general security section in the handbook. > (c) incorporating it into the base system means more work to support, > test, debug, and maintain the code Has to happen in ports anyway? Ok - not to tha same degree, and I would fiercly agree with you if the software under consideration was undergoing rapid development A-La NCFTP-2 or Lynx. The small size of this software is attractive, and its stability means it does not change often enough to be a PITA. > (d) the wrapper changes duplicate much of the access logging and > control we have already included directly in the system They also focus the same, usually in better detail. In fact wrappers are a _great_ source of logging information, and configurable from one place, too. In our last two breakins, wrapper logs nailed the culprit, and wrapper logs are great if your legacy system does not have decent accounting. One-file control of TCP access is darn useful. > (e) they don't cover the case of UDP programs True. > If you can address these issues, then I will withdraw my objections. 80%? ;-) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Tue Jan 23 02:37:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA25811 for security-outgoing; Tue, 23 Jan 1996 02:37:45 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA25802 for ; Tue, 23 Jan 1996 02:37:41 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.7.3) with SMTP id CAA03803; Tue, 23 Jan 1996 02:35:50 -0800 (PST) Message-Id: <199601231035.CAA03803@precipice.shockwave.com> To: Mark Murray cc: Nathan Lawson , security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Tue, 23 Jan 1996 12:21:39 +0200." <199601231021.MAA01048@grumble.grondar.za> Date: Tue, 23 Jan 1996 02:35:49 -0800 From: Paul Traina Sender: owner-security@FreeBSD.ORG Precedence: bulk From: Mark Murray Subject: Re: Ownership of files/tcp_wrappers port Paul Traina wrote: > Likewise, with eBones, we've hacked the sources to the point that its now a > HUGE job to upgrade to patch level 10. I know this, because I started it > and gave up in disgust 2 months ago. Please send me the patches, and I'll do it. I have some leave right now. They're gone...sorry, I shit-canned eBones/kerberos here in favor of ssh. You'll have to gen a copy of the patches by hand by using a copy of the pl9 and pl10 distributions, since ted never posted patches (you might ask him if he has done so since, tytso@mit.edu). > Let me state, completely, my objections to adding the tcp wrapper code: > > (a) there are several similar competing bits of code out there > that do similar things -- wrappers is not the only way to go None of them in regular use, and none as well-trusted (ubiquitous) as tcp_wrappers. None even in ports. Oh that's not true, xinetd is in regular use, but for the sake of an arguement, I'll give you 1/2 credit. > (b) it's already trivial for a user to add this support into the > base system should they desire it Sorta. I have seen some badly fouled up inetd.conf's with either total lossage (didn't work after being maimed) or massive security holes from misunderstanding. This is really a doumentation problem. we need a wrappers/general security section in the handbook. Either you're going to edit our /etc/inetd.conf to enable this stuff by default or you're going to document it. Which is it Mark? If the earlier, then you're going to screw people who don't want it to behave the way you set it up, and if the later, how is this different than documenting it properly in the handbook and pointing them at the port? > (c) incorporating it into the base system means more work to support, > test, debug, and maintain the code Has to happen in ports anyway? Ok - not to tha same degree, and I would fiercly agree with you if the software under consideration was undergoing rapid development A-La NCFTP-2 or Lynx. The small size of this software is attractive, and its stability means it does not change often enough to be a PITA. OK, so you're going to sign up to do this for the life of FreeBSD, thank you for volenteering, now given the average lifetime of contributing developers, that means we have support for ~2 years. Humm. > (d) the wrapper changes duplicate much of the access logging and > control we have already included directly in the system They also focus the same, usually in better detail. In fact wrappers are a _great_ source of logging information, and configurable from one place, too. In our last two breakins, wrapper logs nailed the culprit, and wrapper logs are great if your legacy system does not have decent accounting. One-file control of TCP access is darn useful. Great, then use them! I have no objection to you using the wrapper port on your system, I think it's a fantastic idea if you like them. As far as better detail, I certainly beg to differ. The logging that ftpd, finger, login, and friends do is far better because they have access to the application layer information that tcpd is not privy to. tcpd can only log connection attempts. Don't get me wrong, tcpd is GREAT when you have a binary only system like that garbage the "professional" unix vendors sell (harumph), but it doesn't hold a candle to real logging. > (e) they don't cover the case of UDP programs True. > If you can address these issues, then I will withdraw my objections. 80%? ;-) 15% :-) Let's separate the issue here, perhaps we can come to some sort of compromise. I would have little if any objection to putting optional calls to libwrap into our existing code in the same fashion we do stuff with with other optional parts of the system. In other words, if you wanted to add access control checking to YP or NFSD, and you put in conditional code that is only invoked if /usr/local/lib/libwrap.a is present, I won't barf all over my feet. Reasonable compromise? From owner-freebsd-security Tue Jan 23 03:20:15 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA01448 for security-outgoing; Tue, 23 Jan 1996 03:20:15 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA01409 for ; Tue, 23 Jan 1996 03:20:07 -0800 (PST) Received: from localhost (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with SMTP id NAA01191; Tue, 23 Jan 1996 13:19:26 +0200 (SAT) Message-Id: <199601231119.NAA01191@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host mark@localhost [127.0.0.1] didn't use HELO protocol To: Paul Traina cc: security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port Date: Tue, 23 Jan 1996 13:19:26 +0200 From: Mark Murray Sender: owner-security@FreeBSD.ORG Precedence: bulk Paul Traina wrote: > They're gone...sorry, I shit-canned eBones/kerberos here in favor of ssh. > You'll have to gen a copy of the patches by hand by using a copy of the pl9 > and pl10 distributions, since ted never posted patches (you might ask him > if he has done so since, tytso@mit.edu). Will do. Ta. > Let's separate the issue here, perhaps we can come to some sort of > compromise. I would have little if any objection to putting optional > calls to libwrap into our existing code in the same fashion we do stuff > with with other optional parts of the system. In other words, if you > wanted to add access control checking to YP or NFSD, and you put in > conditional code that is only invoked if /usr/local/lib/libwrap.a is > present, I won't barf all over my feet. You mean put something like .if (wrappers_lib_exists_in_local) SUPPORT_WRAPPERS = yes .endif in the appropriate Makefiles? > Reasonable compromise? Yup. (And they said the art of negotiation was dead!) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Tue Jan 23 03:35:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA03324 for security-outgoing; Tue, 23 Jan 1996 03:35:21 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA03310 for ; Tue, 23 Jan 1996 03:35:17 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.7.3) with SMTP id DAA00324; Tue, 23 Jan 1996 03:33:53 -0800 (PST) Message-Id: <199601231133.DAA00324@precipice.shockwave.com> To: Mark Murray cc: security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Tue, 23 Jan 1996 13:19:26 +0200." <199601231119.NAA01191@grumble.grondar.za> Date: Tue, 23 Jan 1996 03:33:53 -0800 From: Paul Traina Sender: owner-security@FreeBSD.ORG Precedence: bulk From: Mark Murray Subject: Re: Ownership of files/tcp_wrappers port You mean put something like .if (wrappers_lib_exists_in_local) SUPPORT_WRAPPERS = yes .endif Probably something like .if (/usr/local/lib/libwrap.a) and !defined(NO_WRAPPERS) so that distribution binaries can still be built (use whatever the convention is that we do elsewhere and document the root makefile). in the appropriate Makefiles? > Reasonable compromise? Yup. (And they said the art of negotiation was dead!) :-) Glad to be of service. From owner-freebsd-security Tue Jan 23 05:44:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA17868 for security-outgoing; Tue, 23 Jan 1996 05:44:55 -0800 (PST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA17853 Tue, 23 Jan 1996 05:44:45 -0800 (PST) Received: from uucp2.UU.NET by relay5.UU.NET with SMTP id QQzztm01108; Tue, 23 Jan 1996 08:44:38 -0500 (EST) Received: from uanet.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Tue, 23 Jan 1996 08:44:39 -0500 Received: by crocodil.monolit.kiev.ua; Tue, 23 Jan 96 15:42:18 +0200 Received: (from dk@localhost) by dog.farm.org (8.6.11/dk#3) id OAA00822; Tue, 23 Jan 1996 14:46:11 +0200 Date: Tue, 23 Jan 1996 14:46:11 +0200 From: Dmitry Kohmanyuk Message-Id: <199601231246.OAA00822@dog.farm.org> To: nate@sri.MT.net (Nate Williams) Cc: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ssh /etc config files location.. Newsgroups: cs-monolit.gated.lists.freebsd.security Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-security@freebsd.org Precedence: bulk In article you wrote: > > still don't like things touching /etc though. I don't see why we > > should make exceptions for ports that install into /usr/local if they > > happen to have host specific configurations, that's something that the > > local NFS admin should sort out. You'll have exactly the same problem > > if you administer diskless machines. > Agreed. I don't see an easy answer to this, but the current system is > unacceptable for hosts that share /usr/local. oh guys, but we can just make a symlink! NFS mount your /usr/local and just have /usr/local/etc pointing to /etc/local. It's just so plain easy. (or make a /usr/local/etc/ssh -> /etc/ssh if ssh uses a directory for its config files). Maybe this should become a policy?? Hmm, somebody should now argue that security problem with NFS spoofing remains. Yes. But having setuid root binaries in /usr/local is not more dangerous anyway. I have read Linux's FSSTND document (available from tsx-11.mit.edu in /pub/linux/docs/linux-standards/fsstnd), and these guys seems to do it right. (i.e., _all_ host-dependend stuff is not under /usr). On my system, I have /var/links and /usr/X11/bin/X -> /var/links/X11/X which in turn points back to /usr/X11/bin/XF86_ also, /usr/share/man/cat* should _NOT_ reside in /usr, but rather in /var/man (or /var/catman??) Since it now seems to move from -security topic, I cross-post it to -hackers. -- "C makes it easy to shoot yourself in the foot, C++ makes it harder, but when you do, it blows away your whole leg" -- Bjarne Stroustrup From owner-freebsd-security Tue Jan 23 05:44:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA17873 for security-outgoing; Tue, 23 Jan 1996 05:44:56 -0800 (PST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA17852 for ; Tue, 23 Jan 1996 05:44:45 -0800 (PST) Received: from uucp2.UU.NET by relay5.UU.NET with SMTP id QQzztm01087; Tue, 23 Jan 1996 08:44:35 -0500 (EST) Received: from uanet.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Tue, 23 Jan 1996 08:44:35 -0500 Received: by crocodil.monolit.kiev.ua; Tue, 23 Jan 96 15:42:23 +0200 Received: (from dk@localhost) by dog.farm.org (8.6.11/dk#3) id PAA00906; Tue, 23 Jan 1996 15:00:56 +0200 From: Dmitry Kohmanyuk Message-Id: <199601231300.PAA00906@dog.farm.org> Subject: rxvt security hole - proposed fix + more To: freebsd-security@freebsd.org Date: Tue, 23 Jan 1996 13:00:56 +0000 () Reply-To: dk+@ua.net X-Class: Fast X-OS-Of-Choice: FreeBSD 2.0.5-RELEASE X-NIC-Handle: DK379 X-Mailer: ELM [version 2.4 PL22 dk9] Content-Type: text Sender: owner-security@freebsd.org Precedence: bulk since now everybody probably knows about it, I wouldn't explain (just go to linux.announce ;-)) What I have done on my system is make rxvt setgid tty instead of suid root and make /var/run/wtmp and /var/log/wtmp group-writeable tty. This also requires modifying /etc/rc: (cd /var/run && { rm -rf -- *; cp /dev/null utmp; chgrp tty utmp; chmod 664 utmp; }) and adding this line /etc/monthly: chgrp tty wtmp; chmod g+w wtmp If you think that tty is a wrong group for user accounting files, it can be changed to some other one. in my 2.0.5 system, only these programs are setgid tty: /usr/bin/wall /usr/bin/write /sbin/dump /sbin/rdump /sbin/restore /sbin/rrestore (not including screen and rxvt, which I have made setgid tty by hand instead of setuid root). And yes I know rxvt have to be fixed to drop its privileges when using -print-pipe anyway. From owner-freebsd-security Tue Jan 23 09:14:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA03023 for security-outgoing; Tue, 23 Jan 1996 09:14:48 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA03017 for ; Tue, 23 Jan 1996 09:14:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.3/8.6.10) with SMTP id JAA08922; Tue, 23 Jan 1996 09:12:45 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199601231712.JAA08922@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Mark Murray cc: Nathan Lawson , security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Tue, 23 Jan 96 08:27:30 +0200." <199601230627.IAA25371@grumble.grondar.za> Date: Tue, 23 Jan 96 09:12:45 -0800 X-Mts: smtp Sender: owner-security@FreeBSD.ORG Precedence: bulk Mark Murray wrote: > Nathan Lawson wrote: > > Secondly, I was wondering why the tcp_wrappers distribution didn't make it > > into the source tree instead of being a port. It's a pretty small program > > that hasn't received too many changes recently. It's very worthwhile and > > libwrap.a can be linked into portmap and ypserv a lot more easily (even > > making this the default, perhaps). > > I think this is a damn fine idea. Seconded. Any ISP who does not have > wrappers, and any user who does not consider their use when connecting > to the 'net has a serious problem. TCP/Wrapper only partially addresses the problem since it only protects TCP services run out of INETD. Many attackers go through Sendmail, while others probe portmapper. The IP firewall code is already there in the kernel. It doesn't really take much to configure it, even for services that pick random port numbers such as NFS and YP. For example, any time I dial into work or my friend's ISP service I automatically activate the IPFW code in the kernel to protect any services not covered by the TCP/Wrapper. Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Tue Jan 23 12:09:04 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA12667 for security-outgoing; Tue, 23 Jan 1996 12:09:04 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA12658 for ; Tue, 23 Jan 1996 12:08:59 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id MAA11043; Tue, 23 Jan 1996 12:06:07 -0800 From: Nathan Lawson Message-Id: <199601232006.MAA11043@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: pst@shockwave.com (Paul Traina) Date: Tue, 23 Jan 1996 12:06:06 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199601230958.BAA03233@precipice.shockwave.com> from "Paul Traina" at Jan 23, 96 01:58:03 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > Let me state, completely, my objections to adding the tcp wrapper code: > > (a) there are several similar competing bits of code out there > that do similar things -- wrappers is not the only way to go I've only heard of xinetd, and Mike Neumann's binetd, but that's for SunOS only. There are plenty of competing mailer packages besides sendmail, but sendmail comes installed by default. Why? Because it's the industry standard mailer. Look on any system that uses any kind of access control and it's very likely that they are using tcp_wrappers. Why? Because it's smaller, easy to configure, and well-written. I think your arguments could be extended to say that "let's have sendmail be a port since many sites are not Internet or even UUCP connected. It's easy to install if a user should desire it. Besides, I have a firewall and use a custom package anyway, so it would save space on my system, as well as all the work to keep up-to-date (what with all the holes and security patches that sendmail has gone through)" The real problem here is that FreeBSD doesn't have a very dynamic installation system. I think it would be good if people had a way to specify which utilities they wanted installed. The whole bindist thing is the root of this problem. Everyone wants a small utility that they use often to be installed by default, but the people who don't use it could care less. Splitting things up into smaller packages would be nice (perhaps a feature only activated when you are doing a Custom install). There would be menus that say things like "select a mailer" and you can choose sendmail, smail, mmdf, or none. The sendmail option screen could be a subset of "Are you Internet connected?". That way things could be subdivided. An advantage I see of this is that smaller installs overall would be possible, making it easy to custom tailer a whole range of boxes to your own taste. Also, there would be less bandwidth used on ftp.cdrom.com (and other sites). A big disadvantage is it would be a lot of work initially to set up the system, but once it was done, it would be pretty trivial to make up a description file for each package. > (b) it's already trivial for a user to add this support into the > base system should they desire it Not true. Many utilities like mountd, portmap, and ypserv have to be recompiled to have additional access control, inetd.conf has to be changed, etc. Repeat this on several hundred machines and you start seeing Slackware's divided install look pretty good. > (c) incorporating it into the base system means more work to support, > test, debug, and maintain the code Possibly, but this code is not very dynamic. It hasn't changed much over the several years it's been offered. Debugging should be a breeze too. I've never had a problem from it. I've compiled it on just about every system that it supports, except Unicos, and there have never been any problems. > (d) the wrapper changes duplicate much of the access logging and > control we have already included directly in the system Again, this is only half-true. Rlogin/rsh do log more a la logdaemon. But what about telnetd, fingerd, and the many many others? > (e) they don't cover the case of UDP programs Hmmm. I may be wrong, but it works fine with talkd and talk requests are transmitted via UDP. > If you can address these issues, then I will withdraw my objections. I believe I have in a small way. Of course, you ignored the issue of bin ownership. I should have made them seperate issues :) -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Tue Jan 23 12:10:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA12821 for security-outgoing; Tue, 23 Jan 1996 12:10:41 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA12814 for ; Tue, 23 Jan 1996 12:10:37 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id MAA11051; Tue, 23 Jan 1996 12:10:16 -0800 From: Nathan Lawson Message-Id: <199601232010.MAA11051@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: pete@sms.fi (Petri Helenius) Date: Tue, 23 Jan 1996 12:10:15 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199601231004.MAA17990@silver.sms.fi> from "Petri Helenius" at Jan 23, 96 12:04:45 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > Paul Traina writes: > > > > I totally and completely disagree. I do not want to be bound by your > > idea of what's proper for the core part of the system. That's why we > > have a generic source distribution and you can personalize your system > > to your hearts content. > > > > Read: I will wish seriously bad karma on anyone who unilaterally bloats > > out the system with the wrapper code. There is NO good reason to > > make it anything other than a port -- which makes it OPTIONAL to > > install and easy to track 3rd party changes. > > I couldn't agree more. Many places do have adequate firewalling procedures > already in place and wrappers would do only more administrative overhead > with no additional security. And even more places do not have a firewall. Do you want to put a label on FreeBSD that says "Warning: do not connect to Internet without a firewall"? Of course, a firewall is a good first step, but there have been many ways to circumvent packet-filtering routers, and some interesting attacks over application level gateways. Personally, I'd like to know when Bob over in Accounting telnets to my machine. Or perhaps small ISP's that can't afford a firewall. I suggested that tcp_wrappers be installed in such a way as to minimize the administrative overhead. Compile it without ident and paranoid logging, and don't put anything in /etc/hosts.deny except some sample, commented-out, denies. That way, all you get originally is increased logging, and you can add the RFC931 and PARANOID options to the /etc/hosts.allow files _without_ recompiling (if you should desire). -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Tue Jan 23 12:51:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA15619 for security-outgoing; Tue, 23 Jan 1996 12:51:31 -0800 (PST) Received: from gateway.fedex.com (gateway.fedex.com [198.80.10.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA15603 for ; Tue, 23 Jan 1996 12:51:02 -0800 (PST) Received: by gateway.fedex.com id AA23145 (InterLock SMTP Gateway 3.0 for freebsd-security@freebsd.org); Tue, 23 Jan 1996 14:48:21 -0600 X-Disclaimer: THE COMMENTS CONTAINED IN THIS MESSAGE REFLECT THE VIEWS OF THE WRITER AND ARE NOT NECESSARILY THE VIEWS OF FEDERAL EXPRESS CORPORATION. Message-Id: <199601232048.AA23145@gateway.fedex.com> Received: by gateway.fedex.com (Internal Mail Agent-2); Tue, 23 Jan 1996 14:48:21 -0600 Received: by gateway.fedex.com (Internal Mail Agent-1); Tue, 23 Jan 1996 14:48:21 -0600 X-Authentication-Warning: dpd08.dpd.fedex.com: Host localhost didn't use HELO protocol To: Michael Smith Cc: freebsd-security@freebsd.org Subject: Re: Logging user activity Date: Tue, 23 Jan 1996 13:25:39 -0600 From: William McVey Sender: owner-security@freebsd.org Precedence: bulk Michael Smith wrote: >A couple of things you can do; if their shell is one of the csh flavours, >(most particularly tcsh) then you can set their history up (savehist >in particular) controlled by readonly shell variables. Set the >history length (first word in the 'savehist' variable) really high, say >around the 10,000 mark. > >Then you can set the append-only flag on their .history file, and they're >screwed. Well... until they 'exec /bin/sh' or some program they write that does a simple parse of entered commands and forks/execs without maintaining a history. >An alternative would be to use the process accounting stuff; look at >'ac' and 'accton' and 'lastcomm'. Accounting (historically) has some serious problems as far as security auditing goes. Typically the logfile contains the basename of the program executed. This means I build a few links (or rename the executables directly) of things like crack to be named 'vi' or 'cc' and you're none the wiser. In addition, on some systems (I don't know about FreeBSD), an accounting record doesn't get recorded until the process terminates. This means if a system wedges or crashes, there would be no accounting for the process. I've not used FreeBSD's accounting, the above is based off other vendors' implimentations, but it could represent some problems for security critical systems. -- William From owner-freebsd-security Tue Jan 23 13:20:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA17702 for security-outgoing; Tue, 23 Jan 1996 13:20:31 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA17690 for ; Tue, 23 Jan 1996 13:20:19 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.7.3) with SMTP id NAA02408; Tue, 23 Jan 1996 13:18:58 -0800 (PST) Message-Id: <199601232118.NAA02408@precipice.shockwave.com> To: dk+@ua.net cc: freebsd-security@FreeBSD.org Subject: Re: rxvt security hole - proposed fix + more In-reply-to: Your message of "Tue, 23 Jan 1996 13:00:56 GMT." <199601231300.PAA00906@dog.farm.org> Date: Tue, 23 Jan 1996 13:18:58 -0800 From: Paul Traina Sender: owner-security@FreeBSD.org Precedence: bulk And yes I know rxvt have to be fixed to drop its privileges when using -print-pipe anyway. Correction, rxvt has been fixed to drop its privileges when they're not required (which is when editing utmp). From owner-freebsd-security Tue Jan 23 18:30:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA09042 for security-outgoing; Tue, 23 Jan 1996 18:30:06 -0800 (PST) Received: from fire.stf.org.sg (jseng@fire.stf.org.sg [137.132.19.134]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA08992 for ; Tue, 23 Jan 1996 18:30:02 -0800 (PST) Received: (from jseng@localhost) by fire.stf.org.sg (8.6.12/8.6.9) id KAA18920; Wed, 24 Jan 1996 10:39:42 +0800 Date: Wed, 24 Jan 1996 10:39:41 +0800 (SGT) From: James Seng To: Nathan Lawson cc: Petri Helenius , security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <199601232010.MAA11051@statler.csc.calpoly.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk On Tue, 23 Jan 1996, Nathan Lawson wrote: > denies. That way, all you get originally is increased logging, and you can > add the RFC931 and PARANOID options to the /etc/hosts.allow files _without_ > recompiling (if you should desire). Ah great. Lets get Wieste and see if he has that time to hack it in? *8P Before we get over paranoid over security, lets us remember that the primary aim of a base distribution is to provide an dynamic system, of course minus the security bugs. So far, all of us agree that tcpd is a great tool. The problem is that should it go into the bindist just because slackware does so too? I wish to remind all of us here that there is a few dozen of ways tcpd could be installed, each site adopting to their need. You could put in a "generic" tcpd into /usr/libexec but if it is not properly installed, it is almost as good as useless. In fact, i believe it would drive a false sense of security ("Hey, dont worry..i got tcpd install by default!") into some people which could be worst. Now perhaps it is time to sit down and let the core member of FreeBSD to think about what they are trying to archive. Are they trying to provide a dynamic un*x or are they trying to provide a secure C2 system (ok C2 is too much *8)? IMHO, so long the base code is clean and no loopholes exist, it should be good enough. Lets not blob the bindist further unneccessary... Just a thought...maybe they could add a new section, say "SECURITY TOOLS" in sysinstall whereby all security tools like tcpd, tiger, cops, tripwire etc could be installed...? It would be nice to have all these but i think not all people would want it.... -James Seng (jseng@stf.org.sg) From owner-freebsd-security Tue Jan 23 19:40:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA14729 for security-outgoing; Tue, 23 Jan 1996 19:40:56 -0800 (PST) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA14713 for ; Tue, 23 Jan 1996 19:40:41 -0800 (PST) Received: by haven.uniserve.com id <30754-3>; Tue, 23 Jan 1996 19:43:08 -0000 Date: Tue, 23 Jan 1996 19:42:57 -0800 (PST) From: Tom Samplonius To: Nathan Lawson cc: Paul Traina , security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <199601232006.MAA11043@statler.csc.calpoly.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Tue, 23 Jan 1996, Nathan Lawson wrote: > > Let me state, completely, my objections to adding the tcp wrapper code: > > > > (a) there are several similar competing bits of code out there > > that do similar things -- wrappers is not the only way to go > > I've only heard of xinetd, and Mike Neumann's binetd, but that's for SunOS > only. There are plenty of competing mailer packages besides sendmail, but > sendmail comes installed by default. Why? Because it's the industry standard > mailer. Look on any system that uses any kind of access control and it's > very likely that they are using tcp_wrappers. Why? Because it's smaller, > easy to configure, and well-written. ...and slower. > I think your arguments could be extended to say that "let's have sendmail be > a port since many sites are not Internet or even UUCP connected. It's easy > to install if a user should desire it. Besides, I have a firewall and use > a custom package anyway, so it would save space on my system, as well as all > the work to keep up-to-date (what with all the holes and security patches that > sendmail has gone through)" Sendmail is included because it is standard BSD tool, and has always been included with BSD distributions since Sendmail was written. Tom From owner-freebsd-security Tue Jan 23 19:51:04 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA15690 for security-outgoing; Tue, 23 Jan 1996 19:51:04 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA15681 for ; Tue, 23 Jan 1996 19:50:55 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id OAA25573; Wed, 24 Jan 1996 14:29:59 +1030 From: Michael Smith Message-Id: <199601240359.OAA25573@genesis.atrad.adelaide.edu.au> Subject: Re: Logging user activity To: wam@fedex.com (William McVey) Date: Wed, 24 Jan 1996 14:29:58 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, freebsd-security@freebsd.org In-Reply-To: <199601232048.AA23145@gateway.fedex.com> from "William McVey" at Jan 23, 96 01:25:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk William McVey stands accused of saying: > >Then you can set the append-only flag on their .history file, and they're > >screwed. > > Well... until they 'exec /bin/sh' or some program they write that does > a simple parse of entered commands and forks/execs without maintaining > a history. Yup. Point. > >An alternative would be to use the process accounting stuff; look at > >'ac' and 'accton' and 'lastcomm'. > > Accounting (historically) has some serious problems as far as > security auditing goes. Typically the logfile contains the basename Agreed. These are good techniques for catching inexperienced hackers; good ones will spot them straight off. Short of a direct tty log of everything you don't have much hope there. > -- William -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-security Tue Jan 23 21:31:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA25138 for security-outgoing; Tue, 23 Jan 1996 21:31:52 -0800 (PST) Received: from argus.flash.net (root@[206.149.24.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA25125 for ; Tue, 23 Jan 1996 21:31:47 -0800 (PST) Received: (from lists@localhost) by argus.flash.net (8.6.12/8.6.12) id AAA00965; Tue, 23 Jan 1996 00:41:20 -0600 From: mailing list account Message-Id: <199601230641.AAA00965@argus.flash.net> Subject: Re: Ownership of files/tcp_wrappers port To: nlawson@statler.csc.calpoly.edu (Nathan Lawson) Date: Tue, 23 Jan 1996 00:41:19 -0600 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: <199601222147.NAA09887@statler.csc.calpoly.edu> from "Nathan Lawson" at Jan 22, 96 01:47:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org Precedence: bulk In reply: > or not. Are there any more? I really have not heard a convincing argument > for bin ownership other than "too many files are owned by root". Remember which is a lame argument to boot. user and group ownership should be based on function, instead of preference. I pity the poor fool who changes the ownership of a setuid script to root, or a setgid script to wheel... same for setuid/gid programs that give any form of shell access.. bin is nice for non-threat functions in that it has no password assigned, thus disabling any logins... of course there is that one fool in a million who will assign a password for bin, thus making it vulnerable. ghost accounts and groups are not a problem. improper use of permissions bits, stickyness of dirs, and setuid/gid are problems. the plaintext nature of most tcp connections is even a greater threat. > Secondly, I was wondering why the tcp_wrappers distribution didn't make it > into the source tree instead of being a port. It's a pretty small program > that hasn't received too many changes recently. It's very worthwhile and > libwrap.a can be linked into portmap and ypserv a lot more easily (even > making this the default, perhaps). i really see nothing wrong with it being a port, as long as it is in source form, not as a package. security packages are a matter of preference, and should be hackable and/or replacable for any situation. I do see areas where permissions could be changed up a bit... world permissions on binaries should always be 1, and for most of them, a 711 would be adequate... this would be best done in the distribution, and makefiles so we don't have to do it ourselves every time a new release is made. the easiest way for hacker to learn a program's weakneses is from a debugging dump of a readable binary. this in itself will only stop the casual hacker. with the avalability of the sources, a determined hacker could probably find holes with a little effort. Jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@argus.flash.net - FlashNet Communications - Ft. Worth, Texas From owner-freebsd-security Tue Jan 23 23:19:13 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA03940 for security-outgoing; Tue, 23 Jan 1996 23:19:13 -0800 (PST) Received: from schizo.cdsnet.net (schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA03934 for ; Tue, 23 Jan 1996 23:19:11 -0800 (PST) Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.12) id XAA01501; Tue, 23 Jan 1996 23:18:59 -0800 Date: Tue, 23 Jan 1996 23:18:58 -0800 (PST) From: Jaye Mathisen To: Nathan Lawson cc: Petri Helenius , security@FreeBSD.org Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <199601232010.MAA11051@statler.csc.calpoly.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org Precedence: bulk I submit that BSD/OS has been shipping with tcp wrappers for some time now, and nary a complaint that I have seen on any list. They provide a config for no wrappers, where you just replace inetd.conf with one already setup for no wrappers, and that's it. No muss, no fuss, and bloat for a dinky program like that is probably a severe overstatement. From owner-freebsd-security Wed Jan 24 00:30:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA09859 for security-outgoing; Wed, 24 Jan 1996 00:30:10 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA09775 for ; Wed, 24 Jan 1996 00:29:57 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA26571; Wed, 24 Jan 1996 19:07:59 +1030 From: Michael Smith Message-Id: <199601240837.TAA26571@genesis.atrad.adelaide.edu.au> Subject: Re: Ownership of files/tcp_wrappers port To: lists@argus.flash.net (mailing list account) Date: Wed, 24 Jan 1996 19:07:59 +1030 (CST) Cc: nlawson@statler.csc.calpoly.edu, freebsd-security@freebsd.org In-Reply-To: <199601230641.AAA00965@argus.flash.net> from "mailing list account" at Jan 23, 96 00:41:19 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk mailing list account stands accused of saying: > > or not. Are there any more? I really have not heard a convincing argument > > for bin ownership other than "too many files are owned by root". Remember > > which is a lame argument to boot. If nothing else, it's convenient to have "someone" own "system" things. It's _preferable_ that this "someone" isn't a user in the common sense of the word. > user and group ownership should be based on function, instead of preference. Naturally. And if something is "just a binary", why shouldn't it be owned by bin? Only things that need to be owned by root, so that being setuid is useful, should be so. > I pity the poor fool who changes the ownership of a setuid script to root, or Just a point for you to consider; setuid shellscripts _do_not_work_ under FreeBSD. > bin is nice for non-threat functions in that it has no password > assigned, thus disabling any logins... of course there is that one > fool in a million who will And no shell either. > i really see nothing wrong with it being a port, as long as it is in source > form, not as a package. security packages are a matter of preference, and > should be hackable and/or replacable for any situation. Definitely agreed. > the easiest way for hacker to learn a program's weakneses is from a debugging > dump of a readable binary. > > this in itself will only stop the casual hacker. with the avalability of the > sources, a determined hacker could probably find holes with a little effort. Only a determined hacker would bother pulling apart a binary; with the source readily available I can't see any use in preventing read access to system binaries, and a few situations where it'd be a pain. > Jim -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-security Wed Jan 24 01:52:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA15188 for security-outgoing; Wed, 24 Jan 1996 01:52:10 -0800 (PST) Received: from solar.tlk.com (root@solar.tlk.com [194.97.84.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA15148 for ; Wed, 24 Jan 1996 01:51:36 -0800 (PST) Received: by solar.tlk.com id ; Wed, 24 Jan 96 10:50 MET Message-Id: Date: Wed, 24 Jan 96 10:50 MET From: torstenb@solar.tlk.com (Torsten Blum) To: pst@Shockwave.COM Cc: security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port Newsgroups: tlk.lists.freebsd.security References: <199601231119.NAA01191@grumble.grondar.za> <199601231133.DAA00324@precipice.shockwave.com> Sender: owner-security@freebsd.org Precedence: bulk >Probably something like > > .if (/usr/local/lib/libwrap.a) and !defined(NO_WRAPPERS) why not .if (/usr/local/lib/libwrap.a) and defined(USE_WRAPPERS) >so that distribution binaries can still be built (use whatever the >convention is that we do elsewhere and document the root makefile). I think the default should be to NOT use libwrap.a. Adding USE_WRAPPERS=YES to /etc/make.conf takes only 1-2 seconds... bye Torsten PS: I'm currently out of town... From owner-freebsd-security Wed Jan 24 02:07:39 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA16216 for security-outgoing; Wed, 24 Jan 1996 02:07:39 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA16211 for ; Wed, 24 Jan 1996 02:07:35 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id CAA11866; Wed, 24 Jan 1996 02:04:04 -0800 From: Nathan Lawson Message-Id: <199601241004.CAA11866@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: lists@argus.flash.net (mailing list account) Date: Wed, 24 Jan 1996 02:04:03 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199601230641.AAA00965@argus.flash.net> from "mailing list account" at Jan 23, 96 00:41:19 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > In reply: > > or not. Are there any more? I really have not heard a convincing argument > > for bin ownership other than "too many files are owned by root". Remember > > which is a lame argument to boot. Yes, it is. > user and group ownership should be based on function, instead of preference. > >I pity the poor fool who changes the ownership of a setuid script to root, or >a setgid script to wheel... same for setuid/gid programs that give any form of > shell access.. I think you're missing the point. Root runs programs like /bin/ls any time someone su's and lists a directory. So why is ls owned by bin? This means a degradation of privileges and allows a trojan horse attack. Is root a higher level of access than bin? Most definitely. So why should we allow bin compromises an easy way to make a root compromise. > bin is nice for non-threat functions in that it has no password assigned, thus >disabling any logins... of course there is that one fool in a million who will > assign a password for bin, thus making it vulnerable. I think you're missing the fact that bin compromises do not come from passwords assigned to it by mistake, but through NFS. Also, things like hosts.equiv allow bin access, while root is not allowed. Many many utilities treat root as a special account, with appropriate restrictions. I have NEVER seen a system that also applies these checks to bin as well. The only protection on bin is that it doesn't have a valid password. Let's have files that are executed as root be owned by root. > the plaintext nature of most tcp connections is even a greater threat. That's beside the point. I am not addressing network vulnerabilities. I am singling out host vulnerabilities. > I do see areas where permissions could be changed up a bit... > > world permissions on binaries should always be 1, and for most of them, a 711 > would be adequate... this would be best done in the distribution, and > makefiles so we don't have to do it ourselves every time a new release is made I think that binaries should not be world readable, but should be readable by group bin or whatever so that you can place trusted users in group bin and allow them to do strings(1) on binaries, etc. > the easiest way for hacker to learn a program's weakneses is from a debugging > dump of a readable binary. Yeah, but FreeBSD offers source, which is even better. I like the idea of things like /bin/sh not being readable so that cookbook scripts that copy and make a setuid shell are a bit slower to implement. > this in itself will only stop the casual hacker. with the avalability of the > sources, a determined hacker could probably find holes with a little effort. Exactly. Which is why things that are run with privileges must be protected as carefully as programs that run setuid root. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Wed Jan 24 02:13:29 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA16600 for security-outgoing; Wed, 24 Jan 1996 02:13:29 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA16592 for ; Wed, 24 Jan 1996 02:13:25 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id CAA11879; Wed, 24 Jan 1996 02:12:18 -0800 From: Nathan Lawson Message-Id: <199601241012.CAA11879@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: jseng@stf.org.sg (James Seng) Date: Wed, 24 Jan 1996 02:12:18 -0800 (PST) Cc: security@freebsd.org In-Reply-To: from "James Seng" at Jan 24, 96 10:39:41 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > On Tue, 23 Jan 1996, Nathan Lawson wrote: > > denies. That way, all you get originally is increased logging, and you can > > add the RFC931 and PARANOID options to the /etc/hosts.allow files _without_ > > recompiling (if you should desire). > > Ah great. Lets get Wieste and see if he has that time to hack it in? *8P I think you misunderstand. The PARANOID and RFC931 options can be added to the hosts.* file to enable them, even if the compiled binary has them disabled by default. This allows you to use a stripped-down default version, but upgrade it to as strict as you wish (even being stricter per service). > Before we get over paranoid over security, lets us remember that the > primary aim of a base distribution is to provide an dynamic system, of > course minus the security bugs. Well, then FreeBSD has failed. See the recent telnetd environment bug for an example of this. If you had wrapped telnetd and only allowed connects from certain sites, you could have limited the scope of this vulnerability. Bugs are going to show up no matter what. If having the extra logging and easy access control of tcp_wrappers at the installer's fingertips could have prevented even one breakin, I'd be all for it. > I wish to remind all of us here that there is a few dozen of ways tcpd > could be installed, each site adopting to their need. You could put in a > "generic" tcpd into /usr/libexec but if it is not properly installed, it is > almost as good as useless. In fact, i believe it would drive a false > sense of security ("Hey, dont worry..i got tcpd install by default!") into > some people which could be worst. Yes, but I think more people would say "wow, all I have to do is change the hosts.allow file according to its comments and it will have access control". > Now perhaps it is time to sit down and let the core member of FreeBSD to > think about what they are trying to archive. Are they trying to provide a > dynamic un*x or are they trying to provide a secure C2 system (ok C2 is too > much *8)? Well, they might be shooting for C2 in some ways. They've got shadowed passwords already. The extra logging of C2 could be useful to some people. > IMHO, so long the base code is clean and no loopholes exist, it should > be good enough. Lets not blob the bindist further unneccessary... Ok. You can go through and prove all the code in FreeBSD and I'll look over your results. If you can't find any loopholes, but I can, do I get a free lunch? :) > Just a thought...maybe they could add a new section, say "SECURITY TOOLS" > in sysinstall whereby all security tools like tcpd, tiger, cops, tripwire etc > could be installed...? It would be nice to have all these but i think not > all people would want it.... Now this is a good idea. What I'd REALLY like to see is builtin access control, perhaps based on tcpd. For instance, have telnetd log connects. That way each program could take care of itself and you wouldn't have the complaints about the fork/exec overhead of tcp_wrappers. It would be a bit more work, which is why I suggested adding tcp_wrappers instead. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Wed Jan 24 02:20:14 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA16960 for security-outgoing; Wed, 24 Jan 1996 02:20:14 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA16954 for ; Wed, 24 Jan 1996 02:20:09 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id CAA11895; Wed, 24 Jan 1996 02:19:52 -0800 From: Nathan Lawson Message-Id: <199601241019.CAA11895@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 24 Jan 1996 02:19:51 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199601240837.TAA26571@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 24, 96 07:07:59 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > mailing list account stands accused of saying: >> > or not. Are there any more? I really have not heard a convincing argument >> > for bin ownership other than "too many files are owned by root". Remember > > > > which is a lame argument to boot. > > If nothing else, it's convenient to have "someone" own "system" things. > It's _preferable_ that this "someone" isn't a user in the common sense of > the word. This "someone" is not well-protected enough to own critical things like binaries. Until you can prove to me that a bin compromise is as hard as a root compromise, I won't relent. Consider NFS, hosts.equiv, and login. None of those will stop a bin intrusion. If you can log in as bin, login will let you. If you can access a filesystem via NFS, bin access is allowed while root is mapped to nobody. Hosts.equiv allows _every_ user except root to access the equivalent account. Of course, I don't think rlogin and NFS are secure protocols. But you should od your best to protect what little security you do have. Saying "oh, the protocols are fundamentally flawed, let's just throw security out the door" is lazy. > > user and group ownership should be based on function, instead of preference. > > Naturally. And if something is "just a binary", why shouldn't it be owned > by bin? Only things that need to be owned by root, so that being setuid > is useful, should be so. Because "just binaries" are run by root every day. You wouldn't run a program owned by me (I hope!) Why would you let root run programs owned by someone else? Especially since the root account has more protection than bin. > > bin is nice for non-threat functions in that it has no password > > assigned, thus disabling any logins... of course there is that one > > fool in a million who will > > And no shell either. Nope. It uses /bin/sh if the shell is null. I prefer /noshell. >From login.c: if (*pwd->pw_shell == '\0') pwd->pw_shell = _PATH_BSHELL; -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Wed Jan 24 04:13:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA24912 for security-outgoing; Wed, 24 Jan 1996 04:13:43 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA24897 for ; Wed, 24 Jan 1996 04:13:32 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id WAA27070; Wed, 24 Jan 1996 22:51:55 +1030 From: Michael Smith Message-Id: <199601241221.WAA27070@genesis.atrad.adelaide.edu.au> Subject: Re: Ownership of files/tcp_wrappers port To: nlawson@statler.csc.calpoly.edu (Nathan Lawson) Date: Wed, 24 Jan 1996 22:51:55 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, security@freebsd.org In-Reply-To: <199601241019.CAA11895@statler.csc.calpoly.edu> from "Nathan Lawson" at Jan 24, 96 02:19:51 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk Nathan Lawson stands accused of saying: > > If nothing else, it's convenient to have "someone" own "system" things. > > It's _preferable_ that this "someone" isn't a user in the common sense of > > the word. > This "someone" is not well-protected enough to own critical things > like binaries. Until you can prove to me that a bin compromise is > as hard as a root compromise, I won't relent. Consider NFS, > hosts.equiv, and login. None of those will stop a bin intrusion. > If you can log in as bin, login will let you. If you can access a > filesystem via NFS, bin access is allowed while root is mapped to > nobody. Hosts.equiv allows _every_ user except root to access the > equivalent account. Bin has no shell. (See below). Few or no binaries are ever setuid bin. If you're paranoid, your NFS mounts are nosuid. I'd say bin was of comparable secureness to root. Root is, however, more likely to be stupid and use their password in cleartext over the 'net or be shoulder-snooped. > Of course, I don't think rlogin and NFS are secure protocols. But > you should od your best to protect what little security you do have. > Saying "oh, the protocols are fundamentally flawed, let's just throw > security out the door" is lazy. Take your pick. Either they're flawed and a leaking hole, or you should trust them. Chose one. Having binaries owned by bin compromised is no more likely than having binaries owned by root compromised. The added protection of having a nonlogin user owning them is obviously worth it, presuming that root is reasonably careful. Either way, bin is a convenient and simple safeguard. It hurts nothing, so why the angst? > > > bin is nice for non-threat functions in that it has no password > > > assigned, thus disabling any logins... of course there is that one > > > fool in a million who will > > > > And no shell either. > > Nope. It uses /bin/sh if the shell is null. I prefer /noshell. Bin has no shell, ie. it has a nonexistent shell. Check /etc/passwd on a stock FreeBSD system and you will find that bin has /nonexistent as a shell. > Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-security Wed Jan 24 04:48:49 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA26406 for security-outgoing; Wed, 24 Jan 1996 04:48:49 -0800 (PST) Received: from underdog.maxie.com (maxie.com [199.250.231.28]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA26401 for ; Wed, 24 Jan 1996 04:48:46 -0800 (PST) Received: (from max@localhost) by underdog.maxie.com (8.6.12/8.6.12) id HAA12469; Wed, 24 Jan 1996 07:48:17 -0500 Date: Wed, 24 Jan 1996 07:48:16 -0500 (EST) From: James Robertson To: security@Freebsd.org Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <199601241012.CAA11879@statler.csc.calpoly.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@Freebsd.org Precedence: bulk > > Before we get over paranoid over security, lets us remember that the > > primary aim of a base distribution is to provide an dynamic system, of > > course minus the security bugs. I have to strongly agree with this, Iet's NOT get paranoid over security. I feel if someone have reached the point they use the word paranoid to describe thier feeling of safety of a machine, it might perhaps be time to seriously reconsider whether the machine should be on a public network at all. Replacing that ethernet T-connector with a terminator is still a much more fool proof security measure. One of the primary reasons I switched all the machines here (a small IPP) was that the FreeBSD machines were not causing access problems like the Linux ones were. Linux appears to be "paranoid" out of the box, and there is little information available to find where all the checks are, much less disable them. Asking other systems running it didn't help, I got various answers, all along the line of "just leave it alone, it's supposed to be that way" all the way to "I don't feel that it's a good idea to give that info out". In the end, I never could get it to allow certain systems to telnet or even anonymous FTP, and some of the machines disallowed were on the same LAN. Removing the tcp wrappers didn't even fix the problems, the daemons just did the same checks themselves. In short, despite a few protests, I cahnaged all the machines to FreeBSD and ended the problems. (and a good deal of other ones unrelated to security.) I would hate to see FreeBSD become a "paranoid" distribution like that, with every possible security measure in full force by default. Its default setup is robust enough in most cases, and it is far easier to add additional security than it is to strip off layer after layer of options you never wanted to begin with. There is one place in FreeBSD I can think of that a change might be good idea, the Installation program should probably indicate that it is a very good idea to set a root password, instead of just giving a menu option to set it. A new comer to Unix might not be aware just how important that could be if it is anything other than a single user stand alone system. > Well, then FreeBSD has failed. See the recent telnetd environment bug for > an example of this. If you had wrapped telnetd and only allowed connects > from certain sites, you could have limited the scope of this vulnerability. Restricting the hosts that use telnet is not a solution for everyone, in our case 99% of our users could no longer login. Almost all of our user base comes from netside, not from local hosts.... James Robertson Treetop Internet Services From owner-freebsd-security Wed Jan 24 09:17:15 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07029 for security-outgoing; Wed, 24 Jan 1996 09:17:15 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA07012 for ; Wed, 24 Jan 1996 09:16:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.3/8.6.10) with SMTP id JAA13076; Wed, 24 Jan 1996 09:16:31 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199601241716.JAA13076@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Nathan Lawson cc: pst@shockwave.com (Paul Traina), security@FreeBSD.org Subject: Re: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Tue, 23 Jan 96 12:06:06 PST." <199601232006.MAA11043@statler.csc.calpoly.edu> Date: Wed, 24 Jan 96 09:16:31 -0800 X-Mts: smtp Sender: owner-security@FreeBSD.org Precedence: bulk Nathan Lawson writes: > > (b) it's already trivial for a user to add this support into the > > base system should they desire it > > Not true. Many utilities like mountd, portmap, and ypserv have to be > recompiled to have additional access control, inetd.conf has to be changed, > etc. Repeat this on several hundred machines and you start seeing Slackware' s > divided install look pretty good. I disagree. There is no need to recompile these utilities to have any additional access control if you want to use the IPFW code that is already in the kernel. The IPFW code in the kernel doesn't do any DNS lookups like TCPD does but it gives you a basic level of security without breaking any application code. It may be an idea to enhance the IPFW code in the kernel to do some periodic DNS lookups, e.g. if this is the first time the kernel has seen a packet from location X or if location X hasn't been verified in N hours/minutes then do the appropriate lookups to make IP spoofing more difficult. A kernel level KILL_IP_OPTIONS option could be a valuable extension as well. By keeping the code in the kernel (or library), adding additional security features to a service and controlling these features could be performed via some config file rather than a recompile. Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Wed Jan 24 10:13:35 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA09443 for security-outgoing; Wed, 24 Jan 1996 10:13:35 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA09364 for ; Wed, 24 Jan 1996 10:12:53 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id KAA12343; Wed, 24 Jan 1996 10:12:40 -0800 From: Nathan Lawson Message-Id: <199601241812.KAA12343@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 24 Jan 1996 10:12:39 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199601241221.WAA27070@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 24, 96 10:51:55 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > Nathan Lawson stands accused of saying: > > > If nothing else, it's convenient to have "someone" own "system" things. > > > It's _preferable_ that this "someone" isn't a user in the common sense of > > > the word. > > > This "someone" is not well-protected enough to own critical things > > like binaries. Until you can prove to me that a bin compromise is > > as hard as a root compromise, I won't relent. Consider NFS, > > hosts.equiv, and login. None of those will stop a bin intrusion. > > If you can log in as bin, login will let you. If you can access a > > filesystem via NFS, bin access is allowed while root is mapped to > > nobody. Hosts.equiv allows _every_ user except root to access the > > equivalent account. > > Bin has no shell. (See below). Few or no binaries are ever setuid bin. Pardon me. I was thinking of the many other nologin accounts that had a null shell (meaning /bin/sh by default). > If you're paranoid, your NFS mounts are nosuid. I'd say bin was of > comparable secureness to root. Root is, however, more likely to be stupid > and use their password in cleartext over the 'net or be shoulder-snooped. If root gets compromised, then bin is compromised too (I can su bin or just overwrite bin-owned files as root). However, if bin is compromised, root is _not_ necessarily compromised unless you have lots of common binaries owned by bin. See the difference? Bin is only a common user without a password. It has no more protection than your or my account, except its password cannot be sniffed (since there is none). It doesn't matter if your NFS mounts are nosuid. They have to be read-only too. Think about this: you export /usr/bin to some diskless FreeBSD client. Some guy gets root on that client, does an su bin, and replaces /usr/bin/login with some script to start a shell on a port. Now all he has to do is telnet to your machine, telnetd starts up login, and it pops up his root shell on another port. How about hosts.equiv? Joe User gets root access on a machine. He can rlogin to the server as any user. What user would get him more privileges? Well, he can't login as root since hosts.equiv doesn't allow that. So, he rlogins as bin, replaces some key binaries, and you have the same compromised state. Now let's say nothing was owned by bin. All binaries are owned by root. Joe User rlogin's or nfs's into the server as bin. Whoops! He's gained no more privileges than if he had chosen Susy User or any other account. Now, he has to exploit some local bug to get root on server (which isn't impossible, but will definitely take a bit longer). > Having binaries owned by bin compromised is no more likely than having > binaries owned by root compromised. The added protection of having a > nonlogin user owning them is obviously worth it, presuming that root is > reasonably careful. Not true (see above). Bin compromises are much easier than root, especially if the admin is careful about the root password. > Either way, bin is a convenient and simple safeguard. It hurts nothing, > so why the angst? It hurts security. I still have yet to hear a good reason why bin ownership has even one advantage over root. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Wed Jan 24 10:30:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA10443 for security-outgoing; Wed, 24 Jan 1996 10:30:59 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA10421 for ; Wed, 24 Jan 1996 10:30:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.3/8.6.10) with SMTP id KAA13149; Wed, 24 Jan 1996 10:28:44 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199601241828.KAA13149@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Nathan Lawson cc: jseng@stf.org.sg (James Seng), security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Wed, 24 Jan 96 02:12:18 PST." <199601241012.CAA11879@statler.csc.calpoly.edu> Date: Wed, 24 Jan 96 10:28:44 -0800 X-Mts: smtp Sender: owner-security@freebsd.org Precedence: bulk Nathan Lawson wrote: > > On Tue, 23 Jan 1996, Nathan Lawson wrote: > > Before we get over paranoid over security, lets us remember that the > > primary aim of a base distribution is to provide an dynamic system, of > > course minus the security bugs. > > Well, then FreeBSD has failed. See the recent telnetd environment bug for > an example of this. If you had wrapped telnetd and only allowed connects > from certain sites, you could have limited the scope of this vulnerability. In that case so have Sun, IBM, DEC, and HP, to name a few, failed. Bugs are the nature of the beast. Though TCPD is a good product, configuration is at the heart of the issue. For example I like to use the auth facility for logging TCPD logs not the mail facility. Even when I ran Linux I had to recompile TCPD, for the reason I stated above and because Slackware had an older copy of TCPD. Ports is where TCPD belongs. It doesn't take much to extract TCPD, reconfigure it and do a make install. As far as converting inetd.conf to use TCPD, here is an awk script I use on the Sun and DEC boxes I manage at work. This could be incorporated in the port to make the job of installing TCPD much easier. #!/usr/bin/awk -f $1 !~ /^#/ && $6 != "internal" && $6 !~ /tcpd/ && $6 ~ /sbin/ && $7 !~ /identd/ {print "## " $0; print $1 "\t" $2 "\t" $3 "\t" $4 "\t" $5 "\t/usr/local/etc/tcpd\t" $7 "\t" $8 " " $9} $1 !~ /^#/ && $6 != "internal" && $6 !~ /tcpd/ && $6 !~ /sbin/ && $7 !~ /identd/ {print "## " $0; print $1 "\t" $2 "\t" $3 "\t" $4 "\t" $5 "\t/usr/local/etc/tcpd\t" $6 "\t" $8 " " $9} $1 != "time" && $6 == "internal" {print "## " $0} $1 == "time" {print $0} $1 ~ /^#/ || $6 ~ /tcpd/ || $7 ~ /identd/ {print $0} Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Wed Jan 24 11:00:37 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA12494 for security-outgoing; Wed, 24 Jan 1996 11:00:37 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA12429 for ; Wed, 24 Jan 1996 11:00:16 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id KAA12350; Wed, 24 Jan 1996 10:25:59 -0800 From: Nathan Lawson Message-Id: <199601241825.KAA12350@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: max@underdog.maxie.com (James Robertson) Date: Wed, 24 Jan 1996 10:25:59 -0800 (PST) Cc: security@freebsd.org In-Reply-To: from "James Robertson" at Jan 24, 96 07:48:16 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > > > Before we get over paranoid over security, lets us remember that the > > > primary aim of a base distribution is to provide an dynamic system, of > > > course minus the security bugs. > > I have to strongly agree with this, Iet's NOT get paranoid over security. > I feel if someone have reached the point they use the word paranoid to > describe thier feeling of safety of a machine, it might perhaps be time > to seriously reconsider whether the machine should be on a public network > at all. Replacing that ethernet T-connector with a terminator is still a > much more fool proof security measure. I get a different feeling when someone starts suggesting that security measures are paranoid: I start feeling like they don't quite understand what is going on. Proper security is not paranoia. It is not obscurity. It's being able to understand your system well enough to know where holes can appear and being able to detect and control access to your machine. Security is your way of saying "Yes, I own my machine, I know how it works, therefore I am not worried about hacking attempts". People are most afraid of what they don't understand. I wasn't suggesting "paranoid" security measures, I was suggesting that we make tcp_wrappers easily available for newer users, such as yourself, so that if you wish to add access control, you can edit one file to do so. I did NOT suggest that anything be denied by default. In fact, I am against this. But it should be there when someone installs, so that they can make quick use of it (just like any other tool). > One of the primary reasons I switched all the machines here (a small IPP) > was that the FreeBSD machines were not causing access problems like the > Linux ones were. Linux appears to be "paranoid" out of the box, and there > is little information available to find where all the checks are, much > less disable them. Asking other systems running it didn't help, I got > various answers, all along the line of "just leave it alone, it's > supposed to be that way" all the way to "I don't feel that it's a good > idea to give that info out". Even the paranoid option of tcp_wrappers doesn't complain unless DNS is misconfigured or other things like that. What you say is kind of scary, because there are other, more complex issues in running a Unix box (whether Linux or FreeBSD) which are much more dangerous and you were running into just the small ones. Spend some time on your system, whether Linux or FreeBSD, ls'ing around, running arbitrary commands, and using the man pages. Get a "feel" for how your system really operates. > In the end, I never could get it to allow certain systems to telnet or > even anonymous FTP, and some of the machines disallowed were on the same > LAN. Removing the tcp wrappers didn't even fix the problems, the daemons > just did the same checks themselves. In short, despite a few protests, I > cahnaged all the machines to FreeBSD and ended the problems. (and a good > deal of other ones unrelated to security.) I prefer FreeBSD to Linux, but your fix of installing a new operating system because the old one complained too much is a bad omen. Systems do not complain unless there really is something wrong. Changing OS's won't fix what's wrong, it will just change how it's reported (or ignored). > I would hate to see FreeBSD become a "paranoid" distribution like that, > with every possible security measure in full force by default. Its Like I said before, I did not suggest this. I suggested that it be available for quick user configuration IF IT IS DESIRED. > There is one place in FreeBSD I can think of that a change might be good > idea, the Installation program should probably indicate that it is a very > good idea to set a root password, instead of just giving a menu option to > set it. A new comer to Unix might not be aware just how important that > could be if it is anything other than a single user stand alone system. > > > Well, then FreeBSD has failed. See the recent telnetd environment bug for > > an example of this. If you had wrapped telnetd and only allowed connects > > from certain sites, you could have limited the scope of this vulnerability. > > Restricting the hosts that use telnet is not a solution for everyone, in > our case 99% of our users could no longer login. Almost all of our user > base comes from netside, not from local hosts.... > James Robertson > Treetop Internet Services Perhaps it wouldn't have helped for your system, but for many others, I think it would have been a great help. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Wed Jan 24 12:10:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA16333 for security-outgoing; Wed, 24 Jan 1996 12:10:58 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA16309 for ; Wed, 24 Jan 1996 12:10:29 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id UAA00114 for ; Wed, 24 Jan 1996 20:08:24 GMT Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Wed, 24 Jan 1996 20:08:32 +0000 Received: (from dpr@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id UAA19526 for security@FreeBSD.org; Wed, 24 Jan 1996 20:08:32 GMT From: Paul Richards Message-Id: <199601242008.UAA19526@cadair.elsevier.co.uk> Subject: Re: Ownership of files/tcp_wrappers port To: security@FreeBSD.org Date: Wed, 24 Jan 1996 20:08:31 +0000 (GMT) In-Reply-To: <199601241812.KAA12343@statler.csc.calpoly.edu> from "Nathan Lawson" at Jan 24, 96 10:12:39 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.org Precedence: bulk In reply to Nathan Lawson who said > > > Nathan Lawson stands accused of saying: > > > This "someone" is not well-protected enough to own critical things > > > like binaries. Until you can prove to me that a bin compromise is > > > as hard as a root compromise, I won't relent. Consider NFS, > > > hosts.equiv, and login. None of those will stop a bin intrusion. > > > If you can log in as bin, login will let you. If you can access a > > > filesystem via NFS, bin access is allowed while root is mapped to > > > nobody. Hosts.equiv allows _every_ user except root to access the > > > equivalent account. > > > > Bin has no shell. (See below). Few or no binaries are ever setuid bin. Umm, bin does have a shell bin:*:3:7:Binaries Commands and Source,,,:/:/bin/sh The real point against you're argument is segregation of priviliges. Why give any more privilage to a binary than is necessary. If a binary doesn't need to be root then don't make it owned by root at all and then if something goes wrong, like you mistakenly suid a bin binary and not realise it, the possible damage is less than if it was a root binary. This segregation is more to do with protecting sysadmins from themselves than it is about preventing break-ins and the added segragation is *NOT* a potential security hole since those uid's do not have passwords and therefore *cannot* be cracked in and of themselves. You *have* to crack root first. The point about bin is that the system is not owned by an actual user. Another, related point, is that if someone does get access to bin, the damage they can do is limited to the system binaries, you can't go trashing other people's files. To be honest, in a break-in situation the system files are my least concern, if you're security minded you'll be aware pretty soon if someone is messing with your system files and deal with it. Detecting damage to users files is more difficult and in many ways is more important, if someone cracks bin and takes your system down you have outage while you restore, if someone trashed an users mission critical data you're in big trouble. Sysadmins make mistakes, if you make a potentially serious mistake with a bin owned system binary the possible damage is limited to bin owned files. If you make a mistake with a root owned file it's a different matter. This is what segregation of privilages is all about. Making a lot more of the system owned by root just increases the number of potential pitfalls facing sysadmins. -- Paul Richards. Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-security Wed Jan 24 13:50:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA22866 for security-outgoing; Wed, 24 Jan 1996 13:50:54 -0800 (PST) Received: from argus.flash.net (root@[206.149.24.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA22804 for ; Wed, 24 Jan 1996 13:49:58 -0800 (PST) Received: (from lists@localhost) by argus.flash.net (8.6.12/8.6.12) id PAA00722; Wed, 24 Jan 1996 15:47:31 -0600 From: mailing list account Message-Id: <199601242147.PAA00722@argus.flash.net> Subject: Re: Ownership of files/tcp_wrappers port To: nlawson@statler.csc.calpoly.edu (Nathan Lawson) Date: Wed, 24 Jan 1996 15:47:30 -0600 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: <199601241012.CAA11879@statler.csc.calpoly.edu> from "Nathan Lawson" at Jan 24, 96 02:12:18 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org Precedence: bulk In reply: > I think you misunderstand. The PARANOID and RFC931 options can be added to > the hosts.* file to enable them, even if the compiled binary has them disabled > by default. This allows you to use a stripped-down default version, but > upgrade it to as strict as you wish (even being stricter per service). RFC931 can be faked out with almost no effort... it's only legitimate authentication use is over a TRUSTED network for casual identification of who is using a service, and even then.... ------ from RFC931.TXT -------------------------------------------------- CAVEATS Unfortunately, the trustworthiness of the various host systems that might implement an authentication server will vary quite a bit. It is up to the various applications that will use the server to determine the amount of trust they will place in the returned information. It may be appropriate in some cases restrict the use of the server to within a locally controlled subnet. ------ End -------------------------------------------------------------- > > Before we get over paranoid over security, lets us remember that the > > primary aim of a base distribution is to provide an dynamic system, of > > course minus the security bugs. > > Well, then FreeBSD has failed. See the recent telnetd environment bug for > an example of this. If you had wrapped telnetd and only allowed connects > from certain sites, you could have limited the scope of this vulnerability. > > Bugs are going to show up no matter what. If having the extra logging and easy > access control of tcp_wrappers at the installer's fingertips could have > prevented even one breakin, I'd be all for it. correct, bugs are a fact of life... Adm. Hopper made a GREAT speech along those lines once [great person, but I really don't care for COBOL]... the idea in computer security is not to be paranoid, that gets in the way of getting things done. the idea is usually to use some common sense though. such things as permissions alone can help thwart a hacker once he is in, making everything root:wheel when all that is needed is to remove the read bits from a binary is stupid and potentially dangerous. as far as security packages, as i said before, you may like tcp_wrappers, i may do something different, and joe blow up the net may not do anything at all [to his demise]... let's not standardize on anything in particular, just support as much as possible. > > I wish to remind all of us here that there is a few dozen of ways tcpd > > could be installed, each site adopting to their need. You could put in a > > "generic" tcpd into /usr/libexec but if it is not properly installed, it is > > almost as good as useless. In fact, i believe it would drive a false > > sense of security ("Hey, dont worry..i got tcpd install by default!") into > > some people which could be worst. > > Yes, but I think more people would say "wow, all I have to do is change the > hosts.allow file according to its comments and it will have access control". and is also why security packages are preferable in source form... > > Now perhaps it is time to sit down and let the core member of FreeBSD to > > think about what they are trying to archive. Are they trying to provide a > > dynamic un*x or are they trying to provide a secure C2 system (ok C2 is too > > much *8)? > > Well, they might be shooting for C2 in some ways. They've got shadowed > passwords already. The extra logging of C2 could be useful to some people. remember, incorrect chmods can defeat the purpose of C2... [OKAY NATE, in some cases, so can incorrect ownership].. > > IMHO, so long the base code is clean and no loopholes exist, it should > > be good enough. Lets not blob the bindist further unneccessary... > > Ok. You can go through and prove all the code in FreeBSD and I'll look over > your results. If you can't find any loopholes, but I can, do I get a free > lunch? :) AXIOM 1). Security holes will ALWAYS exist. tell me how the lunch goes... > > Just a thought...maybe they could add a new section, say "SECURITY TOOLS" > > in sysinstall whereby all security tools like tcpd, tiger, cops, tripwire etc > > could be installed...? It would be nice to have all these but i think not > > all people would want it.... > > Now this is a good idea. What I'd REALLY like to see is builtin access > control, perhaps based on tcpd. For instance, have telnetd log connects. > That way each program could take care of itself and you wouldn't have the > complaints about the fork/exec overhead of tcp_wrappers. It would be a bit > more work, which is why I suggested adding tcp_wrappers instead. a little more logging never hurts. as long as a good MIX of packages are provided in SOURCE FORM on the CD. Got to remember that there are probably as many FreeBSD boxes that will never connect to the Internet as there are that will... i know that i said this before, but i WILL say it again... one thing i'd like to see is the majority of the binaries set to chmod 711 in the distribution. this is simple enough to implement, and should not harm the functionality of anything. Jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@argus.flash.net - FlashNet Communications - Ft. Worth, Texas From owner-freebsd-security Wed Jan 24 14:25:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA25448 for security-outgoing; Wed, 24 Jan 1996 14:25:11 -0800 (PST) Received: from intele.net (quervo.intele.net [204.118.149.20]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA25442 for ; Wed, 24 Jan 1996 14:25:01 -0800 (PST) Received: (wes@localhost) by intele.net (8.6.12/8.6.5) id PAA12565; Wed, 24 Jan 1996 15:24:48 -0700 From: Barnacle Wes Message-Id: <199601242224.PAA12565@intele.net> Subject: Re: Logging user activity To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 24 Jan 1996 15:24:47 -0700 (MST) Cc: freebsd-security@FreeBSD.org In-Reply-To: <199601240359.OAA25573@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 24, 96 02:29:58 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@FreeBSD.org Precedence: bulk William McVey stands accused of saying: % Accounting (historically) has some serious problems as far as % security auditing goes. Typically the logfile contains the basename Mike Smith observed by way of reply: > Agreed. These are good techniques for catching inexperienced hackers; > good ones will spot them straight off. Short of a direct tty log of > everything you don't have much hope there. On the other hand, since you do have the system sources, you can go hack the syscalls for exec, open, etc. to log whatever you want. Unless you think the user is dumping statically-linked executables on your system, it would probably be enough to just create a new libc.so that does syslog calls before each syscall. Use the source, Luke! -- Wes Peters | Yes I am a pirate, two hundred years too late Softweyr | The cannons don't thunder, there's nothing to plunder Consulting | I'm an over forty victim of fate... wes@intele.net | Jimmy Buffet From owner-freebsd-security Wed Jan 24 15:37:03 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA00773 for security-outgoing; Wed, 24 Jan 1996 15:37:03 -0800 (PST) Received: from multivac.orthanc.com (root@multivac.orthanc.com [206.12.238.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA00768 for ; Wed, 24 Jan 1996 15:36:55 -0800 (PST) Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7.3/8.7.3) with SMTP id PAA13164; Wed, 24 Jan 1996 15:32:47 -0800 (PST) Message-Id: <199601242332.PAA13164@multivac.orthanc.com> X-Authentication-Warning: multivac.orthanc.com: Host lyndon@localhost didn't use HELO protocol From: Lyndon Nerenberg VE7TCP To: Paul Richards cc: security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Wed, 24 Jan 1996 20:08:31 GMT." <199601242008.UAA19526@cadair.elsevier.co.uk> Date: Wed, 24 Jan 1996 15:32:43 -0800 Sender: owner-security@freebsd.org Precedence: bulk >>>>> "Paul" == Paul Richards writes: Paul> The real point against you're argument is segregation of Paul> priviliges. Why give any more privilage to a binary than is Paul> necessary. If a binary doesn't need to be root then don't Paul> make it owned by root at all and then if something goes Paul> wrong, like you mistakenly suid a bin binary and not realise Paul> it, the possible damage is less than if it was a root Paul> binary. This is where you are wrong. It is the *same* as if a root binary were compromised? Why? Because sooner or later that bin-owned binary is going to be run by root. Let's look at your example. You accidentally chmod u+s something owned by bin. What you have here is the potential for *any* user with access to the chmoded command to replace *any* file in /sbin, /usr/sbin, /bin, and /usr/bin. Why? Because these directories are writable by the user 'bin'. This gives you the ability to whack files in those directories that aren't even *owned* by bin. Not to mention the ones that are. Imagine the consequences of this setuid-bin program causing /sbin/init to be unlinked. Harmless? The setuid-bin program can also do things like replace /bin/ls. How long will it be before root runs the new-and-improved ls? As long as root runs bin owned binaries, bin is equivelent to root. Period. Paul> This segregation is more to do with protecting Paul> sysadmins from themselves than it is about preventing Paul> break-ins and the added segragation is *NOT* a potential Paul> security hole since those uid's do not have passwords and Paul> therefore *cannot* be cracked in and of themselves. You Paul> *have* to crack root first. The point about bin is that the Paul> system is not owned by an actual user. Nonsense. Perhaps the easiest attack available is to NFS mount your /usr from a workstation where I have root access. Like this: % su # mount unsecure:/usr /mnt # su bin > rm -f /mnt/bin/more; cp /my/new/and/improved/more /mnt/bin Now, the next time you run the more command as root on your system, my fixed up version wanders off and creates any one of a million possible backdoors into your system. I've just broken root on your box, soley through the use of this "harmless" bin user. And this is just *one* example. [ Note: this is just an example to make point. I'm not stating that this, or any other, specific attack will work. Everybody's machine is a bit different. Let's not get sidetracked from the main issue. ] Some systems are foolish enough to ship with the /etc directory owned by bin. Guess what happens when I can unlink and replace /etc/passwd? Paul> Sysadmins make mistakes, if you make a potentially serious Paul> mistake with a bin owned system binary the possible damage Paul> is limited to bin owned files. If you make a mistake with a Paul> root owned file it's a different matter. To summarize: if root runs bin-owned binaries, bin is root. To pretend otherwise is wrong (and dangerous). --lyndon From owner-freebsd-security Wed Jan 24 16:55:27 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA06300 for security-outgoing; Wed, 24 Jan 1996 16:55:27 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA06290 for ; Wed, 24 Jan 1996 16:55:15 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA28536; Thu, 25 Jan 1996 11:32:14 +1030 From: Michael Smith Message-Id: <199601250102.LAA28536@genesis.atrad.adelaide.edu.au> Subject: Re: Ownership of files/tcp_wrappers port To: p.richards@elsevier.co.uk (Paul Richards) Date: Thu, 25 Jan 1996 11:32:13 +1030 (CST) Cc: security@freebsd.org In-Reply-To: <199601242008.UAA19526@cadair.elsevier.co.uk> from "Paul Richards" at Jan 24, 96 08:08:31 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk Paul Richards stands accused of saying: > > > Bin has no shell. (See below). Few or no binaries are ever setuid bin. > > Umm, bin does have a shell > > bin:*:3:7:Binaries Commands and Source,,,:/:/bin/sh Bin does _not_ have a shell. I had finished a 2.1 install a few minutes before I wrote that message, and I checked my facts. If your bin has a shell, it's either because you gave it one, or because you've upgraded from a previous version. > This is what segregation of privilages is all about. Making a lot more > of the system owned by root just increases the number of potential pitfalls > facing sysadmins. Agreed. > Paul Richards. Originative Solutions Ltd. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-security Wed Jan 24 17:09:03 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA07615 for security-outgoing; Wed, 24 Jan 1996 17:09:03 -0800 (PST) Received: from sasami.jurai.net (root@sasami.jurai.net [205.218.122.51]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA07601 for ; Wed, 24 Jan 1996 17:08:51 -0800 (PST) Received: (from winter@localhost) by sasami.jurai.net (8.6.11/8.6.9) id TAA16800; Wed, 24 Jan 1996 19:08:30 -0600 Date: Wed, 24 Jan 1996 19:08:30 -0600 (CST) From: "Matthew N. Dodd" X-Sender: winter@sasami To: Paul Traina cc: Tom Samplonius , Nathan Lawson , security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <199601230840.AAA02300@precipice.shockwave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Tue, 23 Jan 1996, Paul Traina wrote: > Not every piece of software out there that people deem worthwhile BELONGS > as part of the base system. Most people couldn't give a darn about > the logging or wrapping that either xinetd or tcp-wrappers perform, both > programs are welcome as ports, but not welcome as part of the core system, > thankyouverymuch. cool, please remove window(1) as it is a total waste of disk. Screen is so much nicer. :) | Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter | | Technical Manager | mdodd@intersurf.net | http://www.intersurf.net | | InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"| From owner-freebsd-security Wed Jan 24 17:32:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA09477 for security-outgoing; Wed, 24 Jan 1996 17:32:52 -0800 (PST) Received: from sasami.jurai.net (root@sasami.jurai.net [205.218.122.51]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA09459 for ; Wed, 24 Jan 1996 17:32:46 -0800 (PST) Received: (from winter@localhost) by sasami.jurai.net (8.6.11/8.6.9) id TAA17588; Wed, 24 Jan 1996 19:32:39 -0600 Date: Wed, 24 Jan 1996 19:32:38 -0600 (CST) From: "Matthew N. Dodd" X-Sender: winter@sasami To: Paul Traina cc: dk+@UA.net, freebsd-security@FreeBSD.ORG Subject: Re: rxvt security hole - proposed fix + more In-Reply-To: <199601232118.NAA02408@precipice.shockwave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk On Tue, 23 Jan 1996, Paul Traina wrote: > And yes I know rxvt have to be fixed to drop its privileges when using > -print-pipe anyway. > Correction, rxvt has been fixed to drop its privileges when they're not > required (which is when editing utmp). I've got a few other pateches to rxvt-2.10 that fix some annoying color problems. (Ever notice you can't see dark grey?) 2.10 fixes the ^[[0m bug as well. | Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter | | Technical Manager | mdodd@intersurf.net | http://www.intersurf.net | | InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"| From owner-freebsd-security Wed Jan 24 17:34:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA09630 for security-outgoing; Wed, 24 Jan 1996 17:34:48 -0800 (PST) Received: from gateway.fedex.com (gateway.fedex.com [198.80.10.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA09625 for ; Wed, 24 Jan 1996 17:34:45 -0800 (PST) Received: by gateway.fedex.com id AA23162 (InterLock SMTP Gateway 3.0 for security@freebsd.org); Wed, 24 Jan 1996 19:34:42 -0600 X-Disclaimer: THE COMMENTS CONTAINED IN THIS MESSAGE REFLECT THE VIEWS OF THE WRITER AND ARE NOT NECESSARILY THE VIEWS OF FEDERAL EXPRESS CORPORATION. Message-Id: <199601250134.AA23162@gateway.fedex.com> Received: by gateway.fedex.com (Internal Mail Agent-2); Wed, 24 Jan 1996 19:34:42 -0600 Received: by gateway.fedex.com (Internal Mail Agent-1); Wed, 24 Jan 1996 19:34:42 -0600 X-Authentication-Warning: dpd08.dpd.fedex.com: Host localhost didn't use HELO protocol To: security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port Organization: Federal Express Data Protection Distributed Projects Date: Wed, 24 Jan 1996 19:36:57 -0600 From: William McVey Sender: owner-security@freebsd.org Precedence: bulk >The real point against you're argument is segregation of priviliges. >Why give any more privilage to a binary than is necessary. The ownership of a file gives no privilege to the file unless it's setuid (and even then if you want to be a stickler to detail, the file doesn't get the increase in privileges, the user executing the file does). However, the owner of a file directly impacts on the protections available to it. Under Unix, there are basically two sets of users... root and everyone else. Root is treated special and has extra protections in a number of places meant to protect it from abuse (mapping to nobody with NFS, not honoring hosts.equiv, secure ttys, su only from group 0, etc.) Why make the owners of the binaries that root runs anything other than this protected account? >If a binary >doesn't need to be root then don't make it owned by root at all >and then if something goes wrong, like you mistakenly suid a bin binary >and not realise it, the possible damage is less than if it was a root >binary. This segregation is more to do with protecting sysadmins from >themselves than it is about preventing break-ins Nothing in the world that we do will keep sysadmins from potentially screwing themselves over. Besides this, using your own example, if some bin owned program becomes setuid, then the system is still compromised since with bin permissions you now have root by the nature that bin owns the executables that root runs. Having an unsecure program owned by bin made accidently setuid is just as bad as if the program had been owned by root (as demonstrated below). Your own argument shows that by having a "ghost" user own system critical files can cause administrators who may be inexperienced in security to not realize the ramifications of what has happened. >and the added >segragation is *NOT* a potential security hole since those uid's do not >have passwords and therefore *cannot* be cracked in and of themselves. I disagree. There are other ways into an account than by entering a password. The designers of the system have tried to restrict these entry points for the root id, but for regular users, this is simply not the case. >You *have* to crack root first. The point about bin is that the system >is not owned by an actual user. You gain nothing by having bin own files. Some have claimed it saves on administration details (saying you know it's binary file if it's owned by bin). To this I direct your attention to a lot of the bin owned files in /usr/bin which are not binary at all, but rather shell scripts (whatis, whoami, clear, cpp). If the intent is to show if they are programs or not, that's what the execute bit is for IMHO. >Another, related point, is that if someone does get access to bin, the >damage they can do is limited to the system binaries, you can't go >trashing other people's files. Sure they can... the path from user 'bin' is straightforward to root and from there to anyone. Once you're bin, replace /bin/sh with a program that attempts to chown some copy of the real borne shell to root and make it setuid (and then of course your trojan should invoke the real borne shell to not be detected). Once /bin/sh has been compromised, and run by root (which happens at least daily from /etc/daily) then the bad guy has a setuid root shell that can be used to garner full root privs which as we all know can be used to trash other people's files. Again, the fact that this wasn't intuitvly obvious just goes to show that having 'bin' ownership is misleading at best and downright insecure in practice. >To be honest, in a break-in situation >the system files are my least concern, if you're security minded you'll >be aware pretty soon if someone is messing with your system files and deal >with it. Detecting damage to users files is more difficult and in many >ways is more important, if someone cracks bin and takes your system down >you have outage while you restore, if someone trashed an users mission >critical data you're in big trouble. Granted user data is important, but how can system files be any less important? If I'm an admin for site that has been cracked, my primary concern will be making sure that the OS I'm running my users on won't be cracked again (or still); otherwise, no amount of work done to secure the user data will mean anything since there is nothing a user can do that will keep user files secure from a compromised root account. Even encryption requires the entering of a key or passphrase which root would have access to (a bad guy could read the passphrase directly out of memory or watch the keys strokes entered onto the tty). >Sysadmins make mistakes, if you make a potentially serious mistake with >a bin owned system binary the possible damage is limited to bin owned >files. Which I've demonstrated amounts to a compromise of the root account. >If you make a mistake with a root owned file it's a different matter. No, it's the same. >This is what segregation of privilages is all about. Making a lot more >of the system owned by root just increases the number of potential pitfalls >facing sysadmins. I strongly disagree. The 'bin' account has no additional protections on it than root does (this is obvious since root can become 'bin'). Yet root has numerous added protections. Why would we chose to have the most critical files on the system (the system executables) owned by an id with fewer than the maximum number of protections? -- William From owner-freebsd-security Wed Jan 24 18:12:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA12509 for security-outgoing; Wed, 24 Jan 1996 18:12:41 -0800 (PST) Received: from fire.stf.org.sg (fire.stf.org.sg [137.132.19.134]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA12494 for ; Wed, 24 Jan 1996 18:12:15 -0800 (PST) Received: (from jseng@localhost) by fire.stf.org.sg (8.6.12/8.6.9) id KAA22403; Thu, 25 Jan 1996 10:16:55 +0800 Date: Thu, 25 Jan 1996 10:16:55 +0800 (SGT) From: James Seng To: Nathan Lawson cc: Michael Smith , security@FreeBSD.org Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <199601241812.KAA12343@statler.csc.calpoly.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org Precedence: bulk On Wed, 24 Jan 1996, Nathan Lawson wrote: > Pardon me. I was thinking of the many other nologin accounts that had a > null shell (meaning /bin/sh by default). Actually, even if bin has /nonexistant as a shell in passwd, it can still be login in various ways (rsh -l bin /bin/sh -i). In either case, one more account, one more trouble..but somehow, i still prefer BSD ways of letting bin own the binaries and not root like Linux..dunno why *8) Perhaps i think root have too much power? It seem like none or all solution. In this aspect VMS is better i guess. > It doesn't matter if your NFS mounts are nosuid. They have to be > read-only too. Think about this: you export /usr/bin to some diskless > FreeBSD client. Some guy gets root on that client, does an su bin, and > replaces /usr/bin/login with some script to start a shell on a port. Now > all he has to do is telnet to your machine, telnetd starts up login, and > it pops up his root shell on another port. Speaking of NFS, anyone knows how secure is FreeBSD NFS? I remember there used to be a case whereby NFS filehandle can be easily guessed..does it still exist here or FreeBSD is using the DES-key? > How about hosts.equiv? Joe User gets root access on a machine. He can rlogin > to the server as any user. What user would get him more privileges? Well, > he can't login as root since hosts.equiv doesn't allow that. So, he rlogins > as bin, replaces some key binaries, and you have the same compromised state. In that case, i guess the system admin should wake up a bit *8) Anyone who see bin in that wtmp got to do something fast... It is funny that we have access control on telnetd (or is it logind?), that is who and who is able to login thru telnet, but we have no access control on rlogin, rsh etc...hmm... > It hurts security. I still have yet to hear a good reason why bin ownership > has even one advantage over root. Lets see...because we dont like root to have too much privelliges? *8)))))) (sorry, i couldnt think of a good reason either but i support the idea for bin to own binaries..hehe *8) -James Seng (jseng@stf.org.sg) From owner-freebsd-security Wed Jan 24 21:24:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA03741 for security-outgoing; Wed, 24 Jan 1996 21:24:20 -0800 (PST) Received: from argus.flash.net (root@[206.149.24.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA03729 for ; Wed, 24 Jan 1996 21:24:15 -0800 (PST) Received: (from lists@localhost) by argus.flash.net (8.6.12/8.6.12) id XAA01557; Wed, 24 Jan 1996 23:23:57 -0600 From: mailing list account Message-Id: <199601250523.XAA01557@argus.flash.net> Subject: Re: Ownership of files/tcp_wrappers port To: winter@jurai.net (Matthew N. Dodd) Date: Wed, 24 Jan 1996 23:23:57 -0600 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: from "Matthew N. Dodd" at Jan 24, 96 07:08:30 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org Precedence: bulk In reply: > > programs are welcome as ports, but not welcome as part of the core system, > > thankyouverymuch. > > cool, please remove window(1) as it is a total waste of disk. > > Screen is so much nicer. :) good idea! Jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@argus.flash.net - FlashNet Communications - Ft. Worth, Texas From owner-freebsd-security Wed Jan 24 22:38:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA11594 for security-outgoing; Wed, 24 Jan 1996 22:38:01 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA11587 for ; Wed, 24 Jan 1996 22:37:59 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id WAA13006; Wed, 24 Jan 1996 22:37:49 -0800 From: Nathan Lawson Message-Id: <199601250637.WAA13006@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: lists@argus.flash.net (mailing list account) Date: Wed, 24 Jan 1996 22:37:48 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199601242145.PAA00691@argus.flash.net> from "mailing list account" at Jan 24, 96 03:44:59 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > In reply: > > I think you misunderstand. The PARANOID and RFC931 options can be added to > > the hosts.* file to enable them, even if the compiled binary has them disabled > > by default. This allows you to use a stripped-down default version, but > > upgrade it to as strict as you wish (even being stricter per service). > > RFC931 can be faked out with almost no effort... it's only legitimate > authentication use is over a TRUSTED network for casual identification of > who is using a service, and even then.... > > ------ from RFC931.TXT -------------------------------------------------- [much off-topic info deleted] > ------ End -------------------------------------------------------------- Uh, where did I say that _I_ wanted to enable ident checking? Re-read what I said above. All I said was that you can compile one binary that can be very permissive by default, but each system manager can add the flags into a file to enable PARANOID or RFC931 as he or she wishes. I did not make any statements as to the merits of either of these options. Like you say below, there are many different types of systems out there, and each should have the option to enable whatever feature they wish (and for whatever reason they have). > > > Before we get over paranoid over security, lets us remember that the > > > primary aim of a base distribution is to provide an dynamic system, of > > > course minus the security bugs. > > > > Well, then FreeBSD has failed. See the recent telnetd environment bug for > > an example of this. If you had wrapped telnetd and only allowed connects > > from certain sites, you could have limited the scope of this vulnerability. > > >> Bugs are going to show up no matter what. If having the extra logging and easy > > access control of tcp_wrappers at the installer's fingertips could have > > prevented even one breakin, I'd be all for it. > > the idea in computer security is not to be paranoid, that gets in the way of > getting things done. the idea is usually to use some common sense though. >such things as permissions alone can help thwart a hacker once he is in, making > everything root:wheel when all that is needed is to remove the read bits from > a binary is stupid and potentially dangerous. Huh? So you are saying that making a binary unreadable is better than chowning it to root? I'm sorry, unreadable binaries are security through obscurity, while root ownership prevents a certain class of trojan horse attack. Which would you rather have: an intruder get bin access and trojan /usr/bin/login or have them break in and not be able to read /stand/ls? > as far as security packages, as i said before, you may like tcp_wrappers, i > may do something different, and joe blow up the net may not do anything at all > [to his demise]... let's not standardize on anything in particular, just > support as much as possible. This is respectable. Perhaps we can get the logging that the FreeBSD rlogin/ rsh support installed in the other network binaries as well. How about more example ipfw configs so that ipfw can be used as easily as tcp_wrappers for first-time admins? What I want is to get some kind of standard logging for all the network binaries, and easily configurable access control for the entire distribution. > > > IMHO, so long the base code is clean and no loopholes exist, it should > > > be good enough. Lets not blob the bindist further unneccessary... > > > > Ok. You can go through and prove all the code in FreeBSD and I'll look over > > your results. If you can't find any loopholes, but I can, do I get a free > > lunch? :) > > AXIOM 1). Security holes will ALWAYS exist. > > tell me how the lunch goes... Well, you said above that "if the code has no loopholes, it's good enough [and Nate's suggestions aren't necessary]". I'm saying that it does have loopholes (and you appear to be too), therefore your first statement is not valid, and the code is _not_ "good enough". > i know that i said this before, but i WILL say it again... one thing i'd like > to see is the majority of the binaries set to chmod 711 in the distribution. > this is simple enough to implement, and should not harm the functionality of > anything. I think there is a small security gain from this, but not much considering the availability of the sources. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Wed Jan 24 22:59:22 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA14095 for security-outgoing; Wed, 24 Jan 1996 22:59:22 -0800 (PST) Received: from statler.csc.calpoly.edu (statler-srv.csc.calpoly.edu [129.65.241.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA14087 for ; Wed, 24 Jan 1996 22:59:19 -0800 (PST) Received: (from nlawson@localhost) by statler.csc.calpoly.edu (8.6.12/N8) id WAA13034; Wed, 24 Jan 1996 22:55:46 -0800 From: Nathan Lawson Message-Id: <199601250655.WAA13034@statler.csc.calpoly.edu> Subject: Re: Ownership of files/tcp_wrappers port To: p.richards@elsevier.co.uk (Paul Richards) Date: Wed, 24 Jan 1996 22:55:46 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199601242008.UAA19526@cadair.elsevier.co.uk> from "Paul Richards" at Jan 24, 96 08:08:31 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > In reply to Nathan Lawson who said > > > > > Nathan Lawson stands accused of saying: > > > > This "someone" is not well-protected enough to own critical things > > > > like binaries. Until you can prove to me that a bin compromise is > > > > as hard as a root compromise, I won't relent. Consider NFS, > > > > hosts.equiv, and login. None of those will stop a bin intrusion. > > > > If you can log in as bin, login will let you. If you can access a > > > > filesystem via NFS, bin access is allowed while root is mapped to > > > > nobody. Hosts.equiv allows _every_ user except root to access the > > > > equivalent account. > > > > > > Bin has no shell. (See below). Few or no binaries are ever setuid bin. > > The real point against you're argument is segregation of priviliges. > Why give any more privilage to a binary than is necessary. If a binary > doesn't need to be root then don't make it owned by root at all > and then if something goes wrong, like you mistakenly suid a bin binary > and not realise it, the possible damage is less than if it was a root > binary. This is the only argument that is even close to plausible. But if you make a binary setuid bin mistakenly, your system is still compromised. Let's say I get a uid-bin shell. Now, I can copy my little script that makes a setuid root shell in /tmp to /usr/libexec/telnetd. Then, type "telnet localhost" and you get a root shell in /tmp. You haven't bought anything by making everything owned by bin. > This segregation is more to do with protecting sysadmins from > themselves than it is about preventing break-ins Well, it doesn't work, then, because you've still got a root compromise as shown above. >and the added > segragation is *NOT* a potential security hole since those uid's do not > have passwords and therefore *cannot* be cracked in and of themselves. > You *have* to crack root first. The point about bin is that the system > is not owned by an actual user. It seems no one is paying attention to my previous points about how to get the bin access in the first place. To reiterate: NFS, hosts.equiv, and NIS. See my previous mail for exploit examples. None of them require bin to have a crackable password or any password at all. > Another, related point, is that if someone does get access to bin, the > damage they can do is limited to the system binaries, you can't go > trashing other people's files. Nope. Bin access on any site that has binaries owned by bin is instant root access. THEN, you go trash everyone's files. > To be honest, in a break-in situation > the system files are my least concern, if you're security minded you'll > be aware pretty soon if someone is messing with your system files and deal > with it. ---- (use NFS to claim I am uid bin on client) client% nfs -u 3 server:/usr client% cp server:/usr/libexec/telnetd /tmp ---- (my-inetd.sh is a simple shell script that starts inetd on a port with ---- /bin/sh) client% cp my-inetd.sh server:/usr/libexec/telnetd client% telnet server Trying 129.XX.XX.XX Connected to XXXX Escape character is '^]'. Connection closed by foreign host. client% telnet server 7002 Trying 129.XX.XX.XX Connected to XXXX Escape character is '^]'. whoami; root : Command not found cp /tmp/telnetd /usr/libexec; : Command not found touch /usr/libexec/telnetd; : Command not found ^D Connection closed by foreign host. This is just one example where the system files _should_ be of your concern. Once again, binary files are run by root, some at the will of the user (telnetd in my example). You don't have to wait for root to log in and type "ls" or whatever. My point stands that bin access is easier than root and it is equivalent to root, once obtained. >Detecting damage to users files is more difficult and in many > ways is more important, if someone cracks bin and takes your system down > you have outage while you restore, if someone trashed an users mission > critical data you're in big trouble. In this case, I think an rm -rf / would do both. > Sysadmins make mistakes, if you make a potentially serious mistake with > a bin owned system binary the possible damage is limited to bin owned > files. If you make a mistake with a root owned file it's a different matter. > This is what segregation of privilages is all about. Making a lot more > of the system owned by root just increases the number of potential pitfalls > facing sysadmins. Your point is good, if this wasn't Unix. If you could make a user on a Unix box that could only own binaries, but never execute or write to them, you'd have a better layout of privileges. But this is Unix and we are constrained to the all or nothing world of root access. Root is a better protected account than bin. Once you are root, yes, you can write to root-owned and bin-owned files. But the converse does not hold: once you are bin, you can write to bin-owned files, but not root-owned files. Why go with the account that offers the least security? -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Wed Jan 24 23:15:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA15364 for security-outgoing; Wed, 24 Jan 1996 23:15:18 -0800 (PST) Received: from gateway.fedex.com (gateway.fedex.com [198.80.10.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA15357 for ; Wed, 24 Jan 1996 23:15:15 -0800 (PST) Received: by gateway.fedex.com id AA27853 (InterLock SMTP Gateway 3.0 for security@freebsd.org); Thu, 25 Jan 1996 01:13:43 -0600 X-Disclaimer: THE COMMENTS CONTAINED IN THIS MESSAGE REFLECT THE VIEWS OF THE WRITER AND ARE NOT NECESSARILY THE VIEWS OF FEDERAL EXPRESS CORPORATION. Message-Id: <199601250713.AA27853@gateway.fedex.com> Received: by gateway.fedex.com (Internal Mail Agent-2); Thu, 25 Jan 1996 01:13:43 -0600 Received: by gateway.fedex.com (Internal Mail Agent-1); Thu, 25 Jan 1996 01:13:43 -0600 X-Authentication-Warning: dpd08.dpd.fedex.com: Host localhost didn't use HELO protocol To: James Seng Cc: security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port Date: Thu, 25 Jan 1996 01:15:57 -0600 From: William McVey Sender: owner-security@freebsd.org Precedence: bulk James Seng wrote: >Perhaps i think root have too much power? It seem like none or all solution. >In this aspect VMS is better i guess. Making a bin owner for system files does not fix this. Root's privileges come from a fundemental design of the operating system. I'm really skeptical that this could be corrected by user level changes on owners. The simple fact is you aren't taking any privileges away from root by creating the bin account. Root can always become 'bin' therefore putting your trust in the bin account doesn't keep root from being all powerful. >In that case, i guess the system admin should wake up a bit *8) Anyone >who see bin in that wtmp got to do something fast... The point is that wtmp is a detection tool. Once bin has logged in, its a straight path to root and wtmp is likely to be fixed to remove any indication of wrong doing. The real solution is to focus on prevention of the problem, not detection. The way to prevent this is to set the owners of critical system files (system binaries included) to be root. >It is funny that we have access control on telnetd (or is it >logind?), that is who and who is able to login thru telnet, but we have no >access control on rlogin, rsh etc...hmm... We have user level access control on telnet? How? The user isn't defined in starting a telnet session until the network has connected you to login. I think you may be confusing our recent discussions of tcpd, which does host based access control. But this is available on the rsh suite of tools as well. >> It hurts security. I still have yet to hear a good reason why bin ownership >> has even one advantage over root. >Lets see...because we dont like root to have too much privelliges? *8)))))) >(sorry, i couldnt think of a good reason either but i support the idea for > bin to own binaries..hehe *8) I assume the smileys indicate massive sarcasm. -- William From owner-freebsd-security Thu Jan 25 03:29:19 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA17978 for security-outgoing; Thu, 25 Jan 1996 03:29:19 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA17969 for ; Thu, 25 Jan 1996 03:29:12 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id LAA02697 for ; Thu, 25 Jan 1996 11:27:22 GMT Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Thu, 25 Jan 1996 11:27:31 +0000 Received: (from dpr@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id LAA22260; Thu, 25 Jan 1996 11:27:33 GMT From: Paul Richards Message-Id: <199601251127.LAA22260@cadair.elsevier.co.uk> Subject: Re: Ownership of files/tcp_wrappers port To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 25 Jan 1996 11:27:32 +0000 (GMT) Cc: security@FreeBSD.org In-Reply-To: <199601250102.LAA28536@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 25, 96 11:32:13 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.org Precedence: bulk In reply to Michael Smith who said > > Paul Richards stands accused of saying: > > > > Bin has no shell. (See below). Few or no binaries are ever setuid bin. > > > > Umm, bin does have a shell > > > > bin:*:3:7:Binaries Commands and Source,,,:/:/bin/sh > > Bin does _not_ have a shell. I had finished a 2.1 install a few minutes > before I wrote that message, and I checked my facts. If your bin has > a shell, it's either because you gave it one, or because you've > upgraded from a previous version. > Hmm, I certainly didn't add it and I was a little surprised to find it. Did we fix this post 2.0.5 since that's what the box started off as. -- Paul Richards. Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-security Thu Jan 25 03:40:29 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA18529 for security-outgoing; Thu, 25 Jan 1996 03:40:29 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA18524 for ; Thu, 25 Jan 1996 03:40:24 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id LAA02746 for ; Thu, 25 Jan 1996 11:38:35 GMT Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Thu, 25 Jan 1996 11:38:45 +0000 Received: (from dpr@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id LAA24328 for security@FreeBSD.org; Thu, 25 Jan 1996 11:38:48 GMT From: Paul Richards Message-Id: <199601251138.LAA24328@cadair.elsevier.co.uk> Subject: bin owned files To: security@FreeBSD.org Date: Thu, 25 Jan 1996 11:38:47 +0000 (GMT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.org Precedence: bulk I'l summarise all the point against what I said briefly. Getting bin access does not give you root access. As bin you can't touch root files and you can't create a suid root file either. Users can't give away ownership. Therefore, the only way to get root access from bin is to replace, say, /bin/sh with a program that creates a suid root sh *when it is run by root*. If you log in as root and don't realise that there has been a compromise of bin then that is your problem but in and of itself a bin compromise is safer than a root compromise for the reasons I previously explained. All other arguments relate to NFS and I refuse to even discuss NFS in this context. If you crack root anywhere on an NFS system then the whole system is compromised and while making things owned by root makes it a little harder it is no protection. I can masquerade as many other users and find other ways to do what I want. The whole point is, there *was* a root break-in, the fact that it wasn't the actual server box is not an issue. NFS cannot be regarded as a number of separate machines from a security context, a compromise on one is a compromise on them all. -- Paul Richards. Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-security Thu Jan 25 07:21:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA26065 for security-outgoing; Thu, 25 Jan 1996 07:21:59 -0800 (PST) Received: from gateway.fedex.com (gateway.fedex.com [198.80.10.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA26060 for ; Thu, 25 Jan 1996 07:21:55 -0800 (PST) Received: by gateway.fedex.com id AA04710 (InterLock SMTP Gateway 3.0 for security@freebsd.org); Thu, 25 Jan 1996 09:17:10 -0600 X-Disclaimer: THE COMMENTS CONTAINED IN THIS MESSAGE REFLECT THE VIEWS OF THE WRITER AND ARE NOT NECESSARILY THE VIEWS OF FEDERAL EXPRESS CORPORATION. Message-Id: <199601251517.AA04710@gateway.fedex.com> Received: by gateway.fedex.com (Internal Mail Agent-2); Thu, 25 Jan 1996 09:17:10 -0600 Received: by gateway.fedex.com (Internal Mail Agent-1); Thu, 25 Jan 1996 09:17:10 -0600 X-Authentication-Warning: dpd08.dpd.fedex.com: Host localhost didn't use HELO protocol To: Paul Richards Cc: security@freebsd.org Subject: Re: bin owned files Date: Thu, 25 Jan 1996 09:19:23 -0600 From: William McVey Sender: owner-security@freebsd.org Precedence: bulk Paul Richards wrote: >Therefore, the only way to get root access from >bin is to replace, say, /bin/sh with a program that creates a suid root >sh *when it is run by root*. Which occurs whenever cron executes something on behalf of root. How about all those executables owned by bin but run by root from within inetd? How about init? or /bin/login (which may not be owned by bin, but is in a bin-owned directory, so is therefore exposed). >If you log in as root and don't realise that >there has been a compromise of bin then that is your problem but in and >of itself a bin compromise is safer than a root compromise for the >reasons I previously explained. There have been several examples given where the real administrator plays no role in running the trojan horse... running executables is a system function root performs all the time, not just during interactive login sessions. >All other arguments relate to NFS and I refuse to even discuss NFS in this >context. If you crack root anywhere on an NFS system then the whole >system is compromised and while making things owned by root makes it >a little harder it is no protection. I can masquerade as many other users >and find other ways to do what I want. The whole point is, there *was* >a root break-in, the fact that it wasn't the actual server box is not an >issue. NFS cannot be regarded as a number of separate machines from >a security context, a compromise on one is a compromise on them all. No, this is not necessarly the case. I was an administrator for a lab of 200+ workstations with NFS mounts from a few central file servers. A compromise on one the workstations (in a public lab with few real physical security precautions) did *NOT* result in a compromise of the servers. The clients were considered expendible since they were reloaded every semester. User data was at risk, but this was well known and instructors were informed to not keep sensitive data on the lab cluster. -- William From owner-freebsd-security Thu Jan 25 07:31:26 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA26595 for security-outgoing; Thu, 25 Jan 1996 07:31:26 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA26588 for ; Thu, 25 Jan 1996 07:31:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.3/8.6.10) with SMTP id HAA16987; Thu, 25 Jan 1996 07:30:29 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199601251530.HAA16987@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: James Seng cc: Nathan Lawson , Michael Smith , security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Thu, 25 Jan 96 10:16:55 +0800." Date: Thu, 25 Jan 96 07:30:29 -0800 X-Mts: smtp Sender: owner-security@freebsd.org Precedence: bulk James Seng wrote: > On Wed, 24 Jan 1996, Nathan Lawson wrote: > > Pardon me. I was thinking of the many other nologin accounts that had a > > null shell (meaning /bin/sh by default). > > Actually, even if bin has /nonexistant as a shell in passwd, it can > still be login in various ways (rsh -l bin /bin/sh -i). In either > case, one more account, one more trouble..but somehow, i still prefer BSD > ways of letting bin own the binaries and not root like Linux..dunno why *8) > Perhaps i think root have too much power? It seem like none or all solution. > In this aspect VMS is better i guess. The reason bin exists in the first place is that when doing system maintenance you su to bin, do your maintenance, and exit. This protects the sysadmin from access to too much preventing the obvious fat finger type of mistakes. The protection bin is supposed to give the sysadmin is that access to user and critical system files is limited thereby limiting any potential damage done during system maintenance. I don't know of anyone who follows this discipline nor do I know of any vendor who promotes it either. Other than attempting to promote a management discipline, the ownership by bin of binaries on a local filesystem has little relevance, while on filesystems exported with write privileges it has more relevance. Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Thu Jan 25 15:20:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA16777 for security-outgoing; Thu, 25 Jan 1996 15:20:46 -0800 (PST) Received: from multivac.orthanc.com (root@multivac.orthanc.com [206.12.238.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA16763 for ; Thu, 25 Jan 1996 15:20:33 -0800 (PST) Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7.3/8.7.3) with SMTP id PAA07296; Thu, 25 Jan 1996 15:18:31 -0800 (PST) Message-Id: <199601252318.PAA07296@multivac.orthanc.com> X-Authentication-Warning: multivac.orthanc.com: Host lyndon@localhost didn't use HELO protocol From: Lyndon Nerenberg VE7TCP To: Paul Richards cc: security@freebsd.org Subject: Re: bin owned files In-reply-to: Your message of "Thu, 25 Jan 1996 11:38:47 GMT." <199601251138.LAA24328@cadair.elsevier.co.uk> Date: Thu, 25 Jan 1996 15:18:26 -0800 Sender: owner-security@freebsd.org Precedence: bulk >>>>> "Paul" == Paul Richards I am having a really tough time wrapping my head around this. Paul> Getting bin access does not give you root access. and then Therefore, the only Paul> way to get root access from bin is to replace, say, /bin/sh Paul> with a program that creates a suid root sh *when it is run Paul> by root*. Well, which one is it? Your own example completely invalidates your first assertion. If there is an implied "immediately" in "does not give you root access," please say so. Your own example shows that bin access allows root access. How quickly is based soley upon "bin's" skill. Paul> If you log in as root and don't realise that there Paul> has been a compromise of bin then that is your problem but Paul> in and of itself a bin compromise is safer than a root Paul> compromise for the reasons I previously explained. What reasons? Again, Again I invoke your example above. How is this "safer" than if the files were root owned? Paul> All other arguments relate to NFS and I refuse to even Paul> discuss NFS in this context. Why? If the argument breaks your proof, ignoring the argument does not make your proof valid. Paul> If you crack root anywhere on Paul> an NFS system then the whole system is compromised and while Paul> making things owned by root makes it a little harder it is Paul> no protection. I'm still not clear on why root ownership is "no protection?" To my way of thinking, there is little *effective* difference in actual security in the root-vs-bin ownership case, other than the greater ease in attacking non-root files over NFS. Someone else mentioned that bin ownership helped save administrators from themselves. I invite any of you to run 'rm -rf /' under bin's uid (as per the "accidentally chmod u+s a bin owned program" example given previously), and tell us the results. What all of this demonstrates is that having certain files owned by bin gives you nothing more than a false sense of security. I don't know the origin of the bin id. Can anyone out there state *definitively* the reason for bin's creation? My gut feeling is that it was created to make 'ls -l' look a bit prettier, and vendors have been blindly copying the convention for years now without giving any thought as to the real need for such an account. Things have changed a lot since the days of seventh edition (or wherever bin appeared - it's been around for as long as I can remember), and maybe it's time we rethought the reasons for, and consequences of, a seperate bin id? --lyndon From owner-freebsd-security Fri Jan 26 01:37:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA26593 for security-outgoing; Fri, 26 Jan 1996 01:37:54 -0800 (PST) Received: from toadflax.cs.ucdavis.edu (toadflax.cs.ucdavis.edu [128.120.56.188]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA26586 for ; Fri, 26 Jan 1996 01:37:50 -0800 (PST) Received: by toadflax.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA00228; Fri, 26 Jan 96 01:37:35 PST From: obrien@cs.ucdavis.edu (David E. O'Brien) Message-Id: <9601260937.AA00228@toadflax.cs.ucdavis.edu> Subject: Re: Ownership of files/tcp_wrappers port To: security@freebsd.org Date: Fri, 26 Jan 1996 01:37:32 -0800 (PST) In-Reply-To: <199601250134.AA23162@gateway.fedex.com> from "William McVey" at Jan 24, 96 07:36:57 pm X-Mailer: ELM [version 2.4 PL24 ME8b] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > If you're paranoid, your NFS mounts are nosuid. I'd say bin was of > comparable secureness to root. Root is, however, more likely to be stupid > and use their password in cleartext over the 'net or be shoulder-snooped. Nope, I've used the NFS mount someone's disk on my machine where I have root, several times to fix problems when the other "sysadmins" didn't maintain their boxes very well. Much easier than trying to explain to them how to fix things. I did this with OUT sniffing or shoulder-snooping. In fact NFS'ing and su bin'ing is _SO_ much easier. Exporting read-only would help reduce this ability, but if I remember correctly, there is a bug/hole where you can still trick out NFS to write to such an exported disk. As demonistrated by Nathan Lawson , having system binaries owned by ``bin'' has serious security flaws that would be reduced by having them owned by ``root'', the *real* question is how do we go about _offically_ changing this? Petition JKH? Find a sympathic ear on the Core team? -- David (obrien@cs.ucdavis.edu) From owner-freebsd-security Fri Jan 26 01:51:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA27421 for security-outgoing; Fri, 26 Jan 1996 01:51:34 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA27415 for ; Fri, 26 Jan 1996 01:51:28 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id JAA05491 for ; Fri, 26 Jan 1996 09:49:35 GMT Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Fri, 26 Jan 1996 09:49:42 +0000 Received: (from dpr@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id JAA11440; Fri, 26 Jan 1996 09:49:43 GMT From: Paul Richards Message-Id: <199601260949.JAA11440@cadair.elsevier.co.uk> Subject: Re: Ownership of files/tcp_wrappers port To: obrien@cs.ucdavis.edu (David E. O'Brien) Date: Fri, 26 Jan 1996 09:49:41 +0000 (GMT) Cc: security@FreeBSD.org In-Reply-To: <9601260937.AA00228@toadflax.cs.ucdavis.edu> from "David E. O'Brien" at Jan 26, 96 01:37:32 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.org Precedence: bulk In reply to David E. O'Brien who said > > As demonistrated by Nathan Lawson , > having system binaries owned by ``bin'' has serious security flaws that > would be reduced by having them owned by ``root'', the *real* question is > how do we go about _offically_ changing this? > guys, these are NFS problems. If you want to stop people su'ing to bin then map bin to nobody as well. -- Paul Richards. Originative Solutions Ltd. Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk Phone: 0370 462071 (Mobile), +44 1225 447500 (work) From owner-freebsd-security Fri Jan 26 01:57:40 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA27919 for security-outgoing; Fri, 26 Jan 1996 01:57:40 -0800 (PST) Received: from toadflax.cs.ucdavis.edu (toadflax.cs.ucdavis.edu [128.120.56.188]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA27914 for ; Fri, 26 Jan 1996 01:57:37 -0800 (PST) Received: by toadflax.cs.ucdavis.edu (4.1/UCD.CS.2.6) id AA00572; Fri, 26 Jan 96 01:57:35 PST From: obrien@cs.ucdavis.edu (David E. O'Brien) Message-Id: <9601260957.AA00572@toadflax.cs.ucdavis.edu> Subject: Re: Ownership of files/tcp_wrappers port To: security@freeBsd.org Date: Fri, 26 Jan 1996 01:57:33 -0800 (PST) In-Reply-To: <199601260949.JAA11440@cadair.elsevier.co.uk> from "Paul Richards" at Jan 26, 96 09:49:41 am X-Mailer: ELM [version 2.4 PL24 ME8b] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freeBsd.org Precedence: bulk > In reply to David E. O'Brien who said > > > > As demonistrated by Nathan Lawson , > > having system binaries owned by ``bin'' has serious security flaws that > > would be reduced by having them owned by ``root'', the *real* question is > > how do we go about _offically_ changing this? > > guys, these are NFS problems. If you want to stop people su'ing to bin > then map bin to nobody as well. Fine, then lets get this configured as the default. Most sysadmin's don't know to do this. Why should FreeBSD be that much easier to break-ins straight from the box? Aren't the open, easy to exploit holes the ones we hate from other vendors. Are these the type of things we often feel the other vendors are being careless irresponsible about? If we know of an easy to abuse security related problem shouldn't we fix it? Weren't most of the vulerablities used by the RTM worm known? Why didn't those syadmin's replace those programs??? Either they didn't know themselves, or because of the work load, there were so many other "higher-priority" tasks to work on. -- David (obrien@cs.ucdavis.edu) From owner-freebsd-security Fri Jan 26 03:13:27 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA01347 for security-outgoing; Fri, 26 Jan 1996 03:13:27 -0800 (PST) Received: from sasami.jurai.net (root@sasami.jurai.net [205.218.122.51]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA01342 for ; Fri, 26 Jan 1996 03:13:24 -0800 (PST) Received: (from winter@localhost) by sasami.jurai.net (8.6.11/8.6.9) id FAA02107; Fri, 26 Jan 1996 05:13:20 -0600 Date: Fri, 26 Jan 1996 05:13:20 -0600 (CST) From: "Matthew N. Dodd" X-Sender: winter@sasami To: "David E. O'Brien" cc: security@freeBsd.org Subject: Re: Ownership of files/tcp_wrappers port In-Reply-To: <9601260957.AA00572@toadflax.cs.ucdavis.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freeBsd.org Precedence: bulk On Fri, 26 Jan 1996, David E. O'Brien wrote: > Fine, then lets get this configured as the default. Most sysadmin's > don't know to do this. Why should FreeBSD be that much easier to > break-ins straight from the box? Can we get secure portmapper in as well? (ok, haha, secure...) I really like being able to restrict RPC services to those hosts I "trust" :) | Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter | | Technical Manager | mdodd@intersurf.net | http://www.intersurf.net | | InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"| From owner-freebsd-security Fri Jan 26 05:58:24 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA05919 for security-outgoing; Fri, 26 Jan 1996 05:58:24 -0800 (PST) Received: from helix.nih.gov (helix.nih.gov [128.231.2.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA05914 for ; Fri, 26 Jan 1996 05:58:22 -0800 (PST) Received: (from crtb@localhost) by helix.nih.gov (8.6.12/8.6.12) id IAA04922; Fri, 26 Jan 1996 08:58:21 -0500 Date: Fri, 26 Jan 1996 08:58:21 -0500 From: Chuck Bacon Message-Id: <199601261358.IAA04922@helix.nih.gov> To: Lyndon Nerenberg VE7TCP Subject: Re: bin owned files Cc: security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk > >>>>> "Paul" == Paul Richards > > I am having a really tough time wrapping my head around this. > > Paul> Getting bin access does not give you root access. > > and then > > Therefore, the only > Paul> way to get root access from bin is to replace, say, /bin/sh > Paul> with a program that creates a suid root sh *when it is run > Paul> by root*. This wrangle has been going on for weeks now, and I wonder why nobody has mentioned chflags(1): # chflags -R schg /bin # chflags -R schg /sbin # chflags -R schg /usr/sbin # (protect additional directories too) Anyone with root access can destroy a system, but this makes it harder. Chuck Bacon - crtb@helix.nih.gov ABHOR SECRECY - DEFEND PRIVACY From owner-freebsd-security Fri Jan 26 12:01:47 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA22503 for security-outgoing; Fri, 26 Jan 1996 12:01:47 -0800 (PST) Received: from gateway.fedex.com (gateway.fedex.com [198.80.10.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA22491 for ; Fri, 26 Jan 1996 12:01:40 -0800 (PST) Received: by gateway.fedex.com id AA03214 (InterLock SMTP Gateway 3.0 for security@FreeBSD.ORG); Fri, 26 Jan 1996 13:56:29 -0600 X-Disclaimer: THE COMMENTS CONTAINED IN THIS MESSAGE REFLECT THE VIEWS OF THE WRITER AND ARE NOT NECESSARILY THE VIEWS OF FEDERAL EXPRESS CORPORATION. Message-Id: <199601261956.AA03214@gateway.fedex.com> Received: by gateway.fedex.com (Internal Mail Agent-2); Fri, 26 Jan 1996 13:56:29 -0600 Received: by gateway.fedex.com (Internal Mail Agent-1); Fri, 26 Jan 1996 13:56:29 -0600 X-Authentication-Warning: dpd08.dpd.fedex.com: Host localhost didn't use HELO protocol To: Paul Richards Cc: security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port Date: Fri, 26 Jan 1996 13:58:36 -0600 From: William McVey Sender: owner-security@FreeBSD.ORG Precedence: bulk Paul Richards wrote: >guys, these are NFS problems. If you want to stop people su'ing to bin >then map bin to nobody as well. I don't think this is the right approach. I believe it has been shown that if the user 'bin' owns executables run by root, then bin access equals root access. I've not seen any reasons why a bin owner is a good thing other than a supposedly seperation of root privileges; however, this "seperation" doesn't take any privileges away from root and therefore the 'bin' ownership isn't accomplishing anything. I am at a lost as to why we'd want to build band-aids to gloss over a problem, rather than the problem itself. It has been mentioned before that UNIX was designed to have a single well protected administrative id (root). Why would we want multiple accounts that now need to have an equivalent amount of protection? You suggest that we should fix the NFS to treat 'bin' special as well as root. This is the wrong approach. Root is treated special by NFS because it *IS* special. The 'bin' user is not inherently special other than the fact that it has been made the owner of files that can be used to break root. The bug here is not that NFS treats 'bin' as any other user since it *is* just a regular user (ie it's not uid 0). The bug is that we allow the 'bin' user ownerships of files that can break the 'root' account. It's the ownership problem that is the bug. The original reason 'bin' was put on BSD systems in the first place was to give prettier output in quot(1) messages. People complained about the change then, but were basically ignored. It appears as if quot(1) isn't even distributed anymore (at least not on the user level distribution) so I don't think this is a big deal anymore. Even if it was still distributed, I don't think the original motiviation for the change is worth the security exposure it presents. -- William From owner-freebsd-security Fri Jan 26 22:41:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA28595 for security-outgoing; Fri, 26 Jan 1996 22:41:31 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA28589 for ; Fri, 26 Jan 1996 22:41:28 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id HAA18235 ; Sat, 27 Jan 1996 07:41:26 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id HAA07342 ; Sat, 27 Jan 1996 07:41:25 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id DAA24087; Sat, 27 Jan 1996 03:09:59 +0100 (MET) From: Ollivier Robert Message-Id: <199601270209.DAA24087@keltia.freenix.fr> Subject: Re: Ownership of files/tcp_wrappers port To: obrien@cs.ucdavis.edu (David E. O'Brien) Date: Sat, 27 Jan 1996 03:09:58 +0100 (MET) Cc: security@FreeBSD.org In-Reply-To: <9601260937.AA00228@toadflax.cs.ucdavis.edu> from "David E. O'Brien" at "Jan 26, 96 01:37:32 am" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1586 X-Mailer: ELM [version 2.4ME+ PL3 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org Precedence: bulk It seems that David E. O'Brien said: > would be reduced by having them owned by ``root'', the *real* question is > how do we go about _offically_ changing this? > > Petition JKH? Find a sympathic ear on the Core team? I'm not in the core team but FWIW you've got my vote... (for a long time). -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Sun Jan 14 20:23:45 MET 1996