If one app get compromised, then all the apps gets compromised.
Indeed, if I manage to get access to one app, I can get access to all other app, but gaining access to the auth cookie.
Then the security of the full install is the security of the less secured app.
Did you take any step to mitigate this?
Why allowing people install as subdomain?
At IndieHosters, we decided to forbid that for security reasons.
PS: Is it the right place to discuss this kind of issue?
PPS: I want to discuss that in an attempt to merge our packaging system with yours
I don’t understand the security issue. Can you explain why and how “If one app get compromised, then all the apps gets compromised.” is anything related to an install on a subfolder (or a subdomain) ?
Plus, the good practise is to run each app with a different user, some apps are already doing this but most run under www-data for now.
Ok, let’s imagine a user that has a domain: example.org he has 3 application like WordPress, piwik, ownCloud installed in path like /blog, /stats and /cloud
When he logs in as an admin on each app, a cookie is stored inside his browser. The security policies of browsers make that the app have access to all the cookies stored for the domain.
Now let’s imagine WordPress had been compromised. The attacker has control of the WordPress of the user. It means he can gather all cookies of the user for this domain. so he can get access to the ownCloud admin cookie and login to the admin interface.
To sum up, when you use subfolder, it means that the security of the whole “domain” is the security of the less secured app. Is it clearer?
(The user that run the app does matter in this case, but not that much, we are more on the side of the browser)
It’s an interesting issue and a preoccupying one. So if I understand everything: if I’m logged on my wordpress admin interface and an attacker has access to my cookies he can gather them all to log onto my other apps ?
Well it seems true, but I think you miss an important point here: the SSO.
If an app get compromised, the only cookie an attacker need to access other apps (regardless if they are on the same domain or not I think) is the SSOwat one.
So yes the security of the full yunohost install will always be the security of the less secured public app or the security of SSOwat.
There is almost nothing that can be done to prevent that but it’s a non issue for me. For me yunohost is not about hosting public faced apps. Sure you can host a wordpress, it’s ok for a personnal blog but yunohost is not designed to host a high traffic or a highly customized wordpress. With a basic and up to date wordpress (no plugin) you risk almost nothing, it’s the most used cms in the world, you small yunohost will be the last to be attacked. Most of the other public-faced apps are very simple and doesn’t have a wide attack surface.
The use of subfolders really make sense in a user point of view, subdomain are complicated (they need a dns entry) and it’s nice (and easy) to have just one domain to use.
In general current users have one ssl certificate for one subdomain, they don’t have a wildcard one, so in this configuration, there is no choice.
With the next let’s encrypt integration, the question is not so simple. DNS can be configured with a * to redirect all subdomains.
We should make a small documentation about pro and cons regarding to subdomain. An other pro for subdomain, is that you can migrate part by part your server…