Date: Mon, 30 Sep 1996 18:26:35 -0600 (MDT) From: Marc Slemko <marcs@znep.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: freebsd-security@FreeBSD.ORG Subject: Re: setuid programs in freebsd Message-ID: <Pine.BSF.3.95.960930170509.24468D-100000@alive.ampr.ab.ca> In-Reply-To: <9609301643.AA22082@halloran-eldar.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > <<On Sun, 29 Sep 1996 21:55:48 -0600 (MDT), Marc Slemko <marcs@znep.com> 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.960930170509.24468D-100000>