[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: suid




I don't know why this discussion exists. I am not an expert, but I know
that suid anything is a very bad idea, including and especially shell
scripts, since forever (that is, as far as I can remember back in Unix
that I know of, which is not much).

On a well configured system there should be no need for any suid script at
all. Everything a suid script can or should do can be solved otherwise,
given the skill.

You will argue that an X server must be suid to be run by a user, and I'll
say yes, but he shall not be able to execute it. Want an X session ? The
system provides one if logging in with the correct login for this. It's
all in the setup habits.

There are suid-less solutions for anything. A named pipe in the system,
where you can send commands authenticated by a password, is a way to allow
users to do things in limited ways.

Also, using a socket for some kind of setup controller is possible. It can
authenticate the user from a local host and GECOS and PID and a special
additional password if required. This is at least as secure as accessing a
socket from the network.

The only REAL need for suid programs is when they start up and have to
grab system resources that are owned by root.

Also, normal mortal users should not be able to run any kind of command
with suid privileges, and certainly no suid scripts of any kind. 

imho there should be a compiler flag that would be set automatically and
prevent any kind of suid for any program not compiled by root, or a list
of programs allowed to suid in a database built into the kernel.

my 2 bits
	Peter