selinux August 2021

selinux@lists.fedoraproject.org

3 participants
3 discussions

certmonger post-save scripts & certmonger_unconfined_t domain
by Sam Morris 06 Jun '24

06 Jun '24

Certmonger allows for the configuration of a post-save command to be run after it has obtained new certificates. This can be used to copy the key & certificates out of wherever certmonger is allowed to put them, and save them elsewhere with a particular owner/group, combine the certificate & chain into a single file as required by some software, etc. The problem comes with SELinux which prevents my post-save scripts from being able to do all of that. I thought the solution was to give the scripts the context of certmonger_unconfined_exec_t, which would cause a transition to the certmonger_unconfined_t domain which is as its name suggests unconfined; but I can't get this to work. I'm trying to use runcon to simulate certmonger executing a fake script: # cat /tmp/fakescript #!/bin/bash set -eu id -Z # /tmp/fakescript unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 # ls -Z /tmp/fakescript unconfined_u:object_r:certmonger_unconfined_exec_t:s0 /tmp/fakescript # runcon system_u:system_r:certmonger_t:s0 /tmp/fakescript runcon: ‘/tmp/fakescript’: Permission denied Here is the avc denial: ---- type=PROCTITLE msg=audit(27/04/21 16:16:47.156:153492) : proctitle=runcon system_u:system_r:certmonger_t:s0 /tmp/fakescript type=SYSCALL msg=audit(27/04/21 16:16:47.156:153492) : arch=x86_64 syscall=execve success=no exit=EACCES(Permission denied) a0=0x7ffd8aa768ab a1=0x7ffd8aa75888 a2=0x7ffd8aa75898 a3=0x0 items=0 ppid=177795 pid=177796 auid=sam.admin uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts5 ses=103 comm=runcon exe=/usr/bin/runcon subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(27/04/21 16:16:47.156:153492) : avc: denied { entrypoint } for pid=177796 comm=runcon path=/tmp/fakescript dev="dm-0" ino=33563064 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:certmonger_unconfined_exec_t:s0 tclass=file permissive=0 Even though: # sepolicy transition -s certmonger_t -t certmonger_unconfined_t certmonger_t @ certmonger_unconfined_exec_t --> certmonger_unconfined_t Diving in a little deeper, I can see that certmonger can execute the file: # sesearch -s certmonger_t -t certmonger_unconfined_exec_t -c file -p execute -A allow certmonger_t certmonger_unconfined_exec_t:file { execute execute_no_trans getattr ioctl map open read }; ... and that the file type is an entrypoint for the certmonger_unconfined_t domain: # sesearch -s certmonger_unconfined_t -t certmonger_unconfined_exec_t -c file -p entrypoint -A allow certmonger_unconfined_t certmonger_unconfined_exec_t:file { entrypoint execute getattr ioctl lock map open read }; ... and that transition is permitted from certmonger_t: # sesearch -s certmonger_t -t certmonger_unconfined_t -c process -p transition -A allow certmonger_t certmonger_unconfined_t:process transition; Which leaves me scratching my head, unsure why it doesn't work in practice... -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

2 4

ejabberd and name_bind
by Randy Barlow 17 Aug '21

17 Aug '21

Greetings! The ejabberd Fedora package has its own SELinux policy module that it ships[0]. A user has reported an issue with an SELinux denial with the default ejabberd config[1]. I spent some time trying to modify the policy to allow the name_bind on the port, but it seems that my attempts result in it still being denied: allow ejabberd_t unreserved_port_t:udp_socket name_bind; As I commented on the ticket, I also found that setting the nis_enabled bool on my system to true would solve the problem. However, I think it would be ideal if I could adjust the ejabberd module to do this on the users' behalf, as it is not obvious to the average user (or even to me) that this boolean could be the solution to the problem. Is there something I could adjust in the ejabberd policy that would resolve this issue? Thanks. [0] https://src.fedoraproject.org/rpms/ejabberd/blob/rawhide/f/ejabberd.te [1] https://bugzilla.redhat.com/show_bug.cgi?id=1901466

2 2

machinectl not working
by Louis Seubert 12 Aug '21

12 Aug '21

Hello there, I'm trying to start a new systemd-container with machinectl which gives me an error like: Job for systemd-nspawn(a)fedora-33-dev.service failed because the control process exited with error code. See "systemctl status systemd-nspawn(a)fedora-33-dev.service" and "journalctl -xeu systemd-nspawn(a)fedora-33-dev.service" for details. In the journal is nothing really interesting just: Aug 12 09:27:08 desktop-louis systemd-nspawn[4937]: Failed to register machine: Access denied Aug 12 09:27:08 desktop-louis systemd-nspawn[4940]: Parent died too early Now if I set se linux to permissive, it work without any problems but I get the following if I lookup the selinux logs: SELinux is preventing systemd-machine from search access on the directory 4940. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-machine should be allowed search access on the 4940 directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd-machine' --raw | audit2allow -M my-systemdmachine # semodule -X 300 -i my-systemdmachine.pp Additional Information: Source Context system_u:system_r:systemd_machined_t:s0 Target Context system_u:system_r:unconfined_service_t:s0 Target Objects 4940 [ dir ] Source systemd-machine Source Path systemd-machine Port <Unknown> Host <Unknown> Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch Local Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name desktop-louis Platform Linux desktop-louis 5.13.8-200.fc34.x86_64 #1 SMP Wed Aug 4 19:59:54 UTC 2021 x86_64 x86_64 Alert Count 1 First Seen 2021-08-12 09:27:08 CEST Last Seen 2021-08-12 09:27:08 CEST Local ID 0ded547d-2c08-4e48-a664-159ec9c9675b Raw Audit Messages type=AVC msg=audit(1628753228.555:412): avc: denied { search } for pid=846 comm="systemd-machine" name="4940" dev="proc" ino=65001 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=dir permissive=0 Hash: systemd-machine,systemd_machined_t,unconfined_service_t,dir,search If I then look up the (presumably inode number 4940) with sudo find / -inum 4940, I get the following: /sys/kernel/tracing/events/compaction/mm_compaction_kcompactd_wake/hist /sys/kernel/debug/tracing/events/compaction/mm_compaction_kcompactd_wake/hist /sys/fs/cgroup/user.slice/user-1000.slice/user(a)1000.service/init.scope/cgroup.events /sys/firmware/acpi/interrupts/gpe13 /usr/share/app-info/icons/fedora/64x64/org.fedoraproject.google-noto-serif-fonts.png Now here comes my question, how should I continue with this problem and where should I report this problem to. Ps. Sorry if I made something wrong fist time using a mailing list. Thanks Louis

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux August 2021