Date: Fri, 16 Feb 2001 15:51:54 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Lyndon Nerenberg <lyndon@orthanc.ab.ca> Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <Pine.NEB.3.96L.1010216153010.59690B-100000@fledge.watson.org> In-Reply-To: <200102162010.f1GKAgq40421@orthanc.ab.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
robert@fledge.watson.org NAI Labs, Safeport Network Services On Fri, 16 Feb 2001, Lyndon Nerenberg wrote: > >>>>> "Robert" == Robert Watson <rwatson@FreeBSD.ORG> writes: > > Robert> do run Kerberos will suffer a great deal. My hope would > Robert> be that we'd keep supporting KerberosIV through the end of > Robert> the 4.x branch, and make KerberosV be the supported > Robert> Kerberos on 5.0-RELEASE, and have KerberosIV be a port. > > If there is a move to K5 for 5.x I think it's imperative that the > implementation fully support an existing deployed K4 infrastructure. > E.g. we use K4 everywhere in our shop. One of the critical applications > is kcvs. If the 5.x cvs cannot do kserver within our deployed K4 > infrastucture, 5.x will not be running on our infrastructure machines, > period. The same applies to a lesser extent with the kernerized r* > utilities. (And yes, we're about to deploy a testbed to start looking at > these interoperability issues.) K4 is going to be around for quite a > while (at least on the client side), and can't be ignored. I work in a number of primarily K4-based environments, and am aware of the issues here, and would similarly like (read: expect) to see them addressed. > Robert> One strong argument for disabling aspects of less well > Robert> maintained code in the base system is whether they > Robert> constitute a security risk by existing there unused. > > The issue here is the definition of "unused." I'm sure there are things > in the base that get used a _lot_ less than UUCP, and which aren't being > considered for removal. With UUCP in particular, we have to be *very* > careful not to let our first-world everyone-has-a-t1 view of the world > blind us to the reality that large parts of the planet do not have > ubiquitous and cheap IP connectivity. UUCP still provides a lot of > connectivity. And I think the arguments against keeping UUCP are > primarily FUD. I keep hearing about the security problems, but I've yet > to see anyone document them. If the issue with UUCP _really_ _is_ > security, let's audit the code. Just throwing it out doesn't serve any > useful purpose. I wasn't recommending throwing it out. I'm of the opinion that it would make an excellent build toggle in make.conf, as with many other components of the system (which included, until recently, things like thread support, as well as crypto). The problem with UUCP is that it is a very complex system that does rely on setuid/setgid binaries that exist in the normal program path. The UUCP user and group appear to be tangled up in a number of components, including non-UUCP dialing functionality: crw-rw---- 1 uucp dialer - 28, 128 Feb 12 12:55 /dev/cuaa0 crw-rw---- 1 uucp dialer - 28, 129 Feb 12 12:55 /dev/cuaa1 crw-rw---- 1 uucp dialer - 28, 160 Feb 12 12:55 /dev/cuaia0 crw-rw---- 1 uucp dialer - 28, 161 Feb 12 12:55 /dev/cuaia1 crw-rw---- 1 uucp dialer - 28, 192 Feb 12 12:55 /dev/cuala0 crw-rw---- 1 uucp dialer - 28, 193 Feb 12 12:55 /dev/cuala1 -r-sr-sr-x 1 uucp dialer - 124400 Jan 31 20:21 /usr/bin/cu* -r-xr-xr-x 1 uucp dialer - 37980 Jan 31 20:27 /usr/bin/tip* -r-sr-xr-x 1 uucp wheel - 88652 Jan 31 20:21 /usr/bin/uucp* -r-sr-xr-x 1 uucp wheel - 37568 Jan 31 20:21 /usr/bin/uuname* -r-sr-sr-x 1 uucp dialer - 97048 Jan 31 20:21 /usr/bin/uustat* -r-sr-xr-x 1 uucp wheel - 89256 Jan 31 20:21 /usr/bin/uux* -r-sr-sr-x 1 uucp dialer - 221432 Jan 31 20:21 /usr/libexec/uucp/uucico* -r-sr-s--- 1 uucp uucp - 99996 Jan 31 20:21 /usr/libexec/uucp/uuxqt* Having setuid and setgid all over the place, and associated with devices makes the whole thing rather complicated. Really, /dev/cua* should be owner root, group dialer, for example, and not have UUCP "specialness". With the current model, the ability to compromise any of those setgid/setuid binaries yields access to the system serial ports, as well as the ability to modify programs in the default root and user paths. The daily periodic script, btw, appears to execute uustat each day, and as is seen above, the uustat binary is owned by the UUCP user. I thought all the uu* executions in the periodic stuff had been changed to use su, but either this one wasn't, or it was reverted. In any case, this means that a compromise of the UUCP account can result in a root compromise. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010216153010.59690B-100000>