The security incident on alioth resulted in some rather bad press. Much of which isn't very accurate (the server was not cracked, certain applications installed by users were abused, but no privilege escalation happened) and not fair (this is not a "dumb" web server, but a server to be used by "third party users" to run web applications on).

It's also worth noticing, that everybodys favorite Joerg Schilling commented [de] (read: flamed) on these articles in his best troll manner. In fact, he's known to be a frequent troll on heise, often posting "corrected" versions of articles related to Solaris or Linux. If you've read his posts there and his mails you just can't take him seriously. Don't feed the troll, and just ignore anything you hear from him. Including any cdrecord stuff, please switch to cdrkit/wodim!

To avoid this type of problems I see the following choices:

• Disallow users to install their custom PHP scripts
• Require users to send their web applications through a security review process and installation by the admins
• Write and run some security scanner on these applications, that will detect known vulnerable versions of installed applications (but that means someone needs to write lots of detection code, and update it with every related security announcement...)
• Modify PHP to be harder to attack (i.e. remove functionality, that will potentially break stuff we want to have)
• Use SELinux to jail the webapps a bit more. E.g. SELinux could have prevented the attackers from setting up their IRC proxy.

As you can see, the first option is the easiest, but it's contrary to the idea of alioth - being allowed to run custom web apps. Face it: a webserver serving only static pages is much easier to keep secure than one where users are allowed to install custom applications. And a project of Debians size needs to offer a web server where developers can run custom CGI.

The other options mean much more work; especially the SELinux option would increase security a lot, even with PHP, but it means someone will have to spend a lot more time on administrating the system, and especially helping users when their web app doesn't work right because of SELinux security restrictions. For further increases in security PHP would need to be patched with some SELinux support: it shouldn't be allowed to include() or execute files written by the web server and not uploaded via ssh. For this, PHP needs to understand security contexts.

One thing we should go for, however, is to provide more common services on alioth. For example wikis. Maybe we could setup a shared MoinMoin instance for all projects on alioth that want to have a wiki. And maybe offer "security supported" installations of other common webapps as well (e.g. forums, trac). Attacks usually exploit widely used applications such as wikis or forums. And even when 90% of the users on alioth upgrade their software on time, there are still 10% vulnerable.

And maybe we can setup a box for the custom applications that actually is SELinux enabled in one or two years, when enough people are familiar with it and on how to write and maintain an appropriate policy.