A couple of months ago I was experimenting with adding no-new-privileges to various systems I run. Unfortunately I was surprised a few weeks later at unintended breakge.
My personal server has several "real users", and several "webserver users". Each webserver user runs a single copy of thttpd under its own UID, listening on 127.0.0.1:xxxx, where xxxx is the userid:
steve@steve:~$ id -u s-steve
1019
steve@steve:~$ sudo lsof -i :1019
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
thttpd 9993 s-steve 0u IPv4 7183548 0t0 TCP localhost:1019 (LISTEN)
Facing the world I have an IPv4 & IPv6 proxy server that routes incoming connections to these local thttpd instances.
Wouldn't it be wonderful to restrict these instances, and prevent them from acquiring new privileges? Yes, I thought. Unfortunately I stumbled across a down-side: Some of the servers send email, and they do that by shelling out to /usr/sbin/sendmail which is setuid (and thus fails). D'oh!
The end result was choosing between:
- Leaving "no-new-privileges" in place, and rewriting all my mail-sending CGI scripts.
- Removing the protection such that setuid files can be executed.
I went with the latter for now, but will probably revisit this in the future.
In more interesting news recently I tried to recreate the feel of a painting, as an image which was successful. I think.
I've been doing a lot more shooting recently, even outdoors, which has been fun.
ObQuote: "You know, all the cheerleaders in the world wouldn't help our football team." - Bring it On
Tags: blog, kernels
|