> My understanding of the position of Bob and Mike can be summed up as,
> "in general, shell script's can't be made to use setuid/setgid
> securely". Basically, the problem comes down that a user can manipulate
> their PATH to redefining basic commands that are used by the shell
> scripts (like "ls") in order to elevate their privileges.
>
> I'm not willing to give up on the basic idea yet, however, as I still
> need to run a Java program setgid to "games" to handle a score history
> file. Similarly, I hope to one day run a Java application server (e.g.
> Tomcat, JBoss, or Geronimo) setuid to some system id. Therefore I
> humbly request your comments on how to salvage this idea. Please keep
> in mind that "/usr/bin/java" is, itself, almost certainly a script.
I missed the original discussion, so I risk saying something someone
has already said. My strategy for dealing with setuid/setgid shell
scripts in general is always to use sudo (which mdz mentioned as an
example of controlling elevation of privileges). I abandoned wrappers
in favor of this long ago. sudo is easy to set up, and it explicitly
moves responsibility to the local administrator. My standard approach
is to name my script whatever.real and have a wrapper that runs sudo.
For example, I allow certain users on some of my systems to create
accounts with adduser. I have renamed adduser to adduser.real and
created the following adduser script:
#!/bin/sh
echo "If prompted, enter your password to enter user creation program."
exec sudo $0.real ${1+"$@"}
Use of $0.real here is okay because the sudoers file has the full path
to the program that the user is authorized to run. (Anyway, the user
can always run sudo by hand.) I also set the permissions on the
whatever.real script to 0750 or 0700. Now if I want to control this
with a group or just a list of authorized users, I can do that in
sudoers. Although my home-written adduser script could certainly be
exploited by a knowledgeable user, I trust the people who are
authorized to create accounts on my systems, so I'm willing to accept
that risk in this instance.
As for the specific example of writing to a high scores file, I would
assert that this functionality is not essential to the proper
functioning of the game, and you should make the game work with or
without this functionality. That way, if whatever strategy you choose
for updating the high scores file is overridden by the local
administrator, the game will still work. I wouldn't make the whole
game setgid just so it can write to its high score file. I would do
one of two things instead: make the high score file world-writable and
put it in a non-world-writable directory (some may object to
world-writable files on a system partition), or create a separate
program that your main program communicates to whose sole purpose in
life is to update the high scoring program. This can be a normal
compiled C or C++ program. You can create a debconf question that
explains to the installer that this component of the application needs
to be installed setgid games to update its high scoring file and ask
the user whether to do this, explaining the potential security risks,
and have the default be "no". You can look at man-db
(dpkg-reconfigure man-db) for example of how you might want to word
this.
--
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/
