having the suid sandbox is not the only way to adequately sandbox chromium, because other features from the Linux kernel can be used instead. Also having a suid'ed binary with a lot of potential attacks over the web is a big security concern. Please meake the suid feature optional in both chromium and google-chrome Reproducible: Always
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.
Should be fixed now with https://gitweb.gentoo.org/repo/gentoo.git/commit/www-client/chromium?id=58f3fd3b9db9ce046e50a5a82b1d2499ebcaaf47 .