Bug 2246805 - ntpsec does not install a selinux policy that supports NTS
Summary: ntpsec does not install a selinux policy that supports NTS
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 38
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-10-29 03:59 UTC by jhamlin96
Modified: 2024-01-03 02:18 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-38.31-1.fc38
Clone Of:
Environment:
Last Closed: 2024-01-03 02:18:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description jhamlin96 2023-10-29 03:59:19 UTC
Hello,


I've been working with the upstream project and while doing some NTS testing, I had to generate and install a SELinux policy to allow ntp communications using NTS.


allow ntpd_t ntske_port_t:tcp_socket name_connect;

 

Reproducible: Always

Steps to Reproduce:
1. Install system with Selinux in "enforcing"
2. Install ntpsec RPM
3. Configure ntp.conf to use NTS-enabled server
4. Restart ntpd. 

Actual Results:  
4. Restart ntpd. View in log "Permission Denied" error

Expected Results:  
4. Restart ntpd. View successful ntp connection using NTS.

Comment 1 Miroslav Lichvar 2023-10-30 08:22:06 UTC
The policy is included in the selinux-policy package.

Comment 2 Milos Malik 2023-10-30 08:48:10 UTC
The following SELinux denial appeared in enforcing mode:
----
type=PROCTITLE msg=audit(10/30/2023 04:46:52.693:699) : proctitle=/usr/sbin/ntpd -g -N -u ntp:ntp 
type=SOCKADDR msg=audit(10/30/2023 04:46:52.693:699) : saddr={ saddr_fam=inet6 laddr=2001:67c:2550:d::7 lport=4460 } 
type=SYSCALL msg=audit(10/30/2023 04:46:52.693:699) : arch=x86_64 syscall=connect success=no exit=EACCES(Permission denied) a0=0x4 a1=0x7fdc94003570 a2=0x1c a3=0x4000 items=0 ppid=1 pid=4646 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd subj=system_u:system_r:ntpd_t:s0 key=(null) 
type=AVC msg=audit(10/30/2023 04:46:52.693:699) : avc:  denied  { name_connect } for  pid=4646 comm=ntpd dest=4460 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:object_r:ntske_port_t:s0 tclass=tcp_socket permissive=0 
----

# rpm -qa selinux\* ntp\* | sort
ntpsec-1.2.2a-1.fc39.x86_64
selinux-policy-40.4-1.fc40.noarch
selinux-policy-targeted-40.4-1.fc40.noarch
#

Comment 3 Milos Malik 2023-10-30 08:52:36 UTC
The following SELinux denial appeared in permissive mode:
----
type=PROCTITLE msg=audit(10/30/2023 04:48:27.329:704) : proctitle=/usr/sbin/ntpd -g -N -u ntp:ntp 
type=SOCKADDR msg=audit(10/30/2023 04:48:27.329:704) : saddr={ saddr_fam=inet6 laddr=2001:67c:2550:d::8 lport=4460 } 
type=SYSCALL msg=audit(10/30/2023 04:48:27.329:704) : arch=x86_64 syscall=connect success=no exit=EINPROGRESS(Operation now in progress) a0=0x4 a1=0x7fb5440030f0 a2=0x1c a3=0x4000 items=0 ppid=1 pid=4677 auid=unset uid=ntp gid=ntp euid=ntp suid=ntp fsuid=ntp egid=ntp sgid=ntp fsgid=ntp tty=(none) ses=unset comm=ntpd exe=/usr/sbin/ntpd subj=system_u:system_r:ntpd_t:s0 key=(null) 
type=AVC msg=audit(10/30/2023 04:48:27.329:704) : avc:  denied  { name_connect } for  pid=4677 comm=ntpd dest=4460 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:object_r:ntske_port_t:s0 tclass=tcp_socket permissive=1 
----

# grep nts /etc/ntp.conf 
server nts.netnod.se:4460 nts iburst # Anycast
#

To reproduce the problem, I chose one of the servers listed here and restarted the ntpd service:
 * https://gist.github.com/jauderho/2ad0d441760fc5ed69d8d4e2d6b35f8d

Comment 4 Milos Malik 2023-10-30 10:29:57 UTC
Test coverage for this BZ exists in a form of PR:
 * https://src.fedoraproject.org/tests/selinux/pull-request/445

The PR waits for a review.

Comment 5 jhamlin96 2023-10-30 16:46:20 UTC
PR submitted to selinux-policy: https://github.com/fedora-selinux/selinux-policy/pull/1918

Comment 6 Milos Malik 2023-10-30 17:46:11 UTC
When the EPEL repository is enabled on RHEL-9, the same problem can be reproduced there.

Comment 7 jhamlin96 2023-10-30 18:06:41 UTC
Yes, I was doing the testing on RHEL 9.2. Will the fix end up getting backported to EL9-next?

Comment 8 Milos Malik 2023-10-31 09:02:20 UTC
Here is the Jira ticket that tracks the problem/fix for RHEL-9:
 * https://issues.redhat.com/browse/RHEL-15085

Comment 9 Fedora Update System 2023-12-18 14:01:24 UTC
FEDORA-2023-aeccf7b447 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-aeccf7b447

Comment 10 Fedora Update System 2023-12-19 01:42:10 UTC
FEDORA-2023-aeccf7b447 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-aeccf7b447`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-aeccf7b447

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2024-01-03 02:18:05 UTC
FEDORA-2023-aeccf7b447 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.