Re: setuid/setgid binaries contained in the Debian repository.
On Mon, Aug 11, 2003 at 10:30:24PM +0200, Emile van Bergen wrote:
> On Mon, Aug 11, 2003 at 04:14:36PM -0400, Matt Zimmerman wrote:
> > 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?
Complexity.
> All other solutions require traversing the kernel. Now we traverse a
> userspace wrapper. Is there any fundamental difference?
How does your proposed solution avoid the kernel?
> > 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 was talking about the current state of affairs in Debian, not about a
hypothetical solution. What I described is what we do _today_ in Debian
(the problem).
> > > 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'.
In context, those phrases referred to two different processes.
> > 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.
Moving data to /var/games is possible without setuid operation, as well, if
it is desirable.
> > 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?
Because then the game doesn't work correctly.
> > 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.
I think you misunderstood my scenario. The migration of the game files
would typically be done by the maintainer scripts, with root privileges. It
was an example of additional risks which are introduced by adding
complexity. In this case, a migration is required, and secure migration in
that situation is not necessarily trivial or obvious to the package
maintainer.
(nethack, the example game, already stores its saved games under
/var/lib/games/nethack)
--
- mdz
Reply to: