[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: setuid/setgid binaries contained in the Debian repository.
From:       Emile van Bergen <emile-deb () evbergen ! xs4all ! nl>
Date:       2003-08-11 20:30:24
[Download RAW message or body]

Hi,

On Mon, Aug 11, 2003 at 04:14:36PM -0400, Matt Zimmerman wrote:

> On Mon, Aug 11, 2003 at 08:50:28PM +0200, Emile van Bergen wrote:
> 
> > On Mon, Aug 11, 2003 at 01:18:08PM -0400, Matt Zimmerman wrote:
> > > Right, but its uid owns executable programs, and thus "owns" any user
> > > who runs those executables.
> > 
> > Nonsense. The only thing that can be 'owned' is the user's files and they
> > cannot be written to by the game uid. Also, the game uid cannot run any
> > process impersonating the user. 
> > 
> > The whole point is removing the 'thus' from your sentence, by having a
> > trapdoor that drops the invoking user's permissions.
> 
> If only security were so simple.  Running untrusted code is still a problem,
> even if it isn't under your own uid.  It's not hard to write a convincing
> trojan which aims to steal passwords.
> 
> If nothing else, the process still has a file descriptor for the user's
> terminal, and even that gives it some influence over the user.

Right. Essentially you're saying that an untrusted program that can
interact with the user in any way is a problem in itself. Sure, on some
level that's true of course, but it's the whole point of giving the user
a sandbox.

> > The wrapper *is* trivial. It's what, twenty lines of code? The sandbox
> > available on a unix system is the separate uid. 
> 
> It makes 5 system calls, 4 library calls and still implements its own string
> manipulation logic.  The string manipulation required scrutiny just to make
> sure that it would work, much less that it was secure (having multiple
> statements per line didn't help).
> 
> And in order to get access to this "sandbox", you need to ask _root_ (who
> you called the system creator's account).  Why should he be involved?

Because you need a trusted monitor to bridge uids. Sure, it would be
nice if a setuid/setgid in combination with another permission bit or
file attribute would implement the trapdoor fully kernel based, but
because the kernel doesn't have this functionality, a program running as
root has to implement it. I'm glad that I can do that without adding
such functionality to the kernel, even if that would eventually more
elegant.

> This trivial solution involves traversal of three different UIDs, one of
> which is root.  A setuid root wrapper program, a new uid and a new gid are
> allocated for every game.  And what have we gained?  The ability to share a
> file with other users.

No, a sandbox for every game. Every sandbox requires a uid. This is a
problem why?

All other solutions require traversing the kernel. Now we traverse a
userspace wrapper. Is there any fundamental difference?

> > It's the game code's responsibility to properly bridge between its user
> > interface and its highscore files. No OS can help it do that, that's its
> > role. That's its purpose.
> 
> Its purpose is to entertain the user.  They are not generally written with
> security in mind.  So, inexplicably, we reward them by granting them more
> privileges than would be afforded any other user program, like a text
> editor.  Often, we'll even elevate them to root, if they claim to be able to
> draw pretty pictures directly on the video framebuffer.

No, if we reserve a uid/gid for each game, we actually give the game
fewer privileges. Also, if we do that, we can make those uids a member
of group 'fd' and a member of group 'audio', if the admin is inclined to
allow that. No need for root to acces the framebuffer and the sound
card, if the driver properly adheres to the unix paradigm of
filesystem-based permissions.

> > > I would rather see a tiny setuid program which sanitizes and records high
> > > scores, which is invoked by the game, which runs with the privileges of the
> > > user 
> > 
> > So your highscore manager has the privileges of the user *and* the high
> > score file owner. Less secure than my solution.
> 
> I don't know where you got that idea.

'setuid' + 'runs with the privileges of the user'.

> > > (or, for extra high-score paranoia, setgid, where only gid games can
> > > invoke the high score manager).  
> > 
> > Yes, but all games share the same trust from the high score manager. One
> > compromised came can impersonate another game to the high score manager.
> > The only way to prevent that is different uids for each game. Hence my
> > solution.
> 
> I personally don't care one whit about impersonating high scores.  I do care
> about the security of my system.

I do too. I don't trust game code. I don't want it to access my $HOME at
all. Have it use /var/games/<game>/$USER. My solution allows that.

> > > Having a completely empty environment will surely cause problems; a trusted
> > > PATH at least should be set, and things like TERM are required for proper
> > > operation of many games (though presumably not Quake, which isn't
> > > terminal-based).  You also need some way to tell the game who the user is,
> > > for record keeping purposes.
> > 
> > Sure. That's something you could put in $USER.
> 
> And $LOGNAME.  And then make sure that none of the programs that you're
> wrapping will break, because they use getpwuid() or getlogin() or cuserid()
> or any other method which uses the uid.

Fine, they see the game user. This is bad why?

> nethack, for example, uses the process uid in order to name its save files,
> and changing this would necessitate migration of existing games.  Of course,
> that needs to be done very carefully in order to avoid making it possible to
> exploit root from the games uid through filesystem-based attacks.

There is no games uid, there is only a 'nethack' uid and gid. This uid
and gid cannot attack anything. The consequence is that ~/.game must be
moved to /var/games/<game>/<user>. This is a trivial change.

Cheers,


Emile.

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

[Attachment #3 (application/pgp-signature)]
-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


[prev in list] [next in list] [prev in thread] [next in thread]