On Thu, Sep 8, 2022 at 9:41 AM Ted Toth <txtoth@xxxxxxxxx> wrote: > On Wed, Sep 7, 2022 at 5:46 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Wed, Sep 7, 2022 at 4:19 PM Ted Toth <txtoth@xxxxxxxxx> wrote: > > > > > > systemd uses a helper process (sd-listen) to create sockets and pass > > > their fds back to its parent. I've patched systemd to call semanage to > > > get the context for the port if it exists and create a context using > > > the returned type when calling setsockcreatecon. > > > > This obviously depends on how you structure and write your policy, but > > I don't think you want to use a port type directly as a socket type. > > I think we talked about this a little in the other thread, but for > > bound/listening sockets maybe you could do a transition for new child > > sockets based on the listening socket and port types. > > To be clear you are suggesting to call setsockcreatecon with the port > type but also have a transition rule to transition the port type to a > socket type? Two things: * I'm not sure you want to reuse a port type as a socket type, that seems wrong to me. * The socket type transition I was talking about would be new as there is not currently a type transition when the kernel creates a new socket for incoming connections. > > > Everything looks > > > right i.e. the port type is retrieved, the context is created and > > > setsockcreatecon is called without errors. However 'netstat -Z' shows > > > the listening sockets type as init_t and not the type in the > > > setsockcreatecon call, is this the expected behavior? Can anyone help > > > me understand why this is happening? > > > > You're calling setsockcreatecon() before you create the listening > > socket, right? I wouldn't expect this to work properly if you create > > the listening socket and then call setsockcreatecon() hoping to have > > the new label applied to the new child sockets. > > It's not my code ;) the systemd sd-listen process code does the > setsockccreatecon, bind and then listen. Well, regardless of who wrote the code, setsockcreatecon() is not going to have any effect on a socket's label if it is called *after* the socket is created. Additionally, setsockcreatecon() has no effect on child sockets created by incoming connections on a listening socket; if you want to affect the label of those child sockets today you would need to change the label of the listening parent socket. > Regarding how to get the port context, what would you suggest? > Currently I'm calling semanage functions but have considered using the > sepol instead. I'll leave that to the folks who better understand the SELinux libraries, my only comment would be that I'm not sure reusing the port label is a good idea here. -- paul-moore.com
