On Wed, Sep 14, 2022 at 9:03 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Mon, Sep 12, 2022 at 9: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 ... > > That seems reasonable. Maybe you didn't notice my last comment about giving up on this approach :( > > > 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. > > I guess you could do it that way, but I think the better way to do > this is via a normal type transition in the kernel when the accept()'d > child socket was created in the kernel. Not only does it not require > userspace changes, it avoids all the potential race issues one might > have with multi-threaded applications and setsockcreatecon(). Are you referring to the type transition that doesn't exist yet that you mentioned previously? If so could you give a little more detail about how it would work? Again my concern is primarily with the context of the listening socket as I need to be able to write policy to control the source types that can connect to it. > > -- > paul-moore.com
