Allow chronyd_t to accept and make NTS-KE connections

[mlichvar]

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1872624

[zpytela]

@mlichvar, this permissions set seems to be broader than the one reported in the bz - do you have any scenario to trigger them or a test suite to cover the new functionality?

On the other hand, the reference the /run/chrony-dhcp directory has not been addressed yet. Which process creates the directory?

[mlichvar]

I think the AVCs in the RH bug didn't cover a client connecting to the server. There is an NTS test in the upstream test suite, but it doesn't use the system service and selinux labels, so that won't help much.

Here is a trimmed down version doing that:
https://gist.github.com/mlichvar/e6b183daa16599d7985dc81fdde7af39

As for the /run/chrony-dhcp directory, it's created by the same process that created /run/chrony-helper, that is the NetworkManager dispatcher or dhclient.

[mlichvar]

BTW, I'm not sure if all those rules are really needed. I just used the same rules as some other services that implement a TCP server and client on a labelled port.

[zpytela]

I think the AVCs in the RH bug didn't cover a client connecting to the server. There is an NTS test in the upstream test suite, but it doesn't use the system service and selinux labels, so that won't help much.

Here is a trimmed down version doing that:
https://gist.github.com/mlichvar/e6b183daa16599d7985dc81fdde7af39

Interesting. The script in selinux permissive triggers just the permissions as in the bz:

allow chronyd_t self:tcp_socket listen;
allow chronyd_t unreserved_port_t:tcp_socket { name_bind name_connect };

For the other permissions, it usually is the maintainer who is able to assess which permissions are actually needed. This is how one of the additional interfaces calls expands:

  $ macro-expander ' corenet_tcp_sendrecv_generic_if(chronyd_t)'
allow chronyd_t netif_t:netif { tcp_send tcp_recv egress ingress };

If you are unable to answer it right away, can we proceed and allow only those permission which popped up in some use case?

I also haven't noticed any /run files interactions, even after having it running for some time or restarted. Does it need more time?

As for the /run/chrony-dhcp directory, it's created by the same process that created /run/chrony-helper, that is the NetworkManager dispatcher or dhclient.

Supposing you mean /usr/lib/NetworkManager/dispatcher.d/11-dhclient.
This /run/chrony-dhcp/IF.sources file is managed by nm, but read by chronyd? So it is the directory?

Note in another bz#1880948 we can see initrc_var_run_t for the same file.

[mlichvar]

Interesting. The script in selinux permissive triggers just the permissions as in the bz:

allow chronyd_t self:tcp_socket listen;
allow chronyd_t unreserved_port_t:tcp_socket { name_bind name_connect };

Do you have the latest chrony package (chrony-4.0-0.9.pre4.fc33) installed? It should be using the ntske port. I'm getting also an AVC for the accept syscall, not just listen.

For the other permissions, it usually is the maintainer who is able to assess which permissions are actually needed. This is how one of the additional interfaces calls expands:

  $ macro-expander ' corenet_tcp_sendrecv_generic_if(chronyd_t)'
allow chronyd_t netif_t:netif { tcp_send tcp_recv egress ingress };

I'm not sure what exactly is tcp_send or tcp_recv. If it's supposed to be the send/recv syscall on a TCP socket, then yes, chronyd does that. Maybe they would show only on the labelled port?

I also haven't noticed any /run files interactions, even after having it running for some time or restarted. Does it need more time?

No, it just needs your DHCP server to provide clients with an NTP server. If you run dnsmasq as the DHCP server, you can specify the NTP server with dhcp-option=42,192.168.123.123.

Supposing you mean /usr/lib/NetworkManager/dispatcher.d/11-dhclient.
This /run/chrony-dhcp/IF.sources file is managed by nm, but read by chronyd? So it is the directory?

Yes, it is a directory created by /etc/dhcp/dhclient.d/chrony.sh or /usr/lib/NetworkManager/dispatcher.d/20-chrony-dhcp and those scripts also create the files there, which are then read by chronyd.

Note in another bz#1880948 we can see initrc_var_run_t for the same file.

Maybe that's when using networking scripts (dhclient) instead of NetworkManager?

[mlichvar]

I've removed some of the rules as suggested.

[zpytela]

Interesting. The script in selinux permissive triggers just the permissions as in the bz:

allow chronyd_t self:tcp_socket listen;
allow chronyd_t unreserved_port_t:tcp_socket { name_bind name_connect };

Do you have the latest chrony package (chrony-4.0-0.9.pre4.fc33) installed? It should be using the ntske port. I'm getting also an AVC for the accept syscall, not just listen.
Actually these results:
chrony-4.0-0.9.pre4.fc34.x86_64: listen
chrony-4.0-0.9.pre4.fc33.x86_64: accept listen
make no sense to me.
The ntske port has not made it to Fedora, hence unreserved.

For the other permissions, it usually is the maintainer who is able to assess which permissions are actually needed. This is how one of the additional interfaces calls expands:

  $ macro-expander ' corenet_tcp_sendrecv_generic_if(chronyd_t)'
allow chronyd_t netif_t:netif { tcp_send tcp_recv egress ingress };

I'm not sure what exactly is tcp_send or tcp_recv. If it's supposed to be the send/recv syscall on a TCP socket, then yes, chronyd does that. Maybe they would show only on the labelled port?
The permission names usually match syscall names, but there are also classes where it is hard to find out.

I also haven't noticed any /run files interactions, even after having it running for some time or restarted. Does it need more time?

No, it just needs your DHCP server to provide clients with an NTP server. If you run dnsmasq as the DHCP server, you can specify the NTP server with dhcp-option=42,192.168.123.123.

Supposing you mean /usr/lib/NetworkManager/dispatcher.d/11-dhclient.
This /run/chrony-dhcp/IF.sources file is managed by nm, but read by chronyd? So it is the directory?

Yes, it is a directory created by /etc/dhcp/dhclient.d/chrony.sh or /usr/lib/NetworkManager/dispatcher.d/20-chrony-dhcp and those scripts also create the files there, which are then read by chronyd.

Note in another bz#1880948 we can see initrc_var_run_t for the same file.

Maybe that's when using networking scripts (dhclient) instead of NetworkManager?
If there is no other comment, I'll merge this PR and check further the dealing with runtime files.

[mlichvar]

chrony-4.0-0.9.pre4.fc34.x86_64: listen
chrony-4.0-0.9.pre4.fc33.x86_64: accept listen
make no sense to me.

Hm, that's odd.

If there is no other comment, I'll merge this PR and check further the dealing with runtime files.

Ok. Thank you.

[zpytela]

Miroslav, thank you for your effort, merging and backporting to f33.