selinux June 2021

selinux@lists.fedoraproject.org

8 participants
5 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

Does MLS still work in the current version of SElinux or is it still not going to work the the X window system?
by Daniel Skip 28 Jun '21

28 Jun '21

I was just wondering if you can still configure MLS in the current version of SElinux or is still kind of broken?

3 2

plenty of unix_chkpwd
by lejeczek 10 Jun '21

10 Jun '21

hi guys. I get lots of: Jun 10 16:34:03 dzien.private.lot setroubleshoot[489537]: SELinux is preventing /usr/sbin/unix_chkpwd from getattr access on the filesystem /proc. For complete SELinux messages run: sealert -l 0e04b2ea-b63d-481f-9633-e0bf0530e7ba and I yet do not know from what and before I start investigation I wanted to ask if that is indeed a "valid" denial? ... Additional Information: Source Context system_u:system_r:chkpwd_t:s0 Target Context system_u:object_r:proc_t:s0 Target Objects /proc [ filesystem ] Source unix_chkpwd Source Path /usr/sbin/unix_chkpwd Port <Unknown> Host dzien.private.lot Source RPM Packages pam-1.3.1-15.el8.x86_64 Target RPM Packages filesystem-3.8-4.el8.0.1.x86_64 SELinux Policy RPM selinux-policy-targeted-3.14.3-68.el8.noarch Local Policy RPM selinux-policy-targeted-3.14.3-68.el8.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name dzien.private.lot Platform Linux dzien.private.lot 4.18.0-305.3.1.el8.x86_64 #1 SMP Tue Jun 1 16:14:33 UTC 2021 x86_64 x86_64 Alert Count 1988 First Seen 2021-06-09 09:50:01 BST Last Seen 2021-06-10 16:32:01 BST Local ID 87f481c4-e4dd-4b77-80c5-52a898760061 Raw Audit Messages type=AVC msg=audit(1623339121.659:34011): avc: denied { getattr } for pid=487286 comm="unix_chkpwd" name="/" dev="proc" ino=1 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0 type=SYSCALL msg=audit(1623339121.659:34011): arch=x86_64 syscall=fstatfs success=no exit=EACCES a0=3 a1=7ffe61eee320 a2=0 a3=0 items=0 ppid=487285 pid=487286 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=unix_chkpwd exe=/usr/sbin/unix_chkpwd subj=system_u:system_r:chkpwd_t:s0 key=(null) Hash: unix_chkpwd,chkpwd_t,proc_t,filesystem,getattr ... many thanks, L.

1 0

question about selinux context when creating a directory
by Anthony LaTorre 07 Jun '21

07 Jun '21

Hi all, I was recently setting up a webserver with cgit and apache on a fresh Fedora 34 installation and ran into one issue that I still don't quite understand. After installing both apache and cgit, I created the default location expected for git repositories in /var/lib/git via: # mkdir /var/lib/git and then added a few bare repositories and pushed to them. I wasn't able to view the cgit page though and was getting the following errors in audit.log: type=AVC msg=audit(1622927247.335:77187): avc: denied { getattr } for pid=281294 comm="cgit" path="/var/lib/git/chroma.git/HEAD" dev="sda" ino=134922 scontext=system_u:system_r:git_script_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0 I eventually found out that I needed to run: # restorecon -vR /var/lib/git/ which fixed the issue, but I thought it was supposed to happen automatically since there was already a rule which was supposed to set these as type git_content_t (I think that's it). I emailed the cgit package maintainer and he was suprised too, and has since updated the README to include instructions to run restorecon, but I was curious as to whether this should be necessary. Why doesn't the /var/lib/git directory get the correct context? Thanks, Tony

2 2

Memory protection checking
by Abhijit Tikekar 02 Jun '21

02 Jun '21

> All, > > Just stumbled upon the following setting for selinux > > Memory protection checking: actual (secure) > > I could not find any documentation around this. Can anyone point me in the right direction? Is this something controlled separately or related to certain booleans being active? > > Thanks, > > ~ abhi

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux June 2021