Re: [PATCH 1/3] Security: Add prctl(PR_{GET,SET}_NETWORK)

Michael Stone [off-list ref] writes:

quoted

Eric Biederman writes:

quoted

Alan Cox [off-list ref] writes:

quoted

Michael Stone writes:

quoted

the LSM-based version *does not* resolve the situation to my satisfaction as a
userland hacker due to the well-known and long-standing adoption and
compositionality problems facing small LSMs. ;)

For things like Fedora it's probably an "interesting idea, perhaps we
should do it using SELinux" sort of problem, but a config option for a
magic network prctl is also going to be hard to adopt without producing a
good use case - and avoiding that by dumping crap into everyones kernel
fast paths isn't a good idea either.

If I understand the problem the goal is to disable access to ipc
mechanism that don't have the usual unix permissions.  To get
something that is usable for non-root processes, and to get something
that is widely deployed so you don't have to jump through hoops in
end user applications to use it.

Eric,

You understand correctly. Thank you for this cogent restatement.

quoted

We have widely deployed mechanisms that are what you want or nearly
what you want already in the form of the various namespaces built for
containers.

It's true that your work is closer to what I want than anything else that I've
seen so far...

quoted

I propose you introduce a permanent disable of executing suid applications. 

I'm open to the idea but I don't understand the need that motivates it yet.
Could you please explain further? (or point me to an existing explanation?)

With namespaces it is possible to masquarade as a trusted source,
of information to a suid program such as /etc/passwd or a NIS server.

A one-way removal of the ability to exec suid programs is generally
simple and handy like chroot, and removes the need for CAP_SYS_ADMIN
in most cases.

Plan 9 did not support suid executables and supported an unprivileged
equivalent of unshare(NEWNS).

I need the full unprivileged unshare of USERNS for my primary
uses today as I need to perform normally root only activities
like mounting loopback devices, and setting up networking. Your
uses of limiting of ipc do not appear to require that.

quoted

After which point it is another trivial patch to allow unsharing of
the network namespace if executing suid applications are disabled.

How do you propose to address the problem with the Unix sockets?

Careful code review of the patch to allow talking between network
namespaces with unix domain sockets.  This is a feature that we
simply have not merged yet.  Semantically it is fine today. It is
simply no one has answered the question what other implications
could there be.  Now that I know of 2 or 3 compelling use
cases and most of the rest of the work done.  It seems time to
relax the restriction.

Eric