Re: context of socket passed between processes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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().

-- 
paul-moore.com



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux