[haiku-commits] Re: r41581 - in haiku/trunk: headers/private/interface src/add-ons/decorators/BeDecorator src/add-ons/decorators/MacDecorator src/add-ons/decorators/SATDecorator src/add-ons/decorators/WinDecorator ...

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Fri, 20 May 2011 09:11:10 +0200

On 20.05.2011 05:48, Rene Gollent wrote:
On Thu, May 19, 2011 at 8:03 PM, David McPaul<dlmcpaul@xxxxxxxxx>  wrote:
How is this different to what was there before?

Previously, only a name was given, which the app_server loaded from a
fixed location, namely the decorator add-ons folder. The interface now
lets you give it a path to any arbitrary location on disk, which is
more or less asking for malware, since that opens the door for a
downloaded app to ask the app_server to load it as an add-on and then
consequently execute malicious code with OS-level privileges
(previously such a scenario wouldn't have been possible unless the
user went out of their way to save the executable in question in the
decorator add-on dir). While not strictly an issue right now since
that's the same privilege level the single user of the sys has
anyways, once we go multiuser that kind of vector is unacceptable
security-wise.

I am not too concerned for two reasons. 1) This is not actually anymore open than it was before. As you pointed out yourself, the user is currently running as root anyway, and it would be no different for a malware to put an add-on in the right place. 2) When we fix Haiku for a multi-user scenario, we need to secure the whole app_server communication anyway. It's not so interesting what you can and can't do via the app_server link in principle, but what priviledge level you need to have in order to do so and how that is enforced.

Best regards,
-Stephan

Other related posts: