Summary: | www-client/chromium: suid USE flag should be added to make suid binary optional | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Karol Herbst <gentoo> |
Component: | Current packages | Assignee: | Chromium Project <chromium> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Karol Herbst
2015-05-24 09:25:27 UTC
I'm a bit conflicted on this: we have no direct control over what kernel features are enabled, and the suid sandbox provides a nice fallback if the namespace support isn't enabled.
> Also having a suid'ed binary with a lot of potential attacks over the web is a big security concern.
It's suid because that's the only way it can chroot under normal conditions. It's a security feature, and less so a "risk". I'm sure it has been very carefully coded with security in mind.
there could be a post install message in the ebuild, that if suid is disabled, this and this kernel feature has to be enabled to have an adequate sandbox. There could be also a link to "chrome://sandbox/" so that the user can check easily, if enough kernel features are enabled. (In reply to Mike Gilbert from comment #1) > I'm sure it has been very carefully coded with security in mind. Yeah well, there are a lot of security related libraries out there and I am sure that most of them are also very carefully coded with security in mind, but sometimes there is a vulnerability and it would make sense to be able to reduce the attack surface from the internet. See https://bugs.chromium.org/p/chromium/issues/detail?id=312380 and https://bugs.chromium.org/p/chromium/issues/detail?id=598454 . Looks like we're getting closer to being able to enable this. |