I'm running MLS policy. The following commands were run on a RHEL 8
system without any policy modifications:
rpm -qa | grep selinux-policy
selinux-policy-3.14.3-80.el8_5.2.noarch
selinux-policy-mls-3.14.3-80.el8_5.2.noarch
selinux-policy-devel-3.14.3-80.el8_5.2.noarch
[root@dev tedx]# sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: mls
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: denied
Memory protection checking: actual (secure)
Max kernel policy version: 33
[root@dev tedx]# ps -efZ | grep systemd | grep init_t
system_u:system_r:init_t:s0-s15:c0.c1023 root 1 0 0 11:35 ?
00:00:02 /usr/lib/systemd/systemd --switched-root --system
--deserialize 18
[root@bbws-dev tedx]# sesearch -A -t init_t -s init_t -c tcp_socket
allow init_t init_t:tcp_socket { accept append bind connect create
getattr getopt ioctl listen lock read setattr setopt shutdown write };
allow init_t init_t:tcp_socket { accept append bind connect create
getattr getopt ioctl listen lock read setattr setopt shutdown write };
[ nis_enabled ]:True
allow init_t init_t:tcp_socket { append bind connect create getattr
getopt ioctl lock read setattr setopt shutdown write }; [
authlogin_nsswitch_use_ldap ]:True
allow init_t init_t:tcp_socket { append bind connect create getattr
getopt ioctl lock read setattr setopt shutdown write }; [
kerberos_enabled ]:True
On Wed, Aug 31, 2022 at 12:28 PM Dominick Grift
<dominick.grift@xxxxxxxxxxx> wrote:
>
> Ted Toth <txtoth@xxxxxxxxx> writes:
>
> >
> > On Wed, Aug 31, 2022 at 9:55 AM Christian Göttsche
> > <cgzones@xxxxxxxxxxxxxx> wrote:
> >>
> >> On Wed, 31 Aug 2022 at 02:47, Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> >> >
> >> > On Tue, Aug 30, 2022 at 6:04 PM Ted Toth <txtoth@xxxxxxxxx> wrote:
> >> > > On Mon, Aug 29, 2022 at 4:22 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> >> > > >
> >> > > > On Thu, Aug 25, 2022 at 9:22 AM Ted Toth <txtoth@xxxxxxxxx> wrote:
> >> > > > > I asked on the systemd-devel list about enabling systemd to set the
> >> > > > > context of a socket and got the answer I've included below. I don't
> >> > > > > know how a transition rule can be written to transition tcp sockets to
> >> > > > > multiple different target contexts, is this possible and if so how?
> >>
> >> What do you mean by "multiple different target contexts"?
> >
> > Basically what I meant was that you cannot do the following since the
> > source and target type are the same and there is no way to specify the
> > socket other than if it were a UDS (a socket file):
> > type_transition init_t init_t:tcp_socket app1_socket_t;
> > type_transition init_t init_t:tcp_socket app2_socket_t;
> >
> >
> >> How should they be different and how should systemd know?
> >>
> >> Socket unit configurations are normally paired with service unit
> >> configurations (e.g. dovecot.socket <-> dovecot.service).
> >> To handle incoming traffic the service unit configuration should
> >> contain an ExecStart= directive, to start a program to handle the
> >> data.
> >> By default systemd tries at socket creation to predict the context of
> >> the started program (via security_compute_create_raw(3) in
> >> src/shared/selinux-util.c:mac_selinux_get_create_label_from_exe()),
> >> see src/core/socket.c:socket_determine_selinux_label().
> >>
> >> For example if the service unit contains ExecStart=/usr/bin/myapp and
> >> /usr/bin/myapp has the context myapp_exec_t and the policy contains
> >> `type_transition init_t myapp_exec_t:process myapp_t` systemd should
> >> assign the context myapp_t to the socket specified in the socket unit
> >> configuration.
> >
> > I'll look at the code you reference but my experience is that the
> > socket systemd is listening on is labeled init_t despite, as in your
> > example above, the executable being labeled properly and transitioning
> > to the type that I've specified, in the type_transition rule in the
> > apps policy module, when it is run by systemd.
>
> I am confident that, if were talking about socket activation, this is
> not the case. systemd will create, and listen on the socket with the context of the
> domain that will "accept" the connection.
>
> for example i have a mpd instance that is socket activated:
>
> root@brutus:~# ss -antlpZ | grep 6600
> LISTEN 0 5 *:6600 *:*
> users:(("systemd",pid=968,proc_ctx=wheel.id:wheel.role:user.systemd.subj:s0,fd=33))
>
> systemd is listening on behalf of mpd.
>
> if i query the policy:
>
> root@brutus:~# sesearch -A -s user.systemd.subj -t user.systemd.subj -c
> tcp_socket
>
> ... nothing returns. systemd is not allowed to create tcp_socket with
> its own domain type or listen on them. Yes it is still listening on
> tcp:6600
>
> this is because:
>
> root@brutus:~# sesearch -A -s user.systemd.subj -t user.mpd.subj -c tcp_socket
> allow user.systemd.subj user.systemd.socketactivated.tcp.typeattr:tcp_socket { append bind connect create getattr getopt ioctl listen read setattr setopt shutdown write };
>
> this systemd created a tcp_socket with type user.mpd.subj (on behalf of
> mpd) and listens for connections on that tcp_socket. Once a connection
> comes in then mpd with accept it (not that user.systemd.subj is not
> allowed to accept tcp_socket on behalf of mpd (or any tcp_socket for
> that matter:
>
> root@brutus:~# sesearch -A -s user.systemd.subj -t user.mpd.subj -c
> tcp_socket -p accept
>
> ... nothing returned.
>
> >
> >>
> >> > > >
> >> > > > Ignoring setsockcreatecon(3) as that really isn't an option here,
> >> > >
> >> > > If we determine that policy can't be written to accomplish the
> >> > > transition then maybe systemd will reconsider not wanting to set the
> >> > > socket context using a .socket file option.
> >> >
> >> > I think the challenge is going to be having enough information when
> >> > the socket is created to do any useful type transition. I'm open to
> >> > suggestions, but I'm skeptical there is anything we can do beyond the
> >> > current approach.
> >> >
> >> > > > sockets created via socket(2) do check to see if there is a type
> >> > > > transition defined in the policy. In the case of a TCP socket the
> >> > > > type transition would look something like this:
> >> > > >
> >> > > > type_transition <domain> <domain>:tcp_socket <new_socket_type>
> >> > > >
> >> > > > ... so you can see there is not much one can select on other than the
> >> > > > socket's object class. The reason is that the socket(2) call itself
> >> > > > is rather spartan, with not even any clue as to if this is a client or
> >> > > > server socket in the case of TCP.
> >> > >
> >> > > Having written many policy modules, some of which use the
> >> > > type_transition statement for tcp_socket objects, I do not see how it
> >> > > can be used to transition sockets created by systemd. And under this
> >> > > circumstance I see that the selinux socket create hook would not be
> >> > > able query the policy database for the port context since the port is
> >> > > not known until the bind occurs but what about having the bind hook
> >> > > set the socket context if it finds a sid for the port?
> >> >
> >> > The problem with waiting until the connect()/bind() is that you are
> >> > effectively doing a relabel operation, which is a big no-no (but you
> >> > already know that). *Maybe* you could justify it in the special case
> >> > of stream sockets, as I'm pretty sure there is no way to do anything
> >> > useful with them as a data sink/source until they are either connected
> >> > to a remote peer or bound to a local port, however, we would all need
> >> > to think on that for a bit (it is still a relabel, and thus nasty) and
> >> > probably spend some time staring at the code to make sure there is no
> >> > way to do something sneaky with an unconnected or unbound stream
> >> > socket.
> >> >
> >> > > > Taking a step back, what are you trying to do? Perhaps there is
> >> > > > another approach that would get you where you want to go.
> >> > >
> >> > > I want to create socket activation services using systemd and to have
> >> > > the type of the socket being listened on be one that I've defined so
> >> > > that I can write policy to control which source types can connect to
> >> > > it.
> >> >
> >> > --
> >> > paul-moore.com
>
> --
> gpg --locate-keys dominick.grift@xxxxxxxxxxx
> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
> Dominick Grift
