Re: [arch-general] user namespaces
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?
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.
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
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, 02 Feb 2017 11:49:38 -0500, Daniel Micay via arch-general wrote:
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.
Hi, don't get me wrong, I'm not interested in this for my Arch Linux based digital audio workstation. I only want to provide a pointer for the OP, assuming the OP wants to add a kernel to the AUR. Regards, Ralf -- PS: "linux-rt" is important to me [rocketmouse@archlinux ~]$ cd /boot/; ls vm* vmlinuz-linux vmlinuz-linux-rt vmlinuz-linux-rt-lts vmlinuz-linux-rt-presonus vmlinuz-linux-rt-rosaplüsch
----- Reply to message ----- Subject: Re: [arch-general] user namespaces Date: 2 February 2017 at 18:22:36 From: "Daniel Micay" <danielmicay@gmail.com> To: "General Discussion about Arch Linux" <arch-general@archlinux.org> :
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.
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?
I never said that... It simply doesn't make sense to base application sandboxes on user namespaces. That's all. Isolation can be exposed to unprivileged users without that insanity. Chromium has the best sandbox available for large applications like that, and it works fine without user namespaces. The tiny setuid binary barely adds attack surface vs. the enormous fully privileged attack surface of user namespaces. The chrome-sandbox binary can be contained by MAC too, if you use it.
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
Op 2 feb. 2017 16:06 schreef "Francisco Barbee via arch-general" < arch-general@archlinux.org>: 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? Everybody can have his/her hobbies of course. If you really want $feature, what's stopping you from compiling your own kernel? This is ArchLinux; those kind of things is actually made *easy* for it's users... Mvg, Guus Snijders
participants (5)
-
Daniel Micay
-
Francisco Barbee
-
Guus Snijders
-
Leonid Isaev
-
Ralf Mardorf