Just rebooted into 3.16 [testing] and couldn't find root device by UUID. Can still boot into testing lts kernel without issue. This is my first foray into [testing], so I'm unsure if there are expectations about what else I should report? -rb On Mon, Aug 4, 2014 at 12:43 AM, Dimitris Zervas wrote:

Also, I can't build nvidia module with dkms. I compile the kernel from git.

On 13 August 2014 17:26, Damjan Georgievski wrote:

yey thanks for CONFIG_USER_NS=y

ahh no, I'm stupid. Checked it on another machine and got excited before hand :/ anyway. is there a reason this is not enabled now? all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7, Ubuntu and Debian (at least on the backported kernel) -- damjan

Hi, On Wed, Aug 13, 2014 at 06:44:39PM +0200, Thomas Bächler wrote:

Am 13.08.2014 um 17:29 schrieb Damjan Georgievski:

...

On 13 August 2014 17:26, Damjan Georgievski wrote:

...

yey thanks for CONFIG_USER_NS=y

ahh no, I'm stupid. Checked it on another machine and got excited before hand :/

anyway. is there a reason this is not enabled now? all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7, Ubuntu and Debian (at least on the backported kernel)

I'd think about it, if the feature wasn't entirely useless. Despite the lack of official documentation, I found a document that described how it worked. After reading that document I concluded that the feature is a huge potential security risk with no actual benefit.

Interestinig. Could you please provide a link?

If you give me a valid use case for USER_NS, I might reconsider, but every use case I can imagine is crushed by the limitations of the implementation.

As you know, user_ns is a necesary prerequisite for unpriviileged containers: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ . AFAIU, currently only Ubuntu 14.04 supports those. However, I agree with you that CONFIG_USER_NS is better left disabled in -ARCH kernels. After all, people using containers should be able to compile a custom kernel... Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On Wed, Aug 13, 2014 at 08:21:32PM +0300, Mihamina Rakotomandimby wrote:

Easing the work by defaulting to a ready-to-work kernel would be nice.

I think that LXC is used by minority of users (myself included). So, enabling USER_NS by default would put the rest of (unsuspecting) users in unnecessary danger. OTOH, configuring an LXC container already requires some understanding. Compared to that, building a custom kernel is really not a major barrier. Of course, the user namespace stuff will never become 'stable' if nobody uses it... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

...

anyway. is there a reason this is not enabled now? all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7, Ubuntu and Debian (at least on the backported kernel)

I'd think about it, if the feature wasn't entirely useless. Despite the lack of official documentation, I found a document that described how it worked. After reading that document I concluded that the feature is a huge potential security risk with no actual benefit.

What security risk exactly? There was one that I know of, and it was fixed.

If you give me a valid use case for USER_NS, I might reconsider, but every use case I can imagine is crushed by the limitations of the implementation.

The use case is that you don't need root access to start a container. I can run Firefox with a limited view to the filesystem for example, as a normal user. Or limited view to the network, for ex. just ipv4, just ipv6, just vpn. -- damjan

On 13/08/14 01:40 PM, Damjan Georgievski wrote:

...

...

anyway. is there a reason this is not enabled now? all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7, Ubuntu and Debian (at least on the backported kernel)

I'd think about it, if the feature wasn't entirely useless. Despite the lack of official documentation, I found a document that described how it worked. After reading that document I concluded that the feature is a huge potential security risk with no actual benefit.

What security risk exactly? There was one that I know of, and it was fixed.

A dozen local root exploits based on unprivileged user namespaces have been disclosed. Fedora and grsecurity patch in a check to prevent unprivileged use of user namespaces. You can find many with a search like 'CVE user namespace linux'. The latest vulnerability is only a day old...

...

If you give me a valid use case for USER_NS, I might reconsider, but every use case I can imagine is crushed by the limitations of the implementation.

The use case is that you don't need root access to start a container. I can run Firefox with a limited view to the filesystem for example, as a normal user. Or limited view to the network, for ex. just ipv4, just ipv6, just vpn.

It's not possible to sandbox an X11 application externally, so Firefox isn't a good example. The ability to see the contents of every window, draw arbitrary stuff in the windows, capture every input event without focus, etc. completely breaks it. The AppArmor profiles in distributions like Ubuntu for graphical applications are security theater. There's a reason for the Chromium renderer sandbox proxying all rendering requests over a pipe. Even an OpenGL context is too much before dri3, and it's only *theoretically* possible for dri3 drivers to be secure in that context.

On 13/08/14 12:44 PM, Thomas Bächler wrote:

Am 13.08.2014 um 17:29 schrieb Damjan Georgievski:

...

On 13 August 2014 17:26, Damjan Georgievski wrote:

...

yey thanks for CONFIG_USER_NS=y

ahh no, I'm stupid. Checked it on another machine and got excited before hand :/

anyway. is there a reason this is not enabled now? all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7, Ubuntu and Debian (at least on the backported kernel)

I'd think about it, if the feature wasn't entirely useless. Despite the lack of official documentation, I found a document that described how it worked. After reading that document I concluded that the feature is a huge potential security risk with no actual benefit.

If you give me a valid use case for USER_NS, I might reconsider, but every use case I can imagine is crushed by the limitations of the implementation.

The use case is primarily allowing unprivileged containers, by making it possible to unshare namespaces, enter a chroot and do some mount operations as a regular user. The systemd user session provides the other half of the picture, which is using control groups as an unprivileged user. The secondary purpose is the quirky uid / gid mapping but I don't really understand the intended use case. It seems way too obscure to ever have it exposed in container implementations and you would need root to do anything interesting with it. It's completely broken from a security POV so enabling it without reverting the patch allowing unprivileged user namespaces isn't sane. The latest vulnerability was disclosed only yesterday: http://www.openwall.com/lists/oss-security/2014/08/12/6 The key patch for Fedora's kernel: http://pkgs.fedoraproject.org/cgit/kernel.git/tree/Revert-userns-Allow-unpri... The same -EPERM return for unprivileged users is also a non-optional part of the grsecurity patch set. AFAICT, it also prevents the class of mounts used in the latest CVE. I might just be misunderstanding how user namespaces are supposed to work.

On Aug 13, 2014 5:53 PM, "Alex Belanger" wrote:

On Aug 4, 2014 3:40 AM, "Tobias Powalowski" < tobias.powalowski@googlemail.com> wrote:

...

Hi, just released 3.16 kernel to [testing] repository. Only r8168 binary module did not build. Please take a look at it.

greetings tpowa

-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org