On 0, Adar Dembo <a@darr.com> wrote: > That is a good question, and normally I'd agree, but by just adding sudo > priveledges to the exec, I force more work on the sudoers as follows: > > 1) In my original script, notice there was quite a long set of arguments > following the --exec statement. Typing all this by hand would be painful > and difficult to remember. But all that can be put in a script. I didn't necessarily question the need for a script, just for a script that goes in /etc/init.d, since I got the impression that users would only run a server on demand. > 2) I need to run multiple instances of this process, each with a > slightly different set of arguments. For example, one server needs to > bind to UDP port 27910, and the other to 27920. This would complicate > things. This will compicate things anyway, won't it? > 3) I want a quick, painless way to take down or restart a server, as > simple as "<scriptname> stop", rather than having to find it in the > process list. Furthermore, if I want to shut it down, the original > sudoer would somehow need to gain permission to kill a process now owned > by the user quake2. I am not sure quite how group priveledges work, but > I'd have to make a group, which all sudoers are part of, and get the > process to be run as part of that group as well, in order for an > original sudoer to have the necessary permissions to take down the > process. Fair enough. However, I don't see how making a script in /etc/init.d makes it any easier (from a security point of view) for a user to kill a server than adding: %gs localhost = (quake2) /bin/kill to /etc/sudoers - then they can kill processes owned by the quake2 user which would be limited to the processes started using the sudoers rule from my previous mail. > 4) I want the servers to all activate on boot time. When it's all > working I'll use rcconf and take care of that. Ah. I didn't realise this requirement from your original post. > After some more thought, however, I wonder whether a "su quake2 -c..." > solution would work. The problem I'm getting with start-stop-daemon is > that --background isn't working. With an su -c solution, I'd have to > somehow force the process to fork, and I'm not sure how. Maybe prefixing > su -c with "sh" would open a separate shell. But I don't know for sure. If you use su then they need to know a password. > Also, do you think adding a chroot jail to the setup would be a good > idea? I know vaguely what it does, but it's such a pain to setup. Since > the default shell for the quake2 user would be /bin/false in the end > anyway, would a buffer overflow or similar exploit still be able to give > the hacker access to a shell? Or to anything for that matter? My > knowledge on security exploits is severely lacking... Let's face it, the first step to system security is to deny all logins. If you have people who can login then your system is already fairly insecure. There is no reason why someone with access to the quake2 user could do any more damage than someone with access to one of the normal user accounts. So you are better off making sure that everything that you want to stay there is only accessible by the right people than putting time into locking the quake2 user into a chroot gaol. If that is how to make your system secure then you had better lock all your lusers in a chroot gaol, or better yet set their shell to /bin/false. See what I mean? Users are a pain... The /etc/init.d script seems like a reasonable solution then, with sudo access to it to bring servers up/down etc. However, this means giving them permissions to do so as root... is that what you want? Tom -- Tom Cook Information Technology Services, The University of Adelaide "The secret of creativity is knowing how to hide your sources." - Albert Einstein Get my GPG public key: https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au
Attachment:
pgpT8tx9aHdmR.pgp
Description: PGP signature