I talk to Karl MacMillian offline and he too is of the opinion that the socket should be created with the target applications context. I'm going to submit a feature request to systemd for the removal of the special case of using systemds context when the SELinuxContextFromNet option is set in .socket file. Thanks everyone for your input. Ted On Mon, Sep 12, 2022 at 8:11 AM Ted Toth <txtoth@xxxxxxxxx> wrote: > > On Thu, Sep 8, 2022 at 9:42 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > 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. > > I was thinking I'd create an app type, port type, socket > type and a type transition: > type a_t; > type a_port_t; > type a_sock_t > type_transition init_t a_port_t:tcp_socket a_socket_t; > > I'd use semanage or cil to set the port type. > semanage port -a -p tcp -t a_port_t XXXX > or: > portcon ... > > Then when systemd is creating the socket for the activated service it > would lookup the port type in policy and call security_compute_create > passing in systemds context, the port context and tcp_socket class > which would return an a_socket_t context to be used in the > setsockcreatecon call. > > > > > * 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
