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

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



On Tue, Aug 12, 2003 at 01:02:09AM +0200, Emile van Bergen wrote:

> On Mon, Aug 11, 2003 at 05:32:23PM -0400, Matt Zimmerman wrote:
> > Complexity.
> 
> Let me then ask this first. Do you want the game to run with the full
> privileges of the user invoking it? If no, then you need a sandbox per
> game in some form or another.
> 
> Using a different uid for a process is the simplest and strongest form of
> sandbox imaginable. 

The simplest setup imaginable is for the game to run with the privileges of
the invoking user, just as any other user process does by default.  As long
as the game doesn't trust data under the control of users other than the
caller, this is perfect.

> Yes, and it seems you prefer to keep talking about the problem than
> talking about solutions. I haven't heard any viable alternative from you
> so far.

It seems that you missed the beginning of this thread, the draft policy
proposal that came soon thereafter, and the discussion that ensued.

> > Because then the game doesn't work correctly.
> 
> Then you patch it.

Then _who_ patches it?  If you are volunteering to do this, then I will have
to retract some of my objections.  Otherwise, they still apply.

> Really, this is less complex than any client server solution, a mandatory
> library, or taking advantage of some hot shot kernel feature.

For simple games, making this scheme work will be more complex than securing
the game against untrusted data, and I think that places it firmly on the
wrong side of the cost/benefit ratio.

I would rather have no global score files than a setuid sandbox solution.

-- 
 - mdz



Reply to: