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
plenty of unix_chkpwd
by lejeczek
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.
3 years
question about selinux context when creating a directory
by Anthony LaTorre
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
3 years
Memory protection checking
by Abhijit Tikekar
> 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
3 years
