Skip to content

Security changes have unintended effects.

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

  1. [gravitar] Riku Voipio

    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

  2. [author] Steve Kemp

    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.

  3. [gravitar] Sven Mueller

    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.