At some point, your runs-as-root part needs to trust the job being submitted to it. What level of security is needed to get this trust high enough? What do you, as the SA, require the user to prove to you before you act on their request? Now, what is needed to have a program do the same thing?

Be careful about file system permissions. Perhaps run the CGI submitter under a suexec setup to allow only that CGI to touch whatever mechanism is used to pass information to run-as-root. Think "minimum privilege necessary".

I'm planning on using an suexec like thing (CGIWrap). I don't know of any mechanisms that could be limited by the UID of the CGI process. Maybe a socket? Are there others?

I'd run the web server as a UID that 1) has no shell access; and 2) has no ownership outside the web server. And 3) allow that (and only that) UID to run the root script via sudo.

On the other hand, I'm pressed to think of any root-owned tasks that I'd unload... Do they need to be owned by root? Can they not be cron'd?

My 2¢.

Don't write it yourself if someone else has already written it had more testing.

Especially avoid writing it yourself if it has to do with privileged execution.

Failing to find something thats already been written, don't write a daemon that runs with root privileges. You can use at (man at(1)) to queue up the execution of scripts that do the absolute minimum, ideally in a jail.

You could use Kerberos to authenticate your CGI script to your runs-as-root script (and vice-versa if you wanted even more security).

To avoid a secret being recorded in your CGI script or one of its configuration files, you could run the script in a persistent environment (e.g. mod_perl) and have an operator enter the secret on startup.

It should be sufficient to authenticate the user once. Securing communications between your CGI script and your runs-as-root script is a separate problem from user authentication.

It makes sense. In fact it's quite common to do this, although with authentication in the CGI. The one change I'd make is that instead of doing authentication in both the CGI and the root daemon, I'd only do it in the root daemon, and have the CGI ask it what actions a particular user can perform so that it can present the right options to him. Then, obviously, when the CGI actually submits a job to the root daemon, the daemon needs to authenticate it again.

I'm not sure that you can guarantee that communications are coming from a particular process. But then, provided that you authenticate before performing each action as root, that shouldn't matter. If someone manages to talk to your process in a way you didn't expect, then if they can't authenticate that's great, if they can - well, so what? They could just as easily authenticate through your web interface.

You might even find it useful to have several ways of communicating with the daemon - for example, occasional users might use a web site, more frequent users might have a command line interface.

My advice: If you want security then stay away from Webmin.

Or atleast, that's my advice from looking at it a couple of years ago... it's implementation that is... I gave up trying to explain the security risk to the author... exploits that could be easily verfied (and fixed) were only met with a response: 'fixed in xyz' (testing xyz revealed it was not fix - so much for testing)

Also: webmin runs everything as root. Only thing it takes is one little exploit in one of the module and you have root access. (And unless the code really changed in the past years then I'm sure there are many exploits in it)

One way of promising that input comes from a particular user, (not script), is to have the communication be asynchronous.

Have the CGI application run as user "foo" and create /var/spool/foo which is mode 700.

The CGI script can validate and create jobs in this directory that the root process can examine, validate some more, and then process.

Thats the cleanest separation I've ever used - in general I prefer to use sudo.

I've had/have the same problem. I once hacked on an application that simply runs the CGI as suid and switches back and forth between root and a less privileged user as required. I suppose webmin might fall under that description. Sometimes it's difficult to setup on different systems, but for the most part it's simple and it works, provided you trust your CGI code and what it's doing. You can get a performance boost using Persistent Perl (Speedy CGI), but it also puts the application at odds with mod_perl so it could never run it under mod_perl.

When started to build my own CGI applications I didn't want to mess with full suid run-as-root privileges so my approach to the problem was to create separate runs-as-root suid scripts that do small and defined tasks and leave the CGI scripts to run with what limited access they get from the web server. When the CGI needs to do a run-as-root operation, it executes the run-as-root script passing parameters in the command line, soaking up output from the run-as-root script as return data. One of the parameters passed, is the session id of the CGI script. If the run-as-root can't verify the session id, it simply returns without doing anything.

Splitting the CGI and run-as-root sides into separate scripts offers a lot of flexibility (I think) for how you run the CGI side. But I don't think it's any more secure than a single suid CGI script doing it all. Ultimately, you still depend on the CGI side not doing something stupid with your run-as-root script. I like to think that there's some benefit to be gained by keeping the run-as-root code as small as possible so it's easier spot potential risks, but that's a warm fuzzy, and not necessarily a hard fact.

So far I've only been working with defined functions (reading DHCP leases for instance) but in the distant future I also expect access file systems (user mail spools and home directories for example). When that time comes, I'll probably explore a daemon/socket approach.

I've been thinking about this quite a bit. Send me a pm if you want to exchange some code and talk about it more!

I find it most useful to wrap specific tasks (in Perl, naturally) with taint-safe code that restricts what can be done. Then, you grant sudo access only to that script -- not the system utilities it invokes. Since you're running through a web server, sudo access must be granted to the account under which that web server runs, not the account under which the user has been authenticated.

As far as authentication goes, I don't think you need to do it more than once -- if the user as originally authenticated had a role with additional privileges, he or she can do the advanced tasks. If not, access denied. That said, you might want to include a confirmation dialog for tasks that are somewhat risky -- like rebooting a production server.