on Sun, Feb 03, 2002 at 09:35:33AM +1100, matthew green wrote:
> did you also notice that there are quite a lot of non-setuid programs
> as well?  :-)

yep!

>    /sbin/{r,}dump{,_lfs} are sgid tty - this again (to me) doesn't seem
>    necessary.
> 
> using write(1) would mean that messages might not get through when they
> have in the past.  as these programs are usually run by root or operator
> anyway, both of which have major access to the system, i don't see this
> as a real issue.

yes, and since there has already been a vulnerability in dump...
(NetBSD-SA2001-014)

> ccdconfig shouldn't be setgid IMO, but thorpej disagrees.  it's only
> useful so that non-root can "ccdconfig -g" which i don't believe is
> a necessary or useful thing to provide.  but you'll have to convince
> jason otherwise i think :-)

Well, device configuration, imho, is an administrative task, so
giving out special privileges to allow non-administrative users
view the configuration doesn't seem "right" to me. Plus,
the setgid bit can always be re-added to those installations that
need it.

> pppd and sliplogin are login shells, they need to be setuid.  on a
> "harded" (of sorts) system i run, only priv(8), su(8) and pppd(8)
> are set-id.  (priv is like sudo.)

hmm ok

> /usr/bin/login is set-id so that someone can type "login" at a shell
> to replace their current session.  "login" to a shell really ends up
> doing an "exec /usr/bin/login".  this is of dubious advantage and
> can cause utmp-lossage (or used to on older unix :-)  i wouldn't miss
> the setuid bit on /usr/bin/login.

/usr/bin/su, ssh localhost, telnet localhost, rsh localhost, etc
all seem to do basically the as a setuid /usr/bin/login

> of course this "likely to break" depends vastly on your environment :-)

Yes, getting a good balance is a worthwhile thing imho :)