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
