Re: setuid/setgid binaries contained in the Debian repository.
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.
> 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?
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.
> I can't make it simpler than that. Any java, selinux, MAC, UML-based
> solution will be *much* more complex conceptually and less transparent.
Java gives you a pretty decent sandbox, from what I've seen, but it's of no
use for this problem because we're not running inside a JVM. MAC would
provide finer-grained control over the game process' privileges, limiting
your exposure in the first place. UML is not an access control mechanism.
> 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.
> > 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.
> > (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.
> > 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.
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.
--
- mdz
Reply to: