On 14.8.2009 10:01, Klaus Kaempf wrote:
Yes, we just need this. But do we currently have such service, other than SCR?
The ruby-dbus library offers such functionality.
Could you be more specific? Do you mean writing a new DBus service?
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.
I agree, if we can do a simple task without YaPI let's do it. The problem is how to do some task with root privileges in a secure way. That's adds more complexity, which can be easily implemented using YaPI.
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.
Yes, but a malicious user could do ExecuteScript("start", "rm -rf /") instead of ExecuteScript("start", "/usr/bin/vendor_service") It depends how much the system administrator trusts the service admin...
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.
Yes, but the user could not run anything else except what the vendor has configured. With full script path user with service admin rights is equivalent to root, because he can start _ANY_ command as root. Is that acceptable? Again, it's about trust...
As said before, lets keep it simple for now and get it working. Tightening security is a small refactoring later.
Well, if we later would need to change the architecture completely it might not be a small refactoring... -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org