On Wed, Sep 14, 2022 at 12:44 PM Ted Toth <txtoth@xxxxxxxxx> wrote: > 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 :( Nope. I've been very busy lately. > > > 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? Yep. > If so could you give a little more detail > about how it would work? I believe I did in some previous post on this thread, another related one, or some off-list email. There has been a lot of mail on this issue ... Regardless, if I remember correctly I think I was talking about using the domain and port label to do a type transition to a new type when a socket was created as the result of accepting a new connection. It's pretty much the same 'type_transition ...' statement that you listed above (in the approach you gave up on). > 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. Oh, I thought you were concerned about the child sockets created by accepting new connections on a bound/listening socket. -- paul-moore.com
