Yes, I know how it work I study when I have problems. But this architecture mean, that user yastws has big permissions on that system like changing installed software (or uninstall it) or settings some basic system settings and this user run service which is reachable from network. So for me is still quite problem that if someone hack server, then he owns many permissions and then is quite easy get root account. As example I think that is possible to share via samba important data or stop important many services or change user permissions...which can change permission also for yastws itself and can allow ssh login to easy backdoor. If we still use current solution then we must ensure that our rest-service cannot avoid checking permissions for logged user or run custom command as rest-service user is strong user. JR Stefan Schubert wrote:

P.S.: Here is a general description how it works:

http://en.opensuse.org/YaST/Web#General_2

Greetings Stefan

Stefan Schubert schrieb:

...

Hi, nice ideas which are VERY interesting.

Some history:

When we have started the WebYaST project only the SCR DBUS interface of YaST has been available to communicate with YaST. So mostly all calls have been done via the SCR::Execute by starting YaST modules in the commonline mode. For that these rights have been set in the RPM post install script for the user "yastws". In order to improve the security only a "white list" of commands are valid while calling SCR::Execute (have a look to "def execute (arguments, environment=[] )" in webservice/lib/scr.rb)

Now as more and more YaST modules provide a DBUS interface these SCR:Execute calls are no longer needed. ( I think we will change this step by step ). But now each webservice plugin has to set the special rights by his own for the user "yastws". ( I assume while installing the package) So the user "yastws" has only rights for special YaST resources. From my point of view this would fulfill the security issue. But may be I am wrong....

I have asked Ludwig concerning this concept and at least he has NOT said NO :-) (Ludwig I hope you have no objections to add you again to the discussion. Perhaps I have missed something ).

To the other ideas:

Josef Reidinger schrieb:

...

Hi, I study permissions problem on 11.1 in language module. I found (with mvidner help) root of problem in yast dbus backend call from yast-webservice. I check in webservice if user has rights (in this case root) and then I call to dbus. Problem is that dbus backend check not again root but again caller which is yastws user. So first solution which work is grant yastws all rights in rpm post-script as we do for root. But I think that this is quite big security issue as this mean that anyone who crack into webservice has all rights because he can act as yastws user with all rights to yast backend. This should be somehow solved. MVidner have idea that we could run backend as logged user instead yastws. This has problem that we must somehow handle sending passwords and also multiuser process (another user need maybe another port).

In the future we will have one special (unique) port for the YaST-webservice which will be applied by an organisation ( I have forgotten the name. Klaus has said that he will take care about :-) ) So variable port addresses will be not a solution here.

...

My idea is use ssh with keys authentication and execute dbus call via this ssh, so then we can act as logged user and not as yastws.

I am not sure if we are really improve our security here. Ludwig what you are thinking about this suggestion?

...

Any other ideas or comments? thanks JR

Greetings Stefan

-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

Yesterday I little thinking about this security issue and maybe I find quite good solution. Current problem is that quite big part of code is executed by user which has strong permissions (yastws). And this code is bigger then it looks like. It is not only rest-backend code, but also rails code and ruby code. So if some security issue is find in ruby or in rails webyast is still affected. My solution is use ticket system. DBus interface provide authentification call which authorize user and return one-time random authentification ticket which identify this user. And then all calls to dbus interface pass additional parameter authentification ticket and then dbus interface check user belonging to this ticket. Advantages: - yastws doesn't have any special permission only can try get authentication ticket - ticket is one-time so sniffing without immediate ticket usage is useless - even if ticket is used immediately by attacker then it still have only permission of authenticated person - it is possible to separate user in webyast and in system - It can be separated from plugin and do it in background Disadvantage - It need another interface to module which add special parameter to call - password must be somehow passed (but I think that current version also pass it from frontend to backend and this only add pass from backend to dbus) JR -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org