Re: [RFC 04/10] netns, selinux: create the selinux netlink socket per network namespace

[Stephen Smalley <sds@tycho.nsa.gov>]

On Fri, 2017-10-06 at 12:07 +1100, James Morris wrote:
> On Mon, 2 Oct 2017, Stephen Smalley wrote:
> 
> > This change presumes that one will always unshare the network
> > namespace
> > when unsharing a new selinux namespace (the reverse is not
> > required).
> > Otherwise, the same inconsistencies could arise between the
> > notifications
> > and the relevant policy.  At present, nothing enforces this
> > guarantee
> > at the kernel level; it is left up to userspace (e.g. container
> > runtimes).
> > It is an open question as to whether this is a good idea or whether
> > unsharing of the selinux namespace should automatically unshare the
> > network
> > namespace.  
> 
> What about logging a kernel warning if just SELinux is unshared?

As with Serge's suggestion, the problem is that one can unshare them in
any order, and potentially with intervening steps to set up the
namespace or prepare for doing so, so there is no obvious point where
you could detect and issue such a warning.  Without an interface that
allows unsharing them both simultaneously (either unshare(2)-based or
selinuxfs-based), I don't think we can provide such a warning.

I don't think it will prove to be a problem in practice however;
container runtimes just need to do the right thing (and we can help
this by providing helpers in libselinux or the like).  The larger
concern is not that we'll forget to unshare the network namespace when
we unshare the selinux namespace, but that subsequent further unsharing
of the network namespace by itself could cause lossage of
notifications.  The two cases of concern are that a process unshares
its network namespace again (after the original unsharing of both
selinux namespace and network namespace for the container creation) and
subsequently:

1) Does not get any netlink notifications of setenforce or policy load
events for its selinux namespace. This is only an issue if a program
that uses the userspace AVC also unshares its network namespace or
otherwise is launched into its own network namespace separate from that
of its container.  And it isn't a regression, since before this change
notifications would only be sent to the init network namespace ever, so
this change actually represents an improvement in the ability to at
least get notifications when running in the container's network
namespace.

2) Sets enforcing mode or loads policy itself, in which case the
notification for its setenforce or load_policy will only go to its
network namespace and will not be received by other processes in the
same selinux namespace.  This is only an issue if a process running in
a separate network namespace from that of its container sets enforcing
mode or loads policy.  This seems unlikely to me, since such setting of
enforcing mode or loading of policy will conventionally be restricted
to a small set of privileged processes, such as the container init
process, administrator shells, and package installation/updates, and I
wouldn't expect them to run in a separate network namespace than their
container.

> 
> I think we want to avoid surprising the user by unsharing things for
> them, 
> and yes, it will be possible to mess your system up if you configure
> it 
> badly.
> 
> > However, keeping them separate is consistent with the handling
> > of the mount namespace currently, which also should be unshared so
> > that
> > a private selinuxfs mount can be created.
> 
> Right, and this will in practice always be automated and abstracted
> from 
> an end user pov.