Ondrej Mosnacek <omosnace@xxxxxxxxxx> writes:
> On Thu, Sep 8, 2022 at 4:15 PM Ted Toth <txtoth@xxxxxxxxx> wrote:
>>
>> On Thu, Sep 8, 2022 at 8:43 AM Ted Toth <txtoth@xxxxxxxxx> wrote:
>> >
>> > On Wed, Sep 7, 2022 at 5:48 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>> > >
>> > > On Wed, Sep 7, 2022 at 4:56 PM Dominick Grift
>> > > <dominick.grift@xxxxxxxxxxx> wrote:
>> > > > Ted Toth <txtoth@xxxxxxxxx> 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@xxxxxxxxxxx
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
Dominick Grift
