I need to write a web application that acts as a configuration interface for some system services. Meaning it will probably change some kind of configuration file and has to restart (linux) system services.

I was wondering how to design such a thing in a secure way. It is very similar to router web interfaces and such, so I had a quick look at some of these as well as webmin.

Basically, I could run the web service/CGI-Script/etc. with root privileges, filter the input as good as possible and just write to the system and execute whatever program I'd like.

This does not seem very secure. I would like to achieve some kind of privilege separation.

Maybe having my web app run as unprivileged user and pass the Information to some privileged daemon/service, i.e., having a Python web app writing the infos to a file and notifying the daemon or use unix sockets to communicate with this backend program.

Any ideas or experience you could share regarding this issue?

Thank you very much in advance.

  • Go for abstraction layer method. Make a python library which contains restricted list of functions(that you want admin to perform from web interface). This library then calls more privileged services. But to make it perfectly secured you will have to consider sandbox type system. So if you use SELinux try to use its inbuilt sandbox. Such techniques have been inherently implemented in various system these days!
    – Akshay
    Commented Jan 5, 2013 at 19:02
  • I'm not exactly sure what you mean. So I have a python lib calling system functions. When I include this lib in my (python) web app, it still needs to run as root. The calls are part of the web app after all. Commented Jan 7, 2013 at 9:45

1 Answer 1


You've mostly answered your own question. You're right to dislike running the web app as root, no matter how you run it. You're right to look at separation of priviledge to bridge the gap between the less- and more-secure environments. I'd just add that your chosen bridge (and I like text files for this) should describe the action to be performed, not the technique by which it is performed. So have your less-secure environement write an "action file" that says restart_cron instead of /etc/init.d/crond restart. And have your more-secure environment check the contents of the "action file" very carefully, especially anything that it winds up invoking as part of a command. In general, if you think of a way to make the more-secure environment simpler to use by the less-secure, go in the opposite direction.

  • Thanks, very helpful. Just to make sure I understand you right, with you last sentence you mean that I should put the privileged back-end component into "the drivers seat" instead of "being called" by some other process? Well, if I use text files I have the problem that I need some kind of notification or polling to see when they change. Also if I pass parameters through this I will have to carefully sanitize them, but I'm not sure whether I can prevent shell injection completely. Commented Jan 7, 2013 at 9:49
  • Yes, I'm suggesting your back-end component be a daemon running independently of your front-end. There are lots of ways to wake such a beast up, including setting up a monitor that awakens the sleeping daemon when a file appears in a particular directory. As to preventing shell injections completely, well, this is why programming is a profession that pays well. It can be done, and you should either do it or not write root-level code. Sorry to sound harsh, but that's the truth of the matter. Commented Jan 7, 2013 at 11:49
  • OK, just what I was thinking. Indeed very direct :D But I guess you're right. Commented Jan 7, 2013 at 12:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.