I've been thinking more about it. The main problem I see is that by definition, the administrative interface has to be able to do almost everything : modify base system files (/etc/hosts, /etc/passwd, /etc/resolv.conf etc.), start and stop daemons, run many different programs, partition drives, etc. That makes "whitelisting" command and parameters practically unmanageable.

Whitelisting is the ONLY way that works without opening BIG gapping security holes. It seems you want to check incoming parameters GLOBALLY. That can't work. Once you know which routine will handle the request, you also know how the parameters have to be validated. My last project had a very simple approach to that problem: The request handler routine had a companion routine that returned a hash reference containing all data required for the validation (Data::FormValidator calls that a profile). Essentially, the main routine first decides which routine will handle the request, then it finds the validation profile by calling <reqhandler>_profile(), validates the parameters, and finally calls the real request handler routine <reqhandler>(). All with whitelists, all secure. And by the way: You DO NOT want to pass the name of the file you want to change with root rights in the form parameters, do you?

I want to make it webserver agnostic (this isn't hard, anyway). I plan to run the existing webserver ( apache for instance) with a special user and configuration. That's simple, and you can use any other webserver simply by using a different startup file in /etc/init.d/ or equivalent.

This will limit you to CGI mode. Combined with AJAX, this will cause a nice load on your server.

If necessary, modules may need an AJAX and a pure HTML version.

Useless work, you need only one version. Make the code work with pure HTML, and add Javascript (with or without AJAX) for the nice look and feel.

Alexander