Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] WebYaST: Vendor customization
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Mon, 17 Aug 2009 13:36:25 +0200
  • Message-id: <20090817113624.GD29397@xxxxxxxxxxxxx>
* Ladislav Slezak <lslezak@xxxxxxx> [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

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

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
run arbitrary script. Having function ExecuteScript
("start", "path_to_script"), every user with rights to ExecuteScript can
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

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

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