From owner-freebsd-security Tue Jul 29 06:40:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA13106 for security-outgoing; Tue, 29 Jul 1997 06:40:33 -0700 (PDT) Received: from cyrus.watson.org (robert@cyrus.watson.org [207.86.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA13096 for ; Tue, 29 Jul 1997 06:40:30 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id JAA06132; Tue, 29 Jul 1997 09:40:16 -0400 (EDT) Date: Tue, 29 Jul 1997 09:40:16 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: Adam Shostack cc: robert+freebsd@cyrus.watson.org, vince@mail.MCESTATE.COM, security@FreeBSD.ORG Subject: Re: security hole in FreeBSD In-Reply-To: <199707291250.IAA12447@homeport.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 29 Jul 1997, Adam Shostack wrote: > I know no one who still runs uucp. There are a few holdouts, but most > systems can leave uucp off with no pain. Ditto with kerberos. :) Hey! I run Kerberos! :) Actually, the only Kerberos command that requires suid (that I know of) is register, which allows a user on a host to register into Kerberos if they weren't added there administratively by whoever created their account. It's a good migration tool if you have a few servers, NIS, etc, but no risk of overlapping names, but not actually used by very many people at all. In fact, I'm the only person I know of who has ever used it, although I know of quite a few people running Kerberos, especially in academic environments. Register could easily be made suid-something-else, and the keyfile it uses be changed to something-else. Perhaps a kerberos user should be created. Similarly, on the main Kerberos server, the kerberos daemon (and files) are owned by root. The kerberos daemon could be made to setuid() to a kerberos user once the bind() has taken place (plea for a non-root bind!) and run as non-root from then on fairly easily. Just because it's an authentication system doesn't mean it has to run as root. Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Security Research, Trusted Information Systems http://www.tis.com/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@tis.com http://www.watson.org/~robert/