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

Re: daemons running as nobody

On Sat, Mar 31, 2001 at 02:50:58PM -0900, Ethan Benson wrote:
> i think running daemons as nobody is ok if done in moderation, and
> only on more or less unimportant daemons.

OK, xpilots (a game server) is one such daemon.  Is this cause for

> the thing with nobody is it
> should not own ANY file on the filesystem.  so if the daemon needs to
> write files it should not run as nobody.  

Hm, while xpilots doesn't write files, there's a slight glitch ...  If
started as root, /etc/init.d/xpilots will su nobody to run xpilots. 
Normally, all data the server uses is world-readable.  However, in the
special case of a mapfile containing a password (for a weak,
plaintext-only authentication scheme to allow certain privileges[1] to
players who gain "operator" status by supplying the password from the
xpilot client) I suspect that you'd want a the server run as user and
group "xpilots" and thus be able to protect the map file (or preferably
just a separate file for the password) against prying eyes.

For the next release of xpilots, I think I will leave it as is. 
Automatically starting the server at startup is not the default.  (You
have to modify /etc/xpilots.conf to turn on AUTOSTART for that.)  It is
assumed that a user starts their own xpilot server under their own
username, in which case they can protect the password in the mapfile
by chmodding it 600.

I'll document about the problem by warning the admin about the security
implications of running a passworded server in a comment in
/etc/xpilots.conf and try to resolve the problem with upstream for next
verison.  Sound fair? 

p.s. Matt Kern is listed as the xpilot maintainer, but I'm taking over
     the package in a private adoption.  I expect to upload my new
     version soon.

[1] Players who become "operators" who can then change game settings, kick
    people off the server, lock the game, pause a player, reset scores/rounds,
    advance players on the waiting-to-enter-game queue when game is full,
    and change the password.  If the password falls into the wrong hands,
    the worst that can be done here is a denial-of-service attack such as
    locking the game, screwing up the settings badly enough so as to make
    the game unplayable, or other abuses of operator privilege.
    Basically, it would be equivalent to someone abusing channel
    privileges on irc.  The offender could become obnoxious within the
    context of the channel, but would not be able to compromise the server
    host in any way.
    nSLUG       http://www.nslug.ns.ca      synrg@sanctuary.nslug.ns.ca
    Debian      http://www.debian.org       synrg@debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

Reply to: