certmonger post-save scripts & certmonger_unconfined_t domain
by Sam Morris
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 weeks
- 2
- 4
ejabberd and name_bind
by Randy Barlow
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 years, 10 months
- 2
- 2
machinectl not working
by Louis Seubert
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
2 years, 10 months
- 1
- 0
- ← Newer
- 1
- Older →