SUID server

[Adam Langley <agl () LINUXPOWER ORG>]

Despite many peoples best efforts over many years, it seems that SUID programs
cannot ever be secure. Just recently we have the traceroute bug - how long
has traceroute been around?

I suggest we give up and accept that SUID programs are just a bad idea. So
rather than let processes run as someone else - where the user running has
absolute control over the environment - create a SUID server that does certain
tasks and passes data over a single channel.

The suidserver would need to be able to load .so files on the fly because
packages would need to install their own backends. Now the .so's have to be
secure, but that's no big problem. (put them in /lib like PAM modules)

So the suidserver is run by root at startup and all communication is via a 
single channel. Thus an attacker has no control over fds, environ, caps,
etc. And by making the channel protocol standard for the suidserver, it only
needs to be checked once (less room for errors) before begin passed to the
backends.

So take traceroute as an example:

A user would run a small, normal binary that parses command line args. The
user can do whatever they like this this - it runs as them so if you can
overflow it, it doesn't matter.

The frontend connects and passes the arguments to the suidserver which
checks for a traceroute backend. If it's not loaded into memory it dlopens()
the traceroute.so file and continues. The data from the frontend is checked
and parsed and passed the the traceroute backend which (running as root)
fires off packets and sends the data back, via the suidserver, to the frontend
which can display them as it wants.

Now a badly written backend and still fsck things up - but I think it would
much easier to write a secure backend becuase of the single channel of
communication.

It also allows GUIs (linked against Xlib and everything) to act 'suid', which
they can't without nasty hacks execing the command line tool and parsing the
output.

Now a lot of the details need to be sketched out (which IPC? what's the 
protocol?), and I'm not sure every suid program can work this way (what about
su?). But anything which cuts down on suid holes is worth a shot.

AGL

-- 
Just because you don't understand it doesn't mean that it doesn't work

Attachment: _bin
Description: