[yast-devel] WebYaST: Vendor customization

older
[yast-devel] WebYaST: Network REST...

Jiří Suchomel

13 Aug 2009 13 Aug '09

12:50

Hi! There's already a feature present, it is https://fate.novell.com/307388: Citing from feature description: "Ideally, there should only be a single config dir (or file ?) covering all vendor customization. All customization (the config file, branding images, web style css file(s), etc.) should be contained in a single -branding package." As I'm looking into services module, which should offer Start/Stop options to vendor specific services (fate 306696), I also need some way to provide vendor specific data. Here, the data are: the list of services to show (a must) and optionally custom descriptions and paths to start/stop scripts to such services. So far, I'm using yml file (after Klaus' recommendation) as it is easy to parse and human readable. See attached examples: one is for list of maps (slightly better readable I assume), the second for map of maps (faster access). The file is currently expected under /etc/YaST2 directory. Technically, config file is parsed from YaPI which is called from rest-service, so it is not bound to webYaST usage and theoretically could be used together with YaPI from perl scripts. Comments, ideas? I have one to the feature description above: I'd rather vote for more config files (under same directory) over just one-for-all, as it needs to be parsed for each YaPI call. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz

Attachments:

custom_services.yml (text/plain — 701 bytes)
custom_services.yml.list (text/plain — 688 bytes)

Show replies by date

Klaus Kaempf

13 Aug 13 Aug

13:31

* Jiří Suchomel [Aug 13. 2009 14:50]:

...

Hi!

There's already a feature present, it is https://fate.novell.com/307388:

Citing from feature description: "Ideally, there should only be a single config dir (or file ?) covering all vendor customization. All customization (the config file, branding images, web style css file(s), etc.) should be contained in a single -branding package."

As I'm looking into services module, which should offer Start/Stop options to vendor specific services (fate 306696), I also need some way to provide vendor specific data. Here, the data are: the list of services to show (a must) and optionally custom descriptions and paths to start/stop scripts to such services.

No, not quite. Fate 306696 explicitly talks about a _single_ (vendor specific) service. Multiple services should be covered by /etc/init.d (resp. xinetd) and don't need a separate config file.

...

So far, I'm using yml file (after Klaus' recommendation) as it is easy to parse and human readable. See attached examples: one is for list of maps (slightly better readable I assume), the second for map of maps (faster access). The file is currently expected under /etc/YaST2 directory.

Technically, config file is parsed from YaPI which is called from rest-service, so it is not bound to webYaST usage and theoretically could be used together with YaPI from perl scripts.

Ruby provides nice support for yaml files, so there's no need to involve YaPI here.

...

Comments, ideas?

I have one to the feature description above: I'd rather vote for more config files (under same directory) over just one-for-all, as it needs to be parsed for each YaPI call.

Yes, multiple config files under a single directory make sense. But in this case, there's no need to have a toplevel 'services:' key in the yaml file. 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

Jiří Suchomel

13:37

On Thursday 13 of August 2009 15:31:27 Klaus Kaempf wrote:

...

* Jiří Suchomel [Aug 13. 2009 14:50]:

...

...
So far, I'm using yml file (after Klaus' recommendation) as it is easy to parse and human readable. See attached examples: one is for list of maps (slightly better readable I assume), the second for map of maps (faster access). The file is currently expected under /etc/YaST2 directory.

Technically, config file is parsed from YaPI which is called from rest-service, so it is not bound to webYaST usage and theoretically could be used together with YaPI from perl scripts.

Ruby provides nice support for yaml files, so there's no need to involve YaPI here.

The reason to involve YaPI is different: SCR layer runs as root after user passes the permissions checks, so it has rights to access the scripts. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, 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

Klaus Kaempf

13:47

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

...

On Thursday 13 of August 2009 15:31:27 Klaus Kaempf wrote:

...
* Jiří Suchomel [Aug 13. 2009 14:50]:

...
...
So far, I'm using yml file (after Klaus' recommendation) as it is easy to parse and human readable. See attached examples: one is for list of maps (slightly better readable I assume), the second for map of maps (faster access). The file is currently expected under /etc/YaST2 directory.

Technically, config file is parsed from YaPI which is called from rest-service, so it is not bound to webYaST usage and theoretically could be used together with YaPI from perl scripts.

Ruby provides nice support for yaml files, so there's no need to involve YaPI here.

The reason to involve YaPI is different: SCR layer runs as root after user passes the permissions checks, so it has rights to access the scripts.

Using the YaPI where its needed is fine. But going via SCR and Perl for a simple task easily doable within Ruby doesn't look straightforward to me. 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

Jiří Suchomel

16:37

On Thursday 13 of August 2009 15:47:37 Klaus Kaempf wrote:

...

...
...
...
Technically, config file is parsed from YaPI which is called from rest-service, so it is not bound to webYaST usage and theoretically could be used together with YaPI from perl scripts.

Ruby provides nice support for yaml files, so there's no need to involve YaPI here.

The reason to involve YaPI is different: SCR layer runs as root after user passes the permissions checks, so it has rights to access the scripts.

Using the YaPI where its needed is fine. But going via SCR and Perl for a simple task easily doable within Ruby doesn't look straightforward to me.

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. 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? This is a security risk, as the one who has the right to operate services gets the right to execute custom script.... Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, 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

Klaus Kaempf

19:51

* 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.

...

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.

...

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' 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

Jiří Suchomel

14 Aug 14 Aug

05: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?

...

...
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...?

...

...
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. 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. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, 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

Klaus Kaempf

08:01

* 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

Ladislav Slezak

11:19

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

Klaus Kaempf

17 Aug 17 Aug

11:36

* Ladislav Slezak [Aug 14. 2009 13:19]:

...

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?

Yes. As we're already using Ruby and ruby-dbus, its a practical way without adding new dependencies. http://kkaempf.blogspot.com/2009/02/driving-d-bus-with-ruby.html shows an example.

...

...
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.

Thats why we chose PolicyKit and D-Bus.

...

That's adds more complexity, which can be easily implemented using YaPI.

Using YaPI to leverage existing YaST functionality is the way to go. I am questioning if adding to YaPI just for WebYaST is a practical way. If you think it is, I'm fine with your decision. But this decision includes looking at alternatives and documenting pro and con arguments.

...

...
...
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")

I think this is pretty artificial. We are talking about a vendor config file specifying start/stop commands and passing those to the backend for execution. If a vendor puts "rm -rf /" in there, back luck. If a malicious user finds a way to hack the config file, then this system has a couple of other security issues.

...

It depends how much the system administrator trusts the service admin...

Sure, granting any kind of access is always a matter of trust.

...

...
...
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.

We're in violent agreement for this point. However, configuration and execution are two different things imho.

...

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...

Agreed, thats why its important to discuss, plan, and prototype before starting with the full implementation. 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

Ladislav Slezak

19 Aug 19 Aug

14:33

Dne 17.8.2009 13:36, Klaus Kaempf napsal(a):

...

Yes. As we're already using Ruby and ruby-dbus, its a practical way without adding new dependencies. http://kkaempf.blogspot.com/2009/02/driving-d-bus-with-ruby.html shows an example.

I see, that makes sense. Thanks for the link.

...

Using YaPI to leverage existing YaST functionality is the way to go. I am questioning if adding to YaPI just for WebYaST is a practical way.

I see, so we want to have the REST services YaST independent as much as possible, right? [...]

...

...
Yes, but a malicious user could do ExecuteScript("start", "rm -rf /") instead of ExecuteScript("start", "/usr/bin/vendor_service")

I think this is pretty artificial. We are talking about a vendor config file specifying start/stop commands and passing those to the backend for execution. If a vendor puts "rm -rf /" in there, back luck.

Yes, that's bad, but I mean something different. It means that the backend will execute _any_ requested script with root privileges, isn't it? So we have to ensure that the DBus backend will accept requests only from webyast user so the user with custom services access rights cannot use the backend directly (e.g. via dbus-send). -- 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

Klaus Kaempf

14:44

* Ladislav Slezak [Aug 19. 2009 16:33]:

...

Dne 17.8.2009 13:36, Klaus Kaempf napsal(a):

...
Yes. As we're already using Ruby and ruby-dbus, its a practical way without adding new dependencies. http://kkaempf.blogspot.com/2009/02/driving-d-bus-with-ruby.html shows an example.

I see, that makes sense. Thanks for the link.

...
Using YaPI to leverage existing YaST functionality is the way to go. I am questioning if adding to YaPI just for WebYaST is a practical way.

I see, so we want to have the REST services YaST independent as much as possible, right?

Not quite. We want the REST service influencing existing YaST as little as possible. So keep the changes to existing yast2-* packages at a minimum. Ideally, webyast should just be an add-on, leveraging existing (YaST2-)functionality as much as possible.

...

[...]

...
...
Yes, but a malicious user could do ExecuteScript("start", "rm -rf /") instead of ExecuteScript("start", "/usr/bin/vendor_service")

I think this is pretty artificial. We are talking about a vendor config file specifying start/stop commands and passing those to the backend for execution. If a vendor puts "rm -rf /" in there, back luck.

Yes, that's bad, but I mean something different.

It means that the backend will execute _any_ requested script with root privileges, isn't it?

Right. However, the script path is kept completely in the backend. The unprivileged part reads the path and passes it to the privileged part (scr bash agent). So the only way to tamper is to have access to the system and hack the backend code or change the config file. I'd says we can easily live with this risk.

...

So we have to ensure that the DBus backend will accept requests only from webyast user so the user with custom services access rights cannot use the backend directly (e.g. via dbus-send).

Thats _exactly_ what PolicyKit is for. 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

Duncan Mac-Vicar Prett

13 Aug 13 Aug

16:16

On Thursday 13 August 2009 15:37:12 Jiří Suchomel wrote:

...

The reason to involve YaPI is different: SCR layer runs as root after user passes the permissions checks, so it has rights to access the scripts.

They are configuration items, not scripts, why should one need special rights? -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Jiří Suchomel

16:39

On Thursday 13 of August 2009 18:16:02 Duncan Mac-Vicar Prett wrote:

...

On Thursday 13 August 2009 15:37:12 Jiří Suchomel wrote:

...
The reason to involve YaPI is different: SCR layer runs as root after user passes the permissions checks, so it has rights to access the scripts.

They are configuration items, not scripts, why should one need special rights?

But someone has to really start or stop selected service, so at the end, we need a root access to the system. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, 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

Duncan Mac-Vicar P.

14 Aug 14 Aug

09:05

On Thursday 13 August 2009 18:39:25 Jiří Suchomel wrote:

...

On Thursday 13 of August 2009 18:16:02 Duncan Mac-Vicar Prett wrote:

...
On Thursday 13 August 2009 15:37:12 Jiří Suchomel wrote:

...
The reason to involve YaPI is different: SCR layer runs as root after user passes the permissions checks, so it has rights to access the scripts.

They are configuration items, not scripts, why should one need special rights?

But someone has to really start or stop selected service, so at the end, we need a root access to the system.

Jiri

Yes, that is why we hide YaPI or SCR calls in a model. But to know which services are available (from vendors perspective, aka read the vendor config) you don't need root, and if you did, then you need root to get the file content, but there is no need to parse it at the root side. so either you have services -----------> dbus/YaPI/SCR -------------> rest-service vendor.yml -----------> File.read -> YAML.parse --> or, if the file really needs root permissions, you get services -----> dbus/YaPI/SCR -------------------------------> rest-service vendor.yml -----> dbus/YaPI/SCR (read content) -> YAML.parse --> The configuration reading (and how it affects what the Service model returns can be hidden in the same YaPI wrapper that simulates an ActiveRecord so for example it returns results based on the vendor config. Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

5370

Age (days ago)

5376

Last active (days ago)

List overview

Download

14 comments

5 participants

participants (5)

Duncan Mac-Vicar P.
Duncan Mac-Vicar Prett
Jiří Suchomel
Klaus Kaempf
Ladislav Slezak

[yast-devel] WebYaST: Vendor customization

tags

participants (5)