selinux September 2022

selinux@lists.fedoraproject.org

6 participants
5 discussions

Setting context in early boot
by Frederick Grose 11 Dec '25

11 Dec '25

I have a general scoping question on setting SELinux context on files/directories during early boot. I'm working on a feature in dracut to implement general stacking of filesystem hierarchies via OverlayFS for the root filesystem within the dmsquash-live-root module. How should I address the setting of context for new files, directories, or links needed to assemble the components for the OverlayFS mount? For example, when I mkdir -m 0755 -p --context=system_u:object_r:root_t:s0 /run/somemountpoint I get this warning in the journal: mkdir: warning: ignoring --context; it requires an SELinux/SMACK-enabled kernel If the SELinux code is not active at this early stage, what is to be done?

3 3

SELinux is preventing systemd-tmpfile from using the sys_resource capability.
by Manfred Lotz 31 Jul '25

31 Jul '25

Hi there, Running Fedora 31 and SELinux still in permissive mode I got SELinux is preventing systemd-tmpfile from using the sys_resource capability. ***** Plugin sys_resource (91.4 confidence) suggests ********************** If you do not want processes to require capabilities to use up all the system resources on your syste> Then you need to diagnose why your system is running out of system resources and fix the problem. According to /usr/include/linux/capability.h, sys_resource is required to: /* Override resource limits. Set resource limits. */ /* Override quota limits. */ /* Override reserved space on ext2 filesystem */ /* Modify data journaling mode on ext3 filesystem (uses journaling resources) */ /* NOTE: ext2 honors fsuid when checking for resource overrides, so you can override using fsuid too */ /* Override size restrictions on IPC message queues */ /* Allow more than 64hz interrupts from the real-time clock */ /* Override max number of consoles on console allocation */ /* Override max number of keymaps */ Do fix the cause of the SYS_RESOURCE on your system. ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that systemd-tmpfile should have the sys_resource capability 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-tmpfile' --raw | audit2allow -M my-systemdtmpfile # semodule -X 300 -i my-systemdtmpfile.pp I also see type=AVC msg=audit(1569414241.452:321): avc: denied { sys_resource } for pid=17409 comm="systemd-tmpfile" capability=24 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:system_r:systemd_tmpfiles_t:s0 tclass=capability permissive=1 type=AVC msg=audit(1569414241.452:322): avc: denied { setrlimit } for pid=17409 comm="systemd-tmpfile" scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:system_r:systemd_tmpfiles_t:s0 tclass=process permissive=1 I have to admit I don't know how to judge this. Before I do anything here I like to understand. -- Manfred

5 5

Not possible to specify smtp password for setroubleshootd?
by Matt Kinni 09 Jun '24

09 Jun '24

Hello, I run a Fedora 35 server and would like setroubleshootd to send email alerts for avc denials, but I'm having trouble configuring this due to the apparent lack of support for configuring an smtp password. The out of the box setroubleshoot.conf sets > smtp_host = localhost > smtp_port = 25 > from_address = SELinux_Troubleshoot , but there is no config parameter for smtp password. For this to actually work on a machine acting as an MTA (I have postfix running locally), the mail server would have to be configured to allow unauthenticated port 25 connections to masquerade as any local system user, which no decent postfix setup would allow. I am not a python programmer, but in my reading of https://pagure.io/setroubleshoot/blob/main/f/framework/src/setroubleshoot/e…, it doesn't appear there is any built in way to support authenticated email sending despite the underlying smtplib being able to do it. I would suggest either a) adding password support for smtplib, or/and b) adding an option to send mail using the sendmail binary, which allows postfix to recognize the running user without any password needed. Has anyone else run into problems deploying the setroubleshootd email alerts in practice? email_alert.py appears simple enough to hack in password support, but I feel a security oriented project like selinux shouldn't require an insecure mail setup in order to send its alerts. Any tips are welcome, Thanks, Matt

2 4

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

Allowing OpenDMARC to send mail
by Matt Domsch 18 Sep '22

18 Sep '22

OpenDMARC (Domain-based Message Authentication, Reporting & Conformance) provides an open source library that implements the DMARC verification service plus a milter-based filter application that can plug in to any milter-aware MTA, including sendmail, Postfix, or any other MTA that supports the milter protocol. One feature of OpenDMARC is that i can send email to domains who have specified in their DMARC DNS record that they wish to receive reports (either aggregate or forensic) from mail servers when a message claiming to originate from their mail domain has been received. This allows sending mail servers to possibly adjust their mail sending practices to ensure all mail they legitimately send are marked as such, and all mail sent as a spoof of their domain then be blocked by filters. opendmarc runs in selinux domain dkim_milter_t (I never got around to asking for a separate dmarc_milter_t domain), and uses popen("/usr/sbin/sendmail -t ...") to send its aggregate or forensic report. selinux policy currently prohibits this behavior. I have been trying to write a custom policy that would allow opendmarc to make the transition to sendmail_t, but have been unsuccessful, hence this plea for help. #============= dkim_milter_t ============== allow dkim_milter_t self:process setrlimit; # opendmarc calls setrlimit() allow dkim_milter_t shell_exec_t:file { execute_no_trans map entrypoint }; # opendmarc calls popen() which invokes /bin/sh allow dkim_milter_t sendmail_exec_t:file { entrypoint execute getattr open read map }; # invokes sendmail which has this file type allow dkim_milter_t sendmail_t : process transition; # allow the transition to sendmail_t type_transition dkim_milter_t sendmail_exec_t : process sendmail_t; # However, once sendmail is running and tries to create its queue files in /var/spool/mqueue which has type mqueue_spool_t, the audit logs indicate it's still running as dkim_milter_t which doesn't have permissions to manage that directory (nor should it - that's sendmail's job). type=AVC msg=audit(1662776560.507:10521833): avc: denied { create } for pid=1385220 comm="sendmail" name="df28A2Meeh1385220" scontext=system_u:system_r:dkim_milter_t:s0 tcontext=system_u:object_r:mqueue_spool_t:s0 tclass=file permissive=0 What do I need to do to get opendmarc to be running in sendmail_t automatically following the popen()? Also filed in https://bugzilla.redhat.com/show_bug.cgi?id=2125030 Thanks, Matt

3 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux September 2022