[systemd-devel] [PATCH] socket: introduce SELinuxLabeledNet option

[Michal Sekletar]

On Wed, Aug 20, 2014 at 03:29:37PM +0200, Lennart Poettering wrote:
> On Wed, 20.08.14 12:01, Michal Sekletar (msekleta at redhat.com) wrote:
> 
> > > > +                        if (context->selinux_labeled_net && use_selinux()) {
> > > > +                                _cleanup_free_ char *label = NULL;
> > > > +
> > > > +                                err = label_get_socket_label(socket_fd, command->path, &label);
> > > > +                                if (err < 0) {
> > > > +                                        r = EXIT_SELINUX_CONTEXT;
> > > > +                                        goto fail_child;
> > > > +                                }
> > > > +
> > > > +                                err = setexeccon(label);
> > > > +                                if (err < 0) {
> > > > +                                        r = EXIT_SELINUX_CONTEXT;
> > > > +                                        goto fail_child;
> > > > +                                }
> > > > +                        }
> > > 
> > > If both SELinuxContext= and SELinuxLabeledNet= are set we should
> > > probably not execute one after the other, but only one of them.
> > 
> > I think that it makes sense to set both and resulting label will be combination
> > of both. Note that from SELinux label we acquire from network we are using only
> > security level part.
> 
> Hmm? But in both cases we just execute setexeccon()? Are you saying that
> if we invoke setexeccon() twice with a specific combination of
> parameters then it leads to different results than just doing the second
> invocation and leaving the first one out?

Sorry, I've phrased what I meant poorly. If both are set we will call setexeccon()
to set whatever user has given us via SELinuxContext and then we will figure out
resulting context from context which we set already and from information
provided by connected peer. If no context is explicitly required by user then we
will figure out resulting context from target binary and from information
acquired from network. In v2 of the patch docs will explain how combination of
two options work in greater detail.

> 
> The documentation doesn't mention that. 
> 
> Obviously, I have no understanding of SELinux as it appears, but this
> sounds so werid to me.
> 
> Dan, what's the story here?
> 
> 
> > > > +#ifdef HAVE_SELINUX
> > > > +                        if (!know_label && s->selinux_labeled_net) {
> > > > +                                r = getcon(&label);
> > > > +                                if (r < 0)
> > > > +                                        return r;
> > > > +                                know_label = true;
> > > > +                        }
> > > > +#endif
> > > >                          if (!know_label) {
> > > >  
> > > 
> > > Can you explain this bit? Why would we label the listening socket with our own
> > > label here?
> > 
> > This is because of MLS SELinux policy implementation details. If we relabel to
> > the context acquired from the target binary then it if not possible to connect to
> > the socket because SELinux denies a packet receive on the socket.
> > 
> > https://github.com/selinux-policy/selinux-policy/blob/rawhide-base/policy/mls#L361
> 
> I don't understand a word of this, I mus say. 
> 
> But is it really the intention here to take the current process label
> and apply it directly to the socket fd?
> 
> Lennart
> 
> -- 
> Lennart Poettering, Red Hat