Plugin System: Root/user levels

[jmstacey]

I have a plugin that is run from the user level, but portions of it need root access to modify certain files.
Unless somebody can provide a workaround I would like to make a request to provide at least some ideas of how to workaround this.

Idea 1: All plugins be run with root/admin permissions by default. Scripts would then reduce their access level to the running users using for example, php's posix module. That would allow portions of the script to run as root as needed, however this method may not be considered safe?

Idea 2: DirectAdmin provides a gateway of sorts in which the plugin tells the gateway what needs to be run and at what access level. The "gateway" does so accordingly and returns the results.

Idea 3: One specific filename is set aside for plugins which will be run as root. For example root.php could be run as root when DirectAdmin executes it. A php script in that plugin could then issue DirectAdmin the command to execute that one script as root, however it might be hard to pass information between the two scripts.

Those are just ideas, I look forward to some feedback on how to get a script or portions of a php script to run as root when executed by DirectAdmin.

(Only other workaround is make the necassary files world readable/writable which is probably even less safe than idea 1)

 

[Chrysalis]

Well I think what you might be needing is a suid plugin that starts as root then will carry on running as the user. Directadmin must have some sort of root priveledges since its able to add/remove users and start daemons at will.

 

[ballyn]

For my courier plugin, I ended up compiling a wrapper that is suid diradmin which can only call the specific script that I've written to access the database which is then owned and readable only by diradmin. This keeps the database credentials secure on the server. You could probably use a similar approach if you needed root.

Idea 1: IMO, plugins should never run with root/admin privileges. In the current model, I don't think this is possible anyway since all scripts run with the logged in user level. Overriding this would severely break the security model currently in place.

Idea 2: This would be interesting, but securing it would be tricky. I kind of expected something in the API that could do this, actually, but the current model explicitly denies it. If you had an API call, for example, that could elevate privileges for a script, what's to keep anyone from writing their own script and calling that method in any way they choose?

Idea 3: I believe what I described above is close to this idea. There are a lot of security implications to this, too, however. For example, my wrapper has the path to the script it is allowed to execute compiled into it. This keeps a user from abusing my suid wrapper to call an arbitrary script--the wrapper can only call my script which then does its own security check to ensure that the user calling the script is calling it via DA and that the user actually has privileges to execute the command (in my case, modify a row in a databse), etc. It's actually pretty simple to pass variables since this is all cli php which uses the environment to do so.

 

[jmstacey]

I sent you a pm ballyn, but to share for the rest of the public.
Could you explain your wrapper a bit more.
To me it almost sounds as you have an additional daemon that is continuously "listening" for commands to run, runs them, then returns feedback? (Although I'm not sure how that process would work)

 

[ballyn]

No, it's not a daemon... just a compiled c program that executes my php script. You can't use suid to elevate privileges for an interpreted file (like a php script) under linux, but if you use a compiled program that executes a script, the suid privileges get propogated.

I think that you could probably also use suidperl to achieve this if you have it installed... that package will allow perl scripts that are suid to elevate correctly.

 

[jmstacey]

Compiling a wrapper will be a big headache to distribute among several operating systems.
A universal solution would be nice.

I'd also prefer not to require the root password and use exec() to su to root.

 

[jmstacey]

I played around with this all day without luck. Even though a user comment here said it was possible:
http://us3.php.net/manual/en/function.posix-setuid.php

I finally whipped up a small C program and it worked like a charm. I'll just have to keep in mind to be verrry careful writing the php script that is executed or....

I'm still interested in hearing more opinions and such since even using a wrapper may not be that secure (since it is root and all)

I have been looking at sudo, it might be worth it to bundle it with plugin's and just use exec() and sudo together.
It loooks like only users/groups can be set in sudoers so a wrapper might still be required but then instead of suid'ing(?) to root, you could do it to a less disaster prone username and group, such as a new one installed with the plugin (yourpluginname)

 

[skruf]

Hey,

I wanted to revive this discussion as we've got a plugin we use inhouse to edit the Exim related files. (blacklist, whitelist, etc.)

It currently puts a line in the sudoers file for admin, only allowing it to run one php file used to do the writing.

Any thoughts on the good, bad and ugly of doing this? I'm interested in any opinions on security, etc. related issues doing it this way.

Thanks, David

 

[nobaloney]

Don't ever send your admin password insecurely (of course you should never do that anyway ).

This means don't ever check admin email except with a secure login (we forward it to a different account to read), and never log into your control panel without a secure cert installed.

Jeff