[arch-general] linux 3.16 in [testing]
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
Also, I can't build nvidia module with dkms. I compile the kernel from git.
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 <dzervas@dzervas.gr> wrote:
Also, I can't build nvidia module with dkms. I compile the kernel from git.
yey thanks for CONFIG_USER_NS=y On 4 August 2014 09:38, 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
-- damjan
On 13 August 2014 17:26, Damjan Georgievski <gdamjan@gmail.com> 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
Am 13.08.2014 um 17:29 schrieb Damjan Georgievski:
On 13 August 2014 17:26, Damjan Georgievski <gdamjan@gmail.com> 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.
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 <gdamjan@gmail.com> 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 08/13/2014 08:09 PM, Leonid Isaev wrote:
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...
Hi all, One use case of using LXC might be to want to quicky have a virtual environment running. Easing the work by defaulting to a ready-to-work kernel would be nice. Regards.
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
On 13/08/14 01:21 PM, Mihamina Rakotomandimby wrote:
On 08/13/2014 08:09 PM, Leonid Isaev wrote:
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...
Hi all,
One use case of using LXC might be to want to quicky have a virtual environment running.
Easing the work by defaulting to a ready-to-work kernel would be nice.
Regards.
Containers work fine without CONFIG_USER_NS. You just can't spawn them without being a privileged user. There's a good reason for that, as shown by the endless stream of local root exploits via user namespaces. Having uid 0 or root equivalent capabilities in a container with or without user namespaces is equivalent to root access on the host due to flaws in the implementation. By removing the check for a privileged user, upstream just guaranteed that sane distributions are not going to enable the feature (at least without patching it, which isn't Arch's style).
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
Am 13.08.2014 um 19:40 schrieb Damjan Georgievski:
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.
I am thinking about the risks that are yet unknown.
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.
That's interesting - I was unable to get anything like this done. Maybe the LXC people are smarter than me after all.
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.
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.
has anybody tried Qubes? https://qubes-os.org/ it appears to be designed to address that problem: Qubes implements a Security by Isolation approach by providing the user with the ability to easily create many security domains. These domains are implemented as lightweight Virtual Machines (VMs) running under the Xen hypervisor. Qubes' main objective is to provide strong isolation between these domains, so that even if an attacker compromises one of the domains, the others are still safe. Qubes, however, does not attempt to provide any security isolation for applications running within the same domain. For example, a buggy web browser running in a Qubes domain could still be compromised just as easily as on a regular Linux distribution. The difference that Qubes makes is that now the attacker doesn't have access to all the software running in the other domains. Qubes also provides a number of mechanisms that make it easy and convenient for the user to run multiple domains, such as seamless GUI integration onto one common desktop, secure clipboard copy and paste between domains, secure file transfer between domains, disposable VMs, and much more. Qubes also provides an advanced networking infrastructure that allows for the creation of multiple network VMs (which isolate all the world-facing networking stacks) and proxy VMs which can be used for advanced VPN and tunnelling over untrusted connections.
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 <gdamjan@gmail.com> 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 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
On Aug 13, 2014 5:53 PM, "Alex Belanger" <i.caught.air@gmail.com> 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
participants (10)
-
Alex Belanger
-
Carl Schaefer
-
Damjan Georgievski
-
Daniel Micay
-
Dimitris Zervas
-
G. Richard Bellamy
-
Leonid Isaev
-
Mihamina Rakotomandimby
-
Thomas Bächler
-
Tobias Powalowski