Re: [yast-devel] WebYaST: Vendor customization

* Jiří Suchomel [Aug 14. 2009 07:44]:

On Thursday 13 of August 2009 21:51:35 Klaus Kaempf wrote:

...

* Jiří Suchomel [Aug 13. 2009 18:37]:

...

The scripts (either vendor specific ones or init scripts) should be called by YaPI because of SCR running with root privilliegies. Or maybe there is some other way, but I don't know about it.

Well, one just need a service running as root behind D-Bus. It doesn't have to be SCR.

Yes, we just need this. But do we currently have such service, other than SCR?

The ruby-dbus library offers such functionality.

...

...

So you mean that parsing the config file could be done on ruby level? That is possible, but how should the results (the example of result is path to executable script) be passed to YaPI layer? As a parameter?

Sure. Just as SCR::Execute(.bash) gets the command as parameter.

Well, yes, at the end. But I thought you are arguing against SCR...?

I am arguing against SCR if this means implementing a new service/agent. I am arguing in favour of SCR (resp. Yapi) where we can leverage existing functionality.

...

...

This is a security risk, as the one who has the right to operate services gets the right to execute custom script....

Sure, executing the script is the main purpose of (gettings rights to) 'services'

But there are risks and risks.

The security argument is bound to YaPI usage, if there's no YaPI and everything is done inside rest, than there's no questioning, of course. But YaPI gives nice access to SCR and SCR is root-running service behind D-BUS.

With YaPI, I could only expose a function to start/stop given service, not to run arbitrary script. Having function ExecuteScript ("start", "path_to_script"), every user with rights to ExecuteScript can run arbitrary stuff.

I believe this is sufficient. Rights to "ExecuteScript" means rights to execute (an arbitrary) script. Well, this script has to exist on the system first so a potential attacker needs also right to store/manipulate a script.

With function ExecuteScript ("start", "my_app"), user with ExecuteScript rights can really only operate "my_app", when the information about my_app's start script is stored in a file with rights 600 and parsed directly by ExecuteScript function.

PolicyKit checks are per-function and not per-argument afaik. So raising the security bar would need ExecuteMyAppScript() but we don't know what MyApp is since its vendor configurable. As said before, lets keep it simple for now and get it working. Tightening security is a small refactoring later. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org