From owner-freebsd-security Mon Sep 30 03:57:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA23839 for security-outgoing; Mon, 30 Sep 1996 03:57:43 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA23737 for ; Mon, 30 Sep 1996 03:57:31 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id UAA18707 for ; Sun, 29 Sep 1996 20:58:52 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id VAA11053 for freebsd-security@freebsd.org; Sun, 29 Sep 1996 21:57:29 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id VAA19267 for ; Sun, 29 Sep 1996 21:55:49 -0600 (MDT) Date: Sun, 29 Sep 1996 21:55:48 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: freebsd-security@FreeBSD.ORG Subject: setuid programs in freebsd Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Below is the start of a document I am putting together about various setuid programs in FreeBSD with the intent of giving users a chance to disable what they don't need. It is incomplete, some of it is out of date due to new things that have cropped up since I started writing it, and I have not even read over the whole thing to make sure it makes sense. That means it is in no state to be trusted for any reason by anyone This list came from a find on all setuid binaries in a 2.1.5 install. Where there is a '***', that means that the comment is temporary until I get a chance to expand on it. Things that should be mentioned: - X programs - discussion of how the setuid flag works and how to change it, nofschg, etc. - discussion of using groups to control access to programs Please do NOT repost this anywhere since it is not yet at an appropriate state for that. I would appreciate all feedback on it, including: - errors in what I have written - things I have missed - philosophical debates about ways of doing things - issues of style - general usefulness - spelling, I guess, although I haven't even run it through ispell so don't be too concerned about that. I think it could be the start of a useful collection of documents about specific ways of improving security on FreeBSD systems. I have tried to keep it at a level which is understandable to novices but still technically accurate; my intent isn't to write something for experts, but rather for novices or for experienced people new to FreeBSD looking for specific FreeBSD information. ----------------------------------------------------------------------------- $Id: setuid.txt,v 1.3 1996/09/30 03:41:30 marcs Exp marcs $ 7681 240 -r-sr-xr-x 1 uucp bin 110592 Jul 16 20:17 ./usr/bin/cu 7682 152 -r-sr-xr-x 1 uucp bin 77824 Jul 16 20:17 ./usr/bin/uucp 7684 72 -r-sr-xr-x 1 uucp bin 36864 Jul 16 20:17 ./usr/bin/uuname 7687 168 -r-sr-xr-x 1 uucp bin 86016 Jul 16 20:17 ./usr/bin/uustat 7689 160 -r-sr-xr-x 1 uucp bin 81920 Jul 16 20:18 ./usr/bin/uux 99849 400 -r-sr-xr-x 1 uucp bin 196608 Jul 16 20:17 ./usr/libexec/uucp/uucico 99850 176 -r-sr-x--- 1 uucp uucp 90112 Jul 16 20:18 ./usr/libexec/uucp/uuxqt USE: Used by uucp. IMPACT: If you are not using uucp on your system, removing the setuid flag from uucp, uuname, uustat, uux, uuxqt and uucico will have no impact on the functionality of your system. If you use cu for accessing ports, removing the setuid flag may or may not affect its use depending on how use use it. If you are using uucp, there is no easy way, and arguable no need, to remove the setuid flag. COMMENTS: Since they are setuid uucp and not root, a security hole would only result in someone gaining access to the uucp user. If you are using uucp, compromizing the uucp user means that all your uucp traffic can be compromised. If you aren't using uucp, compromising the uucp user means that, on systems using the default permissions for /dev/cua*, access to any serial devices on the systems will be gained. If those devices include modems, long distance phone calls could be made. 7745 576 ---s--x--x 2 root bin 286720 Jul 16 20:21 ./usr/bin/suidperl 7745 576 ---s--x--x 2 root bin 286720 Jul 16 20:21 ./usr/bin/sperl4.036 suidperl and sperl4.036 are both links to the same file. suidperl should be taken to refer to both suidperl and sperl4.036. If you installed perl5, there will also be suidperl and sperl* in /usr/local/bin; the same comments apply to them. USE: suidperl is a part of perl that allows for secure execution of setuid and setgid perl scripts. Traditionally, setuid and setgid scripts have been insecure due to a race condition when executing the script. suidperl provides a workaround. See the perlsec(1) (in perl 5) or perl(1) (in perl 4; under the 'Setuid Scripts' section; the perl 4 man page is quite incomplete in this regard, so you probably want to use the perl5 one) man page for more details. IMPACT: Removing the setuid flag from suidperl will mean that setuid or setgid perl scripts will no longer work. Most people don't use them, so for most people this is of little consequence. COMMENTS: There was a rather large security hole discovered in suidperl soon before the 2.1.5 release that allowed any user to gain root access on many systems with suidperl installed. FreeBSD 2.1.0 was vulerable; 2.1.5 is not. If you are still running a 2.1.0 system and have not fixed suidperl, take the suid flag off suidperl and sperl* immediately and find out more about the problem. Although, as far as anyone knows, suidperl is now secure, I would advise removing the setuid flags from all copies of 'sperl*' and 'suidperl' on your system if you don't use setuid or setgid perl scripts. 7772 40 -r-sr-xr-x 4 root bin 20480 Jul 16 20:28 ./usr/bin/at 7772 40 -r-sr-xr-x 4 root bin 20480 Jul 16 20:28 ./usr/bin/atq 7772 40 -r-sr-xr-x 4 root bin 20480 Jul 16 20:28 ./usr/bin/atrm 7772 40 -r-sr-xr-x 4 root bin 20480 Jul 16 20:28 ./usr/bin/batch at, atq, atrm and batch are links to the same file. USE: Used to schedule jobs in a similar way to cron, except designed more for non-repeating one time jobs. IMPACT: Removing the setuid flag results in users other than root being unable to use at. 7782 48 -r-sr-xr-x 6 root bin 24576 Jul 16 20:29 ./usr/bin/chpass 7782 48 -r-sr-xr-x 6 root bin 24576 Jul 16 20:29 ./usr/bin/chfn 7782 48 -r-sr-xr-x 6 root bin 24576 Jul 16 20:29 ./usr/bin/chsh 7782 48 -r-sr-xr-x 6 root bin 24576 Jul 16 20:29 ./usr/bin/ypchpass 7782 48 -r-sr-xr-x 6 root bin 24576 Jul 16 20:29 ./usr/bin/ypchfn 7782 48 -r-sr-xr-x 6 root bin 24576 Jul 16 20:29 ./usr/bin/ypchsh chpass, chfn, chsh, ypchpass, ypchfn and ypchsh are links to the same file. USE: Used to change various information in the password file. IMPACT: If the setuid flag is removed, users will be unable to change information in the password file. 7836 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:30 ./usr/bin/keyinit USE: Used by the S/Key authentication system to initialize the use of S/Key one time passwords for logins. IMPACT: Removing the setuid flag from keyinit means that the S/Key authentication system will no longer be functional on your system. COMMENTS: *** Pointer to S/Key info. *** Does S/Key need to be setuid root? 7843 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:30 ./usr/bin/lock USE: Allows the user to 'lock' their terminal from being used until either the given password or login password (depending on command line options) is given or the program times out. IMPACT: *** None?!?! (won't let user use login password to disable) COMMENTS: *** error in source --> no root password 7845 40 -r-sr-xr-x 1 root bin 20480 Jul 16 20:30 ./usr/bin/login USE: Used by many programs in the login name to authenticate by username and password. Can also be used by a user already logged in to get a new login prompt if they wish to login again, possibly as another user. IMPACT: Removing the setuid flag from login results in people who are already logged in being unable to run login to get a new login prompt. For most systems this is not a problem, and many Unixes even ship without login setuid. COMMENT: Although login should be quite secure, and does run as root anyway from programs such as telnetd, removing the setuid flag has so few side effects that it is worthwhile doing if acceptable in your situation. 7868 40 -r-sr-xr-x 2 root bin 20480 Jul 16 20:30 ./usr/bin/passwd 7868 40 -r-sr-xr-x 2 root bin 20480 Jul 16 20:30 ./usr/bin/yppasswd passwd and yppasswd are links to the same file. USE: Allows users to change their password. IMPACT: Removing the setuid flag from passwd means that users will be unable to change their passwords. There are few environments in which this is practical. COMMENTS: This is one of the things that it is reasonable to require a program that is setuid root to do. People interested in increasing the security of user passwords should look at something like ANLpasswd which checks user passwords in an attempt to encourage the user to choose a secure password. *** add pointer to more info 7873 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:30 ./usr/bin/quota USE: Displays information about users' disk usage and limits. IMPACT: Removing the setuid flag means that only users with access to read quota.user on the relevant partition will be able to get quota information. If you aren't using quotas, removing the setuid flag will have no impact on operations. COMMENTS: *** why is it setuid root? why not setgid something? 7875 88 -r-sr-xr-x 1 root bin 45056 Jul 16 20:30 ./usr/bin/rdist USE: rdist is a program that allows for automated remote file distribution. IMPACT: Removing the setuid flag means that only root will be able to use rdist. If you aren't using rdist, removing the setuid flag will have no impact on operations. COMMENTS: There was a rather large security hold discovered in rdist soon before the 2.1.5 release that allowed any user to gain root access on most systems with rdist installed. FreeBSD 2.1.0 is vulnerable; 2.1.5 is not. If you are still running a 2.1.0 system and have not fixed fdist, take the suid flag off rdist immediately and find out more about the problem. Although, as far as anyone knows, the current rdist is secure, I would recommend removing the setuid flag from rdist. If you requre the functionality provided by rdist, there is a rdist-6.1.2 package/port which uses rsh; since it uses rsh and does not call rcmd(3) directly, it does not need to be setuid root. Also note that both versions of rdist use host based security, which has some quite serious flaws. It is possible to make ssh work with the rdist-6.1.2 package; that is strongly recommended if you need to use rdist. 7878 32 -r-sr-xr-x 1 root bin 16384 Jul 16 20:30 ./usr/bin/rlogin USE: rlogin allows you to login remotely to a machine over the network. IMPACT: removing the setuid flat from rlogin means that users other than root will be unable to use rlogin to connect to remote hosts. COMMENTS: There was a security hole in rlogin that was patched soon after the 2.1.5 release. I have not investigated it in depth, nor have I heard of any exploits for it, but it is possible that the hole discovered could allow others to gain root access to your system. *** more info, pointer to fixed binary? In many environments, rlogin can not be disabled without having an unacceptable impact on system usability. ** add not on rlogin and host based auth in general? 7882 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:31 ./usr/bin/rsh USE: rsh is similar to rlogin in that it allows remote execution of commands, however rsh can not be used with interactive commands. *** fix up IMPACT: removing the setuid flag from rsh means that users other than root will be unable to use rsh to connect to remote hosts. COMMENTS: In many environments, rsh can not be disabled without having an unacceptable impact on system usability. 7901 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:31 ./usr/bin/su USE: su is used to switch the user you are running as. It can be used by those in group wheel to switch to the root user (uid 0), and by others to switch to other users. Authentication is by password. IMPACT: removing the setuid flag from su means that users other than root will be unable to use su to switch to other users. COMMENTS: In most cases, unless some alternative such as sudo is being used, removing the setuid flag from su is a very bad idea since it means people need to login as root directly to do things requiring superuser privleges. In many environments, an acceptable alternative is to chgrp su to group wheel and take away execute permission to people not in group wheel. This means that while people in group wheel can still use su to switch users, others will be unable to use it. To some, this is viewed as being desirable in itself, regardless of other security improvements that it may make. 7960 48 -r-sr-xr-x 1 root bin 24576 Jul 16 20:33 ./usr/bin/crontab USE: crontab is used by users to edit their crontab files. IMPACT: removing the setuid flag from crontab means that users other than root will be unable to modify their crontabs. COMMENTS: At some sites, local policy is to not let users have their own crontabs. If this is the case, it can be worthwhile to make a seperate group for those users allowed to have crontabs and only allow users in that group to run crontab. 7964 32 -r-sr-sr-x 1 root daemon 16384 Jul 16 20:33 ./usr/bin/lpq 7965 40 -r-sr-sr-x 1 root daemon 20480 Jul 16 20:33 ./usr/bin/lpr 7966 32 -r-sr-sr-x 1 root daemon 16384 Jul 16 20:33 ./usr/bin/lprm USE: All part of the BSD line printer system used for print queueing, both locally and to and from remote hosts. IMPACT: removing the setuid and setgid flags from the above three utilities means that users other than root will be unable to execute them to submit or remove print jobs. There is an associated program called lpc that is setgid daemon and which can be used, by authorized users, to control print queuing. On hosts that do not use this system for print queueing, removing the setuid and setgid flags will have no impact. COMMENTS: Although lpd and associated programs do not have any currently known problems, I hesitate to trust them. There is no real need for such a program to run as root most of the time. If you don't use them, disable them. If you do need the functionality that they provide, I suggest you take a look at LPRng (which originates from PLP). LPRng is a much more secure replacement to lpd and associated programs that also adds numerous features. It is available at ftp://dickory.sdsu.edu/pub/LPRng. 7967 496 -r-sr-xr-x 3 root bin 245760 Jul 16 20:37 ./usr/bin/newaliases 7967 496 -r-sr-xr-x 3 root bin 245760 Jul 16 20:37 ./usr/bin/mailq 7967 496 -r-sr-xr-x 3 root bin 245760 Jul 16 20:37 ./usr/sbin/sendmail These three programs are links to the same file. USE: Sendmail is a full featured SMTP transport program. IMPACT: Removing the setuid flags from these programs, without some fairly in-depth other changes, will result in very major problems, even if you aren't connected to the Internet. COMMENTS: *** It's sendmail. smapd, smrsh, other programs to help reduce risk? alternatives? don't run sendmail as daemon if you don't need to recieve mail. *** recent bug fixes 76850 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:22 ./usr/libexec/mail.local USE: Part of sendmail; used for local mail delivery. IMPACT: Removing the setuid flag from mail.local, without numerous other changes, will result in major problems on your system. COMMENTS: *** related to sendmail, setgid possibilities 65 40 -rwsr-xr-x 1 root bin 20480 Jul 16 20:33 ./usr/sbin/mrinfo 67 56 -rwsr-xr-x 1 root bin 28672 Jul 16 20:33 ./usr/sbin/mtrace USE: Used to debug multicast routing. IMPACT: Removing the setuid flag from mrinfo and mtrace will mean that users other than root will be unable to use these utilities to get information about multicast routing. If you aren't using multicast routing, they can be disabled without problem. COMMENTS: If you don't know what multicast routing is, you almost certainly aren't using it. 91 168 -r-sr-xr-x 1 root bin 86016 Jul 16 20:34 ./usr/sbin/ppp USE: Establish ppp connections using kernel level ppp. IMPACT: Removing the setuid flag results in users other than root being unable to run kernel level ppp. COMMENTS: If you are using user level ppp (see "/usr/sbin/ppp"), disabling kernel level ppp ("pppd") will have no impact on your ppp connections. On many systems that do use pppd, there is no need to have it executable by everyone so restricting execution to a specific group may be appropriate. 92 128 -r-sr-xr-x 1 root bin 65536 Jul 16 20:34 ./usr/sbin/pppd USE: Establishing ppp connections using user level ppp. IMPACT: Removing the setuid flag results in users other than root being unable to run kernel level ppp. COMMENTS: If you are using kernel level ppp (see "/usr/sbin/pppd"), disabling user level ppp will have no impact on your ppp connections. On many systems that do user user level ppp, there is no need to have it executable by everyone so restricting execution to a specific group may be appropriate. Personally, I have some serious (perhaps unfair; I have NOT really looked into to code in depth) concerns about the thought given by the author to security while writing "ppp". These concerns include things such as the suggested login script in the man page (although that may or may not have been suggested by the original author; see PR 1383 for details) and the default of allowing telnet connections to manage the ppp session. *** info on recent bug and fix 108 32 -r-sr-xr-x 1 root bin 16384 Jul 16 20:34 ./usr/sbin/sliplogin USE: Establishing a SLIP connection. IMPACT: Removing the setuid flag results in users other than root being unable to properly establish a SLIP connection. COMMENTS: If you don't use slip, take the setuid flag off. There was a security hole in old versions that was fixed as of 1996/04/24; 2.1.0 is vulnerable, 2.1.5 should be fixed. 118 40 -r-sr-xr-x 1 root bin 20480 Jul 16 20:34 ./usr/sbin/timedc USE: Used to control the time daemon timed. IMPACT: Removing the setuid flag results in users other than root being unable to use timedc. timedc is setuid because it needs to bind to a privleged port. If you don't use timedc, timed should work just fine with the setuid flag removed from timed. COMMENTS: This code seems relatively secure since it gets rid of its root privileges right after it binds to the port. 119 32 -r-sr-xr-x 1 root bin 16384 Jul 16 20:34 ./usr/sbin/traceroute USE: Used to trace the route that IP packets follow over a network. Extremely useful for users in many environments. IMPACT: Removing the setuid flag results in users other than root being unable to us traceroute. COMMENTS: There have been some recent security fixes in traceroute, but I am uncertain as to if they fix exploitable holes. *** 207 352 -r-sr-xr-x 1 root bin 172032 Jul 16 20:15 ./bin/rcp USE: Used to copy files across the network. IMPACT: Removing the setuid flag results in users other than root being unable to use rcp. COMMENTS: rcp uses host based security and is vulnerable to things such as IP spoofing. A bad thing to use, not just because of any possible security problems in the binary. ssh is a more secure solution that is worth investigating. 686 384 -r-sr-sr-x 2 root tty 188416 Jul 16 20:23 ./sbin/dump 686 384 -r-sr-sr-x 2 root tty 188416 Jul 16 20:23 ./sbin/rdump dump and rdump are links to the same file. USE: Used for local and network backups. IMPACT: Removing the setuid flag results in users other than root being unable to perform backups of the filesystem. COMMENTS: The idea is that anyone in the 'operator' group is able to do backups without having to be root. This is an ideal candidate for restricting execution by means of group, except for the fact that it has to be setgid tty to allow the 'n' option to work. If you don't use the 'n' option, remove the setgid flag, change it to group operator, and remove the world execute flag. Then only those in the operator group can exploit any security holes that may be there, and since generally they can read from the raw disk device anyway... If it is not setuid root, then local backups can still work as long as the person doing them has access to the raw device file and the dump device, however network backups will not work because rcmd(3) will fail. 717 256 -r-sr-xr-x 1 root bin 118784 Jul 16 20:24 ./sbin/ping USE: ping is used to send icmp echo requests to hosts on the network for the purpose of determining reachability. IMPACT: removing the setuid flag results in users other than root being unable to use ping. COMMENTS: ping is a very useful thing for users, although there are possible denial of service attacks possible, especially with the '-l' option. There have been some potential security holes fixed after 2.1.5 was released, but it appears like none of them are exploitable. Perhaps. 721 416 -r-sr-sr-x 2 root tty 204800 Jul 16 20:24 ./sbin/restore 721 416 -r-sr-sr-x 2 root tty 204800 Jul 16 20:24 ./sbin/rrestore restore and rrestore are links to the same file. USE: Used for local and network restores. IMPACT: same as dump COMMENTS: same as dump 722 272 -r-sr-xr-x 1 root bin 126976 Jul 16 20:24 ./sbin/route USE: route is used to maintain the routing table. IMPACT: removing the setuid flag results in users other than root being unable to access the routing table via route. Normally users can't change routes anyway, so the only thing you loose is 'route get' and 'route monitor'. COMMENTS: minimal impact in most situations if the setuid flag is removed. 726 288 -r-sr-x--- 1 root operator 139264 Jul 16 20:24 ./sbin/shutdown USE: Used to shutdown the system. IMPACT: removing the setuid flag results in users other than root being unable to use shutdown. COMMENTS: it is restricted to execution by those in the operator group anyway, so as long as you are careful about who you put in the operator group there should be little risk. 734 288 -r-sr-xr-x 1 root bin 139264 Jul 16 20:24 ./sbin/mount_msdos USE: Used to mount MS-DOS filesystems. IMPACT: removing the setuid flag results in users other than root being unable to mount DOS filesystems. COMMENTS: I sure don't want users mounting filesystems on my box. While it is true that in some situations it can be useful to allow users to do so, I much prefer mtools if users need access to DOS filesystems. I find it more an issue of stability than security, since I don't trust the FreeBSD DOS filesystem code. From owner-freebsd-security Mon Sep 30 09:43:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA09616 for security-outgoing; Mon, 30 Sep 1996 09:43:34 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA09553 for ; Mon, 30 Sep 1996 09:43:28 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA22082; Mon, 30 Sep 1996 12:43:09 -0400 Date: Mon, 30 Sep 1996 12:43:09 -0400 From: Garrett Wollman Message-Id: <9609301643.AA22082@halloran-eldar.lcs.mit.edu> To: Marc Slemko Cc: freebsd-security@FreeBSD.ORG Subject: setuid programs in freebsd In-Reply-To: References: Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > chpass, chfn, chsh, ypchpass, ypchfn and ypchsh are links to the same file. > USE: Used to change various information in the password file. > IMPACT: If the setuid flag is removed, users will be unable to change > information in the password file. Should specifically state which information can be modified by users. > COMMENTS: *** Pointer to S/Key info. *** Does S/Key need to be setuid > root? It needs to be set-id something, in order to be able to modify the /etc/skeykeys file. Since `login' is already root, it does not make sense to me to create a special user for this file. > 7843 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:30 ./usr/bin/lock > IMPACT: *** None?!?! (won't let user use login password to disable) Bzzzt. Any program which needs to verify a password must be root because non-root users cannot read /etc/spwd.db. > usability. ** add not on rlogin and host based auth in general? > USE: rsh is similar to rlogin in that it allows remote execution of > commands, however rsh can not be used with interactive commands. *** > fix up Correctly stated: rsh cannot be used with commands that expect to interact with a terminal. > COMMENTS: In many environments, rsh can not be disabled without having > an unacceptable impact on system usability. More comments: the principal r* commands (rcp, rsh, rlogin) are equipped to do Kerberos authentication and encryption if the user has installed that distribution subset. If Kerberos is working properly to all destinations of interest, the set-uid bit can be removed with no impact on functionality. (It only comes into play when the Kerberos-authenticated mechanism fails and the programs fall back to rcmd(3).) > 7901 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:31 ./usr/bin/su More comments: If the `su' program is build with the WHEEL_SU option, or Kerberos is in use AND the local host has an rcmd.hostname key in /etc/srvtab AND root has a .klogin file AND the user has a username.root instance which is listed in said .klogin file, users in group wheel becoming root can authenticate with their own passwords. (For Kerberized su to root, it would be with username.root's password, not necessarily the same as username.'s password.) The WHEEL_SU facility is perhaps most valuable in conjunction with S/Key, since it allows authorized users to use their own private S/Key one-time pads to become root, thus making remote administration more secure. > 76850 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:22 ./usr/libexec/mail.local > COMMENTS: *** related to sendmail, setgid possibilities None. mail.local has to be able to create the mailbox if it doesn't exist, and it won't be able to chown it to the appropriate user if it doesn't have root. > 207 352 -r-sr-xr-x 1 root bin 172032 Jul 16 20:15 ./bin/rcp > USE: Used to copy files across the network. > IMPACT: Removing the setuid flag results in users other than root being > unable to use rcp. See above. > 734 288 -r-sr-xr-x 1 root bin 139264 Jul 16 20:24 ./sbin/mount_msdos > IMPACT: removing the setuid flag results in users other than root being > unable to mount DOS filesystems. Additional comments: this is done securely inside the kernel without the need for set-id mount programs in Lite2. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Mon Sep 30 10:53:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22133 for security-outgoing; Mon, 30 Sep 1996 10:53:34 -0700 (PDT) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA22043 for ; Mon, 30 Sep 1996 10:53:28 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.13/1.53) id TAA10693; Mon, 30 Sep 1996 19:53:15 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199609301753.TAA10693@gvr.win.tue.nl> Subject: Re: setuid programs in freebsd To: marcs@znep.com (Marc Slemko) Date: Mon, 30 Sep 1996 19:53:14 +0200 (MET DST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from Marc Slemko at "Sep 29, 96 09:55:48 pm" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 7836 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:30 ./usr/bin/keyinit > > USE: Used by the S/Key authentication system to initialize the use of > S/Key one time passwords for logins. > > IMPACT: Removing the setuid flag from keyinit means that the S/Key > authentication system will no longer be functional on your system. Nottrue. It only means users can not setup skeys for themselves. > > COMMENTS: *** Pointer to S/Key info. *** Does S/Key need to be setuid > root? Yes. > 7843 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:30 ./usr/bin/lock > > USE: Allows the user to 'lock' their terminal from being used until > either the given password or login password (depending on command line > options) is given or the program times out. > > IMPACT: *** None?!?! (won't let user use login password to disable) s-bit is indeed necessary to check a users password. > > COMMENTS: There was a security hole in rlogin that was patched soon > after the 2.1.5 release. I have not investigated it in depth, nor > have I heard of any exploits for it, but it is possible that the hole > discovered could allow others to gain root access to your system. *** > more info, pointer to fixed binary? In many environments, rlogin can > not be disabled without having an unacceptable impact on system > usability. ** add not on rlogin and host based auth in general? There was a bug in rlogind, a portential buffer overflow that was not exploitable. -Guido From owner-freebsd-security Mon Sep 30 15:29:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA08394 for security-outgoing; Mon, 30 Sep 1996 15:29:48 -0700 (PDT) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA08320 for ; Mon, 30 Sep 1996 15:29:40 -0700 (PDT) Received: (from steve@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) id PAA00302; Mon, 30 Sep 1996 15:29:26 -0700 Date: Mon, 30 Sep 1996 15:29:21 -0700 (PDT) From: Steve Reid To: Marc Slemko cc: freebsd-security@FreeBSD.ORG Subject: Re: setuid programs in freebsd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Below is the start of a document I am putting together about various > setuid programs in FreeBSD with the intent of giving users a chance to > disable what they don't need. [snip] This is a very good idea. Other people have posted about what they've removed the suid bit from, but not with such detailed information. How about turning this into a script for convenience? It could go through all of the suid programs, display the relevant info from your document, and ask how the modes should be set. Much faster and easier than manually going through all of the files and typing the necessary chflags and chmod commands by hand. ===================================================================== | Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/) | | Email: steve@edmweb.com Home Page: http://www.edmweb.com/steve/ | | PGP (2048/9F317269) Fingerprint: 11C89D1CD67287E68C09EC52443F8830 | | -- Disclaimer: JMHO, YMMV, TANSTAAFL, IANAL. -- | ===================================================================:) From owner-freebsd-security Mon Sep 30 18:23:39 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA21213 for security-outgoing; Mon, 30 Sep 1996 18:23:39 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA21110 for ; Mon, 30 Sep 1996 18:23:31 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id TAA06858; Mon, 30 Sep 1996 19:23:19 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id SAA25085; Mon, 30 Sep 1996 18:26:37 -0600 (MDT) Date: Mon, 30 Sep 1996 18:26:35 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Garrett Wollman cc: freebsd-security@FreeBSD.ORG Subject: Re: setuid programs in freebsd In-Reply-To: <9609301643.AA22082@halloran-eldar.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thanks for the comments. I will incorporate what I can into the next revision of the document. On Mon, 30 Sep 1996, Garrett Wollman wrote: > < said: > > > chpass, chfn, chsh, ypchpass, ypchfn and ypchsh are links to the same file. > > > USE: Used to change various information in the password file. > > > IMPACT: If the setuid flag is removed, users will be unable to change > > information in the password file. > > Should specifically state which information can be modified by users. Agreed. > > > COMMENTS: *** Pointer to S/Key info. *** Does S/Key need to be setuid > > root? > > It needs to be set-id something, in order to be able to modify the > /etc/skeykeys file. Since `login' is already root, it does not make > sense to me to create a special user for this file. You have a point. I can see some minor gains to having it setuid to something else (ie. instead of giving you instant root when an exploit is found, it only gives you access to data that can give you root reasonably easily), but it probably isn't worth bothering with. > > > 7843 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:30 ./usr/bin/lock > > > IMPACT: *** None?!?! (won't let user use login password to disable) > > Bzzzt. Any program which needs to verify a password must be root > because non-root users cannot read /etc/spwd.db. Yup. That was me being silly and not thinking; I added the bit in comments when I finally woke up, but forgot to delete the none bit. > > > usability. ** add not on rlogin and host based auth in general? > > > USE: rsh is similar to rlogin in that it allows remote execution of > > commands, however rsh can not be used with interactive commands. *** > > fix up > > Correctly stated: rsh cannot be used with commands that expect to > interact with a terminal. Good point. > > > COMMENTS: In many environments, rsh can not be disabled without having > > an unacceptable impact on system usability. > > More comments: the principal r* commands (rcp, rsh, rlogin) are > equipped to do Kerberos authentication and encryption if the user has > installed that distribution subset. If Kerberos is working properly > to all destinations of interest, the set-uid bit can be removed with > no impact on functionality. (It only comes into play when the > Kerberos-authenticated mechanism fails and the programs fall back to > rcmd(3).) Good point. I'm trying to decide how much I should mention about Kerberos since it can be somewhat complicated. I'll probably mention it in passing and find a good semi-generic Kerberos document to point them to. > > > 7901 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:31 ./usr/bin/su > > More comments: If the `su' program is build with the WHEEL_SU option, > or Kerberos is in use AND the local host has an rcmd.hostname key in > /etc/srvtab AND root has a .klogin file AND the user has a > username.root instance which is listed in said .klogin file, users in > group wheel becoming root can authenticate with their own passwords. > (For Kerberized su to root, it would be with username.root's password, > not necessarily the same as username.'s password.) The WHEEL_SU > facility is perhaps most valuable in conjunction with S/Key, since it > allows authorized users to use their own private S/Key one-time pads > to become root, thus making remote administration more secure. Very interesting. I wasn't aware of that one. I'll see how I can work some or all of that in. > > > 76850 24 -r-sr-xr-x 1 root bin 12288 Jul 16 20:22 ./usr/libexec/mail.local > > > COMMENTS: *** related to sendmail, setgid possibilities > > None. mail.local has to be able to create the mailbox if it doesn't > exist, and it won't be able to chown it to the appropriate user if it > doesn't have root. It would be possible to have all mailboxes pre-created by a different process, or have a small sub-program that mail.local used for that. But yes, it is true for mail.local specifically and sendmail in general that out of the box it doesn't like running as something other than root. I think that either going through a few of the issues that need to be dealt with to make sendmail run as something other than root or discussing any alternative mailers that don't need root could be worthwhile. Anyone know if there is any active work going on on implementing ACLs (ie. this user can bind to this port, this one can change the owner of files in this directory, etc.) in any BSD? From owner-freebsd-security Mon Sep 30 18:24:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA21524 for security-outgoing; Mon, 30 Sep 1996 18:24:01 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA21441 for ; Mon, 30 Sep 1996 18:23:55 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id TAA06864; Mon, 30 Sep 1996 19:23:38 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id SAA25108; Mon, 30 Sep 1996 18:38:48 -0600 (MDT) Date: Mon, 30 Sep 1996 18:38:47 -0600 (MDT) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Steve Reid cc: freebsd-security@FreeBSD.ORG Subject: Re: setuid programs in freebsd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Good suggestion. I am tossing about the idea of doing so, but there gets to be more involved than you may think. I don't think it would be a script if I wrote it, but probably a pretty full screen utility similar to sysinstall in interface. The first step I'm working on is getting the information and getting it accurate and complete. Until I know the information is accurate I'm not going to worry about making it easy to use. At the very least, it needs a good explaination about chflags and chmod. On Mon, 30 Sep 1996, Steve Reid wrote: > > Below is the start of a document I am putting together about various > > setuid programs in FreeBSD with the intent of giving users a chance to > > disable what they don't need. > [snip] > > This is a very good idea. Other people have posted about what they've > removed the suid bit from, but not with such detailed information. > > How about turning this into a script for convenience? It could go through > all of the suid programs, display the relevant info from your document, > and ask how the modes should be set. Much faster and easier than manually > going through all of the files and typing the necessary chflags and chmod > commands by hand. > > > ===================================================================== > | Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/) | > | Email: steve@edmweb.com Home Page: http://www.edmweb.com/steve/ | > | PGP (2048/9F317269) Fingerprint: 11C89D1CD67287E68C09EC52443F8830 | > | -- Disclaimer: JMHO, YMMV, TANSTAAFL, IANAL. -- | > ===================================================================:) > From owner-freebsd-security Tue Oct 1 11:06:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA06384 for security-outgoing; Tue, 1 Oct 1996 11:06:59 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA06376 for ; Tue, 1 Oct 1996 11:06:54 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15717(6)>; Tue, 1 Oct 1996 11:06:13 PDT Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177476>; Tue, 1 Oct 1996 11:05:11 -0700 X-Mailer: exmh version 1.6.7 5/3/96 To: Marc Slemko cc: freebsd-security@freebsd.org Subject: Re: setuid programs in freebsd In-reply-to: Your message of "Sun, 29 Sep 1996 20:55:48 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 1 Oct 1996 11:05:03 PDT From: Bill Fenner Message-Id: <96Oct1.110511pdt.177476@crevenia.parc.xerox.com> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Marc, There are certain programs that have been modified to do the minimum required tasks before releasing their setuid-ness, e.g. ping and traceroute basically do main() { s = socket(); setuid(getuid()); I've been meaning to do the same to mrinfo & mtrace for quite a long time. Perhaps these could be specially labelled in your document? > 119 32 -r-sr-xr-x 1 root bin 16384 Jul 16 20:34 ./usr/sbin > /traceroute > >COMMENTS: There have been some recent security fixes in traceroute, but >I am uncertain as to if they fix exploitable holes. *** Yes, the holes are exploitable if you control the DNS of a host that you can traceroute through. >COMMENTS: ping is a very useful thing for users, although there are possible >denial of service attacks possible, especially with the '-l' option. There >have been some potential security holes fixed after 2.1.5 was released, >but it appears like none of them are exploitable. Perhaps. I agree, the setuid(getuid()) in ping was basically belt-and-suspenders kind of fix. Bill From owner-freebsd-security Tue Oct 1 15:55:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA06397 for security-outgoing; Tue, 1 Oct 1996 15:55:57 -0700 (PDT) Received: from dhp.com (dhp.com [199.245.105.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA06391 for ; Tue, 1 Oct 1996 15:55:53 -0700 (PDT) Received: from localhost (jaeger@localhost) by dhp.com (8.7.6/8.6.12) with SMTP id SAA32124; Tue, 1 Oct 1996 18:55:28 -0400 Date: Tue, 1 Oct 1996 18:55:28 -0400 (EDT) From: jaeger To: Bill Fenner cc: freebsd-security@freebsd.org Subject: Re: setuid programs in freebsd In-Reply-To: <96Oct1.110511pdt.177476@crevenia.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Oct 1996, Bill Fenner wrote: > Marc, > > There are certain programs that have been modified to do the minimum > required tasks before releasing their setuid-ness, e.g. ping and traceroute > basically do > > main() > { > s = socket(); > setuid(getuid()); > > I've been meaning to do the same to mrinfo & mtrace for quite a long time. > Perhaps these could be specially labelled in your document? I believe Theo De Raadt commited those changes to OpenBSD a month or two ago. Has the FreeBSD core been getting notices on security holes still? > Bill > j. From owner-freebsd-security Tue Oct 1 16:10:14 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA07646 for security-outgoing; Tue, 1 Oct 1996 16:10:14 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA07633 for ; Tue, 1 Oct 1996 16:10:09 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15210(4)>; Tue, 1 Oct 1996 16:09:34 PDT Received: by crevenia.parc.xerox.com id <177476>; Tue, 1 Oct 1996 16:09:22 -0700 From: Bill Fenner To: fenner@parc.xerox.com, jaeger@dhp.com Subject: Re: setuid programs in freebsd Cc: freebsd-security@freebsd.org Message-Id: <96Oct1.160922pdt.177476@crevenia.parc.xerox.com> Date: Tue, 1 Oct 1996 16:09:09 PDT Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I believe Theo De Raadt commited those changes to OpenBSD a month or >two ago. Presumably you're talking about the patches to map-mbone, mrinfo, mtrace and mrouted that I reviewed for him? I sent them to him on September 11th and just keep forgetting to apply them to the FreeBSD tree. Bill From owner-freebsd-security Tue Oct 1 21:52:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA02330 for security-outgoing; Tue, 1 Oct 1996 21:52:56 -0700 (PDT) Received: from dhp.com (dhp.com [199.245.105.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA02309 for ; Tue, 1 Oct 1996 21:52:49 -0700 (PDT) Received: from localhost (jaeger@localhost) by dhp.com (8.7.6/8.6.12) with SMTP id AAA05981; Wed, 2 Oct 1996 00:52:45 -0400 Date: Wed, 2 Oct 1996 00:52:45 -0400 (EDT) From: jaeger To: Bill Fenner cc: freebsd-security@freebsd.org Subject: Re: setuid programs in freebsd In-Reply-To: <96Oct1.160922pdt.177476@crevenia.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 1 Oct 1996, Bill Fenner wrote: > > I believe Theo De Raadt commited those changes to OpenBSD a month or > >two ago. > > Presumably you're talking about the patches to map-mbone, mrinfo, mtrace > and mrouted that I reviewed for him? I sent them to him on September 11th > and just keep forgetting to apply them to the FreeBSD tree. > > Bill > Actually he and I and some other people were poking around the suids informally, and looked at mrinfo and mtrace I believe. I thought I saw some problems, he wasn't sure and just decided to drop privs right away. This was sometime in early August I recall. I'm not sure where all he applied fixes, I haven't looked at the CVS logs for the changes or the dates. j. From owner-freebsd-security Tue Oct 1 23:13:23 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA09596 for security-outgoing; Tue, 1 Oct 1996 23:13:23 -0700 (PDT) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA09588 for ; Tue, 1 Oct 1996 23:13:18 -0700 (PDT) Received: from communica.com.au (newton@frenzy [192.82.222.65]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id JAA01350; Tue, 1 Oct 1996 09:32:04 +0930 Received: by communica.com.au (4.1/SMI-4.1) id AA15420; Tue, 1 Oct 96 09:31:21 CST From: newton@communica.com.au (Mark Newton) Message-Id: <9610010001.AA15420@communica.com.au> Subject: Re: setuid programs in freebsd To: marcs@znep.com (Marc Slemko) Date: Tue, 1 Oct 1996 09:31:21 +0930 (CST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from "Marc Slemko" at Sep 29, 96 09:55:48 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Marc Slemko wrote: > 91 168 -r-sr-xr-x 1 root bin 86016 Jul 16 20:34 ./usr/sbin/ppp > > USE: Establish ppp connections using kernel level ppp. > > 92 128 -r-sr-xr-x 1 root bin 65536 Jul 16 20:34 ./usr/sbin/pppd > > USE: Establishing ppp connections using user level ppp. These two are the wrong way around: pppd is for kernel PPP. /usr/sbin/ppp is the ijppp user PPP executable (the one that uses the tun devices) - mark [ nitpicky, I know - Others have made many other worthy suggestions already ] --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au