Re: context of socket passed between processes

[Dominick Grift <dominick.grift@defensec.nl>]

Paul Moore <paul@paul-moore.com> writes:

> On Thu, Sep 8, 2022 at 9:41 AM Ted Toth <txtoth@gmail.com> wrote:
>> On Wed, Sep 7, 2022 at 5:46 PM Paul Moore <paul@paul-moore.com> wrote:
>> > On Wed, Sep 7, 2022 at 4:19 PM Ted Toth <txtoth@gmail.com> 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@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift