context of socket passed between processes

context of socket passed between processes

[Ted Toth]

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. 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?

Ted

Re: context of socket passed between processes

[Dominick Grift]

Ted Toth <txtoth@gmail.com> writes:

> 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. 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?

It is probably the context of the process listening on the port and not
the context of the socket that binds to the port

also i doubt you can rely on the presence of (lib)semanage (think small
embedded devices with monolithic policy)

>
> Ted

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

Re: context of socket passed between processes

[Paul Moore]

On Wed, Sep 7, 2022 at 4:56 PM Dominick Grift
<dominick.grift@defensec.nl> wrote:
> Ted Toth <txtoth@gmail.com> writes:
> > 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. 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?
>
> It is probably the context of the process listening on the port and not
> the context of the socket that binds to the port

That's a good point, I would have thought it would have looked at the
socket itself but perhaps it is the calling process' label.  Actually,
it might be the fd's label associated with the socket; that would
explain it.  Someone would need to look at the netstat sources to
confirm.

-- 
paul-moore.com

Re: context of socket passed between processes

[Ted Toth]

On Wed, Sep 7, 2022 at 5:48 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Wed, Sep 7, 2022 at 4:56 PM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
> > Ted Toth <txtoth@gmail.com> writes:
> > > 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. 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?
> >
> > It is probably the context of the process listening on the port and not
> > the context of the socket that binds to the port
>
> That's a good point, I would have thought it would have looked at the
> socket itself but perhaps it is the calling process' label.  Actually,
> it might be the fd's label associated with the socket; that would
> explain it.  Someone would need to look at the netstat sources to
> confirm.

Is there an API to query the context of a socket fd?

>
> --
> paul-moore.com

Re: context of socket passed between processes

[Ted Toth]

On Thu, Sep 8, 2022 at 8:43 AM Ted Toth <txtoth@gmail.com> wrote:
>
> On Wed, Sep 7, 2022 at 5:48 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Wed, Sep 7, 2022 at 4:56 PM Dominick Grift
> > <dominick.grift@defensec.nl> wrote:
> > > Ted Toth <txtoth@gmail.com> writes:
> > > > 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. 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?
> > >
> > > It is probably the context of the process listening on the port and not
> > > the context of the socket that binds to the port
> >
> > That's a good point, I would have thought it would have looked at the
> > socket itself but perhaps it is the calling process' label.  Actually,
> > it might be the fd's label associated with the socket; that would
> > explain it.  Someone would need to look at the netstat sources to
> > confirm.
>
> Is there an API to query the context of a socket fd?

I wrote a client which connects and calls getpeercon and indeed the
context is what was set via setsockcreatecon so that's reassuring.
Unfortunately it seems that netstat, ss and lsof don't have a way to
query the context of the listening socket :( I'd like to see a
getsockcon function (taking an fd as its argument) added to libselinux
if it can be written.

>
> >
> > --
> > paul-moore.com

Re: context of socket passed between processes

[Ondrej Mosnacek]

On Thu, Sep 8, 2022 at 4:15 PM Ted Toth <txtoth@gmail.com> wrote:
>
> On Thu, Sep 8, 2022 at 8:43 AM Ted Toth <txtoth@gmail.com> wrote:
> >
> > On Wed, Sep 7, 2022 at 5:48 PM Paul Moore <paul@paul-moore.com> wrote:
> > >
> > > On Wed, Sep 7, 2022 at 4:56 PM Dominick Grift
> > > <dominick.grift@defensec.nl> wrote:
> > > > Ted Toth <txtoth@gmail.com> writes:
> > > > > 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. 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?
> > > >
> > > > It is probably the context of the process listening on the port and not
> > > > the context of the socket that binds to the port
> > >
> > > That's a good point, I would have thought it would have looked at the
> > > socket itself but perhaps it is the calling process' label.  Actually,
> > > it might be the fd's label associated with the socket; that would
> > > explain it.  Someone would need to look at the netstat sources to
> > > confirm.
> >
> > Is there an API to query the context of a socket fd?
>
> I wrote a client which connects and calls getpeercon and indeed the
> context is what was set via setsockcreatecon so that's reassuring.
> Unfortunately it seems that netstat, ss and lsof don't have a way to
> query the context of the listening socket :( I'd like to see a
> getsockcon function (taking an fd as its argument) added to libselinux
> if it can be written.

There is a way to see a socket's context, though it's a bit obscure:

ls -ZL /proc/<PID>/fd/<FD>

-- 
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.

Re: context of socket passed between processes

[Dominick Grift]

Ondrej Mosnacek <omosnace@redhat.com> writes:

> On Thu, Sep 8, 2022 at 4:15 PM Ted Toth <txtoth@gmail.com> wrote:
>>
>> On Thu, Sep 8, 2022 at 8:43 AM Ted Toth <txtoth@gmail.com> wrote:
>> >
>> > On Wed, Sep 7, 2022 at 5:48 PM Paul Moore <paul@paul-moore.com> wrote:
>> > >
>> > > On Wed, Sep 7, 2022 at 4:56 PM Dominick Grift
>> > > <dominick.grift@defensec.nl> wrote:
>> > > > Ted Toth <txtoth@gmail.com> writes:
>> > > > > 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. 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?
>> > > >
>> > > > It is probably the context of the process listening on the port and not
>> > > > the context of the socket that binds to the port
>> > >
>> > > That's a good point, I would have thought it would have looked at the
>> > > socket itself but perhaps it is the calling process' label.  Actually,
>> > > it might be the fd's label associated with the socket; that would
>> > > explain it.  Someone would need to look at the netstat sources to
>> > > confirm.
>> >
>> > Is there an API to query the context of a socket fd?
>>
>> I wrote a client which connects and calls getpeercon and indeed the
>> context is what was set via setsockcreatecon so that's reassuring.
>> Unfortunately it seems that netstat, ss and lsof don't have a way to
>> query the context of the listening socket :( I'd like to see a
>> getsockcon function (taking an fd as its argument) added to libselinux
>> if it can be written.
>
> There is a way to see a socket's context, though it's a bit obscure:
>
> ls -ZL /proc/<PID>/fd/<FD>

Nice, that is one way to confirm at least that systemd socket activation does the
right thing:

root@brutus:~# ss -antlZ | grep 6600
LISTEN 0      5                  *:6600            *:*    users:(("systemd",pid=968,proc_ctx=wheel.id:wheel.role:user.systemd.subj:s0,fd=28))       
root@brutus:~# ls -ZL /proc/968/fd/28
wheel.id:wheel.role:user.mpd.subj:s0 /proc/968/fd/28
root@brutus:~#

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

Re: context of socket passed between processes

[Ted Toth]

On Thu, Sep 8, 2022 at 9:28 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Thu, Sep 8, 2022 at 4:15 PM Ted Toth <txtoth@gmail.com> wrote:
> >
> > On Thu, Sep 8, 2022 at 8:43 AM Ted Toth <txtoth@gmail.com> wrote:
> > >
> > > On Wed, Sep 7, 2022 at 5:48 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > On Wed, Sep 7, 2022 at 4:56 PM Dominick Grift
> > > > <dominick.grift@defensec.nl> wrote:
> > > > > Ted Toth <txtoth@gmail.com> writes:
> > > > > > 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. 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?
> > > > >
> > > > > It is probably the context of the process listening on the port and not
> > > > > the context of the socket that binds to the port
> > > >
> > > > That's a good point, I would have thought it would have looked at the
> > > > socket itself but perhaps it is the calling process' label.  Actually,
> > > > it might be the fd's label associated with the socket; that would
> > > > explain it.  Someone would need to look at the netstat sources to
> > > > confirm.
> > >
> > > Is there an API to query the context of a socket fd?
> >
> > I wrote a client which connects and calls getpeercon and indeed the
> > context is what was set via setsockcreatecon so that's reassuring.
> > Unfortunately it seems that netstat, ss and lsof don't have a way to
> > query the context of the listening socket :( I'd like to see a
> > getsockcon function (taking an fd as its argument) added to libselinux
> > if it can be written.
>
> There is a way to see a socket's context, though it's a bit obscure:
>
> ls -ZL /proc/<PID>/fd/<FD>

Yes I did that too but it does not show the context set in the
setsockcreatecon call, only the client getpeercon returned the context
set on create.


>
> --
> Ondrej Mosnacek
> Senior Software Engineer, Linux Security - SELinux kernel
> Red Hat, Inc.
>

Re: context of socket passed between processes

[Paul Moore]

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.

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

-- 
paul-moore.com

Re: context of socket passed between processes

[Ted Toth]

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?

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

Regarding how to get the port context, what would you suggest?
Currently I'm calling semanage functions but have considered using the
sepol instead.

>
> --
> paul-moore.com

Re: context of socket passed between processes

[Paul Moore]

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.

-- 
paul-moore.com

Re: context of socket passed between processes

[Dominick Grift]

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

Re: context of socket passed between processes

[Ted Toth]

On Thu, Sep 8, 2022 at 9:42 AM Paul Moore <paul@paul-moore.com> wrote:
>
> 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.

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

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.

>
> * 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.
>
> --
> paul-moore.com

Re: context of socket passed between processes

[Ted Toth]

I talk to Karl MacMillian offline and he too is of the opinion that
the socket should be created with the target applications context. I'm
going to submit a feature request to systemd for the removal of the
special case of using systemds context when the SELinuxContextFromNet
option is set in .socket file. Thanks everyone for your input.

Ted

On Mon, Sep 12, 2022 at 8:11 AM Ted Toth <txtoth@gmail.com> wrote:
>
> On Thu, Sep 8, 2022 at 9:42 AM Paul Moore <paul@paul-moore.com> wrote:
> >
> > 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.
>
> 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 ...
>
> 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.
>
> >
> > * 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.
> >
> > --
> > paul-moore.com

Re: context of socket passed between processes

[Paul Moore]

On Mon, Sep 12, 2022 at 9:11 AM Ted Toth <txtoth@gmail.com> wrote:
> On Thu, Sep 8, 2022 at 9:42 AM Paul Moore <paul@paul-moore.com> wrote:
> > 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.
>
> 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

Re: context of socket passed between processes

[Ted Toth]

On Wed, Sep 14, 2022 at 9:03 AM Paul Moore <paul@paul-moore.com> wrote:
>
> On Mon, Sep 12, 2022 at 9:11 AM Ted Toth <txtoth@gmail.com> wrote:
> > On Thu, Sep 8, 2022 at 9:42 AM Paul Moore <paul@paul-moore.com> wrote:
> > > 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.
> >
> > 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

Re: context of socket passed between processes

[Paul Moore]

On Wed, Sep 14, 2022 at 12:44 PM Ted Toth <txtoth@gmail.com> wrote:
> On Wed, Sep 14, 2022 at 9:03 AM Paul Moore <paul@paul-moore.com> wrote:
> > On Mon, Sep 12, 2022 at 9:11 AM Ted Toth <txtoth@gmail.com> wrote:
> > > On Thu, Sep 8, 2022 at 9:42 AM Paul Moore <paul@paul-moore.com> wrote:
> > > > 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.
> > >
> > > 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