[lkml]   [2012]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [REVIEW][PATCH 0/43] Completing the user namespace
    richard -rw- weinberger <> writes:

    > On Sun, Apr 8, 2012 at 7:10 AM, Eric W. Biederman <> wrote:
    >> - Capabilities are localized to the current user namespace making
    >>  it safe to give the initial user in a user namespace all capabilities.
    > So, this makes LXC and friends ready for hostile environments?
    > IOW a root user (with all capabilities) sitting in his own namespace can no
    > longer ham the host?

    The user namespace now restricts the root user in a container to being
    able to do no more harm than any other user can do. Additionally suid
    executables can no longer lead to having all power on the system. Which
    means that the only privilege escalation attacks available from a
    container require kernel bugs.

    With my version of user namespaces you no longer have to worry about the
    container root writing to files in /proc or /sys and changing the
    behavior of the system. Nor do you have to worry about messages passed
    across unix domain sockets to d-bus having a trusted uid and being
    allowed to do something nasty.

    It allows for applications with no capabilities to use multiple
    uids and to implement privilege separation.

    I certainly see user namespaces like this as having the potential
    to make linux systems more secure.

    You will have to make your own threat assessment to decide if that is
    enough of an improvement to start deploying containers in what you
    consider hostile environments.

    For me the big potential I see is that it makes possible the creation of
    a container without privilege (today the uid mapping setup still
    requires privilege), and it allows a lot of things that the existence of
    suid root executables has prevented us from making unprivileged before.

    After the core is settled we can start looking at patches to allow
    unprivileged creation of other namespaces. Unprivileged mounts.
    Unprivileged use of the networking stack. Bringing many of the
    improvements that linux has seen over the years to unprivileged

    I also see great potential for April fools day jokes. You log in and
    try to fix something and discover you are not the root you thought you
    were. Does that count as a hostile environment?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-04-08 23:29    [W:2.397 / U:0.288 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site