[arch-general] user namespaces

[Daniel Micay]

On Thu, 2017-02-02 at 17:06 +0200, Francisco Barbee via arch-general
wrote:
> So what's your alternatives/setup usable on Arch
> (not android, not ChromeOS)? We heave disabled
> SElinux, disabled Apparmor, disabled user
> namespaces, PIE not enabled by default and only
> partial relro. What's left then? Swimming naked?

You're venturing totally off-topic here, but I'll respond anyway.

The intention is to enable PIE by default but no one is stepping up to
help Allan with it. There are binutils test failures that need to be
triaged, and either fixed or ignored if they are not real failures.

Arch has a hardened linux-grsec kernel package which offers multiple MAC
options enabled. The reason for SELinux and AppArmor not being enabled
for linux or linux-grsec has to do with audit. If people were willing to
do a bit of work, all of the MAC implementations rather than only
grsecurity RBAC and TOMOYO could be available. I don't see much value in
a huge amount of choice here anyway. None of it is particularly relevant
to sandboxing desktop applications due to X11, pulseaudio, dbus, etc. In
theory Wayland was supposed to be forward progress on that front but it
depends on the Wayland compositor choosing to provide a real security
model.

Unprivileged access to user namespaces is an anti-security feature, not
a security feature. User namespaces themselves offer essentially zero
value to application containers. The uid/gid mapping is superfluous when
using a different approach and it isn't even properly supported since
there's so much missing. The distribution would be significantly less
secure with them enabled for unprivileged use. You should be thankful
that the feature is not exposed by default if you really care about
security rather than just being a concern troll.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20170202/21450d30/attachment-0001.asc>