• Taint mode is just the first step. Each parameter should be validated as strictly as possible. The API could support this by requiring a "description" of the expected parameters to get access to the (validated) parameters. Data::FormValidator is a good start, but it has some legacy problems that I solved in my last project by writing a cleaner re-implementation (that is unfortunately not available to the public).
• Perl 5.6 or even perl 5.005 should be no big problem unless you need Unicode. In that case, the minimum requirement should be perl 5.8.1.
• "Own webserver" does not mean that you should write the 10.000th implementation of the server side of the HTTP protocol. But the HTTP server for the tool should be independant of any other parts of the system. Especially on a webserver machine, you don't want to mix public web access and system configuration. You would depend on the security of the public web server, misconfiguring that server would disable your tool, and especially the Apache web server has far too many features that could disturb your tool or give the public full access to the machine. I don't propose an embedded web server. The Web server could (and should) live in a completely independant process. It can be a very small and simple server, as it does not have to handle big loads, it should be able to deliver some static content (images, CSS, JS), and it should be able to pass requests to perl, using CGI, FastCGI or perhaps an equivalent of mod_perl. CGI and FastCGI have the advantage of an additional separation of web server code and application code. A fatal error in the application does not kill the web server, just the application process.
• OS compatibility: Just don't expect any system to behave like a linux system, or a specific linux distribution, and most things should just work. If you need external tools, don't expect them to work like GNU tools. Don't expect them to be in /usr/bin, don't expect the default shell to be a recent version of bash. Using different plugins for different OSes is a good idea, but for components like an Apache configurator, one tool should be able to handle all OSes. That means that pluigins need a configuration space, e.g. to set the location of apachectl and httpd.conf.
• AJAX is nice for some enhancements, like auto-completion or maybe a pure-Javascript terminal. Restrict yourself to use Javascript only as an enhancement, not for basic functions, and you will get a "modern" interface which still works nicely in links, lynx, NN3, TV internet set-top boxes, and old smartphones. Valid and semantic (X)HTML and valid CSS would also be good for this purpose.
• sudo would also be my first tool for the privileged helper process, but as soon as we leave modern Linux distributions, sudo may disappear. On some distributions, sudo is still optional today. During the installation, the user would have to add rules to allow the unprivileged user to execute the privileged helper process. I think that a classic suid wrapper is easier to install. Unfortunately, this requires writing secure and paranoid C code. The Apache suexec wrapper security model could be a good starting point. You don't want any user to be able to edit /etc/passwd using the wrapper, do you?

The privileged process should do as few tasks as possible. It should not start parsing third party configuration files, or rewrite tons of XML files. For some tasks, like reading and writing configuration files, you could get away with a stripped-down version of cat, chmod, chown, mv or cp, plus the paranoia code based on suexec. But when you want to start a service, the privileged process needs to execute an arbitary program with arbitary parameters as root, like apachectl, exim, smbd, nmbd, sshd, inetd, or the svc tool from daemontools. It would still run all paranoia checks, but it would give the tool full root access without requiring a password. Still better than running everything as root.

Alexander