About Archive Tags RSS Feed


Security changes have unintended effects.

7 September 2012 21:50

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, where xxxx is the userid:

steve@steve:~$ id -u s-steve

steve@steve:~$ sudo lsof -i :1019
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



Comments on this entry

icon Riku Voipio at 17:16 on 7 September 2012

There would have been a third choice, right? Eg switching to email server that doesn't have setuid /usr/sbin/sendmail. For example:

~$ ls -altr /usr/sbin/sendmail
-rwxr-xr-x 1 root root 25884 May 5 2011 /usr/sbin/sendmail
~$ dpkg -S /usr/sbin/sendmail
postfix: /usr/sbin/sendmail

icon Steve Kemp at 17:27 on 7 September 2012

That would be a valid third choice, yes.

Oddly enough it didn't occur to me, but that's because I'm pretty happy with my exim setup otherwise.

icon Sven Mueller at 11:12 on 8 September 2012

In a relatively similar situation, I installed a patched version of the ssmtp package, which only differs from the original ssmtp package in two ways: It doesn't conflict/provide my and it diverts the installed sendmail, replacing it with its own one. So calling sendmail results in immediate delivery to some other mta via smtp.