On Thu, 2017-02-02 at 17:39 +0100, Ralf Mardorf wrote:

On Thu, 02 Feb 2017 11:22:28 -0500, Daniel Micay via arch-general wrote:

...

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.

IIUC Mark Shuttleworth offered manpower to enable a standard mac-based security framework: https://lists.ubuntu.com/archives/snapcraft/2017-January/002247.html

There's a need to improve audit or remove the dependency on it. If there was a kernel configuration option upstream to fully disable audit by default and avoid logging / performance / security issues from it then the kernel maintainers would likely be willing to enable it and the LSMs depending on it again. They were disabled due to the drawbacks of audit, combined with the lack of effort to actually use those LSMs on Arch. It is not simply a matter of people not stepping up to integrate the MACs but also the kernel requiring changes that our kernel maintainers are not willing to carry out-of-tree.

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,

theory Wayland was supposed to be forward

depends on the Wayland compositor choosing to

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

----- Reply to message ----- Subject: Re: [arch-general] user namespaces Date: 2 February 2017 at 18:22:36 From: "Daniel Micay" To: "General Discussion about Arch Linux" : pulseaudio, dbus, etc. In progress on that front but it provide a real security 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.

So your advice for now would be to use grsecurity kernel and forget all those jails and namespaces until someone figure out proper security solution?

On Thu, 2017-02-02 at 19:32 +0200, Francisco Barbee wrote:

So your advice for now would be to use grsecurity kernel and forget all those jails and namespaces until someone figure out proper security solution?

No, the advice is to learn what you are trying to defend against, instead of wasting time on exploring the zoo of sandboxing apps... There is nothing wrong with -ARCH kernel. Cheers, -- Leonid Isaev