Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] WebYaST: Vendor customization
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Fri, 14 Aug 2009 10:01:18 +0200
  • Message-id: <20090814080118.GE4645@xxxxxxxxxxxxx>
* Jiří Suchomel <jsuchome@xxxxxxx> [Aug 14. 2009 07:44]:
On Thursday 13 of August 2009 21:51:35 Klaus Kaempf wrote:
* Jiří Suchomel <jsuchome@xxxxxxx> [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)

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.

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups