Re: [gentoo-dev] Integrating Portage with other package managers

[Rich Freeman]

On Thu, Mar 8, 2018 at 4:00 PM, R0b0t1 <r030t1@×××××.com> wrote:
> On Thu, Mar 8, 2018 at 11:50 AM, Rich Freeman <rich0@g.o> wrote:
>> If you have util-linux installed then try running (as any user - you
>> don't have to be root):
>> unshare -i -m -n -p -u -C -f --mount-proc -U -r  /bin/bash
>>
>
> Interesting. I hadn't found a good interface to containers and
> clone(2) besides Docker. Of course, I didn't look very hard. I half
> expect a "new" process model to develop around the kernel namespaces,
> as people realize GID separation only is too coarse.

Well, the original userspace tools are in app-emulation/lxc (I can see
how it ended up in this category, but obviously it doesn't fit).

Docker is the most popular one.

My personal favorite is systemd-nspawn.  That basically has almost
nothing to do with systemd per-se, but I have no idea if it can work
standalone.  It is a bit more minimal while still being fairly
functional.

unshare/nsenter are the util-linux commands that give relatively
direct access to the system calls themselves.  I used unshare to
illustrate that these really are just system calls and how you use
them is up to you.

>
> I still see some odd claims about container security, though: claiming
> containers are more secure than user accounts still seems odd to me,
> as if you don't trust the kernel to enforce user accounts, why trust
> it to enforce namespace separation?
>

I'm not sure I'd say that containers are more than user accounts
per-se, though with UID mapping it could be easier to avoid sharing
user/group IDs across different services that might otherwise share
them.

I'd say that the security of a container is a bit like the security of
running something in a chroot jail.  It is one additional level of
isolation that something needs to break out of.

Processes running as root inside a container (and I mean the real
root, not root in a user namespace like in my example - unless you ran
the command I gave while logged in as root) are not secure today as
far as I'm aware.  Sure, the isolation is such that a process isn't
going to accidentally escape from the container, so that is a form of
security.  However, a malicious process running as root inside a
container (or a chroot) is generally going to be able to escape if it
wants to.  Maybe some kernel hardening approaches would help with
that.

Also, a process running in a container has less info on the host,
especially if in a chroot (which is typically the case).  If you run a
shell as nobody you could probably glean quite a bit about what is
going on with the host, even if you can't directly touch most of it.
If you could run a process as nobody on many hosts maybe you could
identify which hosts you want to prioritize for further attacks.  If
they're doing the same thing on processes trapped in a
container+chroot then they're basically not going to know about any
other services on the host other than the one they've already hacked
into.

Stuff running as non-root inside a container should be very well
contained, barring kernel bugs.  As we saw a few months ago with
meltdown even running in a VM isn't a perfect guarantee of isolation.
But, I would agree that stuff running under a different UID is also
reasonably secure other than information leaks.

The main benefit of containers is isolation, IMO.  Stuff inside a
container just doesn't see anything outside, which means fewer
incompatibilities.  I run a bunch of nspawn containers mostly running
Gentoo (some with other distros inside), and the nice thing about it
is that when I update a container I know it only provides one service,
so I only have one service I need to test, vs doing a glibc update and
having to test everything.  On the other hand it is that many more
updates to do, and there is a bit more memory cost since libraries
aren't shared across them the way they would be if they all ran on the
host.

-- 
Rich