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

Re: setuid/setgid binaries contained in the Debian repository.



Hi,

On Mon, Aug 11, 2003 at 09:28:42AM -0400, Matt Zimmerman wrote:

> On Mon, Aug 11, 2003 at 10:56:50AM +0200, Emile van Bergen wrote:
> 
> > A more unix-like approach would therefore be to create a separate uid
> > for each game, and use a wrapper for each game that's suid to the game's
> > uid and executable only by gid games. This wrapper would, clean the
> > environment and run the game, passing the uid of the invoking user as
> > simple command line or environment information to the game. A "call
> > gate" for games, so to speak.
> >
> > This way, users have no control over the process that runs the game;
> > each game runs under a different uid and can have its own highscore
> > file, which is guaranteed secure from other games. 
> > 
> > In other words, the game doesn't have to trust the user nor does it need
> > to trust all other games anymore. Looks like it solves the problem.
> 
> setuid results in even more problems than setgid.  Given access to the game
> uid, the user can modify the wrapper program (because they own it) and from
> that point forward, any user who runs the game is compromised.

The point is that the user doesn't get control over the game uid,
because the setuid + wrapper that sets the real uid, etc. provides a
barrier to the invoking user. We have to trust such barriers; they are
required in the unix design.

If a user could make any setuid binary do arbitrary things, no matter
whether it's correctly written, then it's a kernel bug and we are in
much, much bigger trouble.

The idea is that the wrapper must be trusted to be able to guarantee
dropping all permissions inherited from the invoking user and setting
all uids (saved, effective, real) to the per-game uid. After this, the
game cannot do anything as the invoking user or to his files. That's the
whole point.

In short, the setuid wrapper doesn't add any permissions, it effectively
drops the invoking user's permissions. Most people don't consider this
possibility of setuid.

Setgid is a bigger problem because the process retains the permissions
over the invoking users files and gains additional permissions. Not so
with this scenario.

After completely switching to the game uid, if mere user input is enough
to have the game run arbitrary code under its per-game uid and do the
same when the next user runs it, it won't be able to harm that user in
any way, simply because that game uid can't do anything to any user at
all.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

Attachment: pgpryDxmNChLM.pgp
Description: PGP signature


Reply to: