On Tue, 2021-04-27 at 21:11 +0200, Zdenek Pytela wrote:
> runcon is a useful tool, but its usage is a bit tricky: it can be
> used to run a process in a different context, but only if policy
> allows it. Namely, it uses setexeccon(3) to set the new process
> context and on the very next execvp(2) the context is checked and the
> change evaluated.
>
> You are right with your commands how to check the 3 important parts
> to allow a transition. However, in your first command, you see the
> shell is running in unconfined_t. Is there a transition allowed to
> certmonger_t?
>
> # sesearch -T -s unconfined_t -c process |grep certmonger_t
> <>
>
> No. You would actually need a 3-link chain (certmonger_initrc_exec_t,
> certmonger_exec_t, certmonger_unconfined_exec_t), so it'd be
> worth writing a custom policy if you need to have it working from
> console.
Ah, so I needed to look at the SYSCALL event, which has
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023, in order to
realise that I wasn't really launching the script from the domain that
I thought I was...
Thanks for explaining that.
> I still don't quite understand what is to be done there though. For
> instance, which process executes the post-save commands? Are there
> any audit records when it fails? Are there additional error messages
> in journal?
In the particular case I was debugging, it looks like certmonger
renewed the certificate a long time ago an this useful information
has been rotated away.
So, rather than repeatedly renewing the certificate until I got the
script working, I wanted to use runcon to simulate certmonger running
my script so that I could find out if it was SELinux that prevented the
script from working.
Now I understand that the problem was really my assumption that I
understood how to use runcon to diagnose this sort of problem. :)
I've now gone back to certmonger and created a tracking request using
the SelfSign CA, which I can renew as many times as I want while
debugging the script. I've used that to prove that
certmonger_unconfined_exec_t does work as expected, and that the
problem was therefore with my post-save script and nothing to do with
SELinux policy.
Since the existence and usage of certmonger_unconfined_t is a bit
under-documented IMO, here's how I proved to myself that this domain
can be used to allow certmonger to launch post-save command scripts
that are able to do things that certmonger itself is not:
This script tries to create a file in /etc, which SELinux policy will
prevent:
$ cat /tmp/fakescript.unconfined
#!/bin/sh
set -eu -o pipefail
id > /etc/fakercert-id -Z
Here's how to use the SelfSign CA to creat a certificate and then
invoke the
script:
# selfsign-getcert request -w -v -I fakecert -f
/etc/pki/tls/certs/fakescript.crt -k
/etc/pki/tls/private/fakescript.key -C /tmp/fakescript.unconfined
New signing request "fakecert" added.
State NEWLY_ADDED_READING_CERT, stuck: no.
State GENERATING_CSR, stuck: no.
State POST_SAVED_CERT, stuck: no.
State MONITORING, stuck: no.
That causes this avc denial; as expected, certmonger_t is not allowed
to modify
etc_t:
type=AVC msg=audit(28/04/21 11:10:01.147:164884) : avc: denied {
create }
for pid=187115 comm=fakescript.unconfined name=fakercert-id
scontext=system_u:system_r:certmonger_t:s0
tcontext=system_u:object_r:etc_t:s0
tclass=file permissive=0
After using chcon to change the type of the script to
certmonger_unconfined_exec_t:
$ ls -Z /tmp/fakescript.unconfined
unconfined_u:object_r:certmonger_unconfined_exec_t:s0
/tmp/fakescript.unconfined
... I can tell certmonger to renew the certificate. In doing so it will
launch the script--now with the right type to trigger transition to
certmonger_unconfined_t:
# getcert resubmit -i fakecert -w -v
Resubmitting "fakecert" to "SelfSign".
State GENERATING_CSR, stuck: no.
State NOTIFYING_ISSUED_SAVED, stuck: no.
State MONITORING, stuck: no.
There's now no avc denial, hurrah! And here's the created file:
# cat /etc/fakercert-id
context=system_u:system_r:certmonger_unconfined_t:s0
I hope someone else finds that helpful some day!
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/selinux@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
