Paul Moore <paul@xxxxxxxxxxxxxx> writes: > 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. I do not know what a good alternative is either. libsepol and libselinux are guaranteed to be available. libsemanage is not: root@OpenWrt:~# opkg list-installed | grep libse libselinux - 3.3-2 libsepol - 3.3-1 root@OpenWrt:~# -- gpg --locate-keys dominick.grift@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift
