Re: certmonger post-save scripts & certmonger_unconfined_t domain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

If I understand correctly, your problem is gone now. If you need some additional help, feel free to reply back.

I spotted one more thing:

On Wed, Apr 28, 2021 at 2:25 PM Sam Morris <sam@xxxxxxxxxxxxx> wrote:
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

The target context is etc_t, but the only file/dir in the path with this type should be /etc.
It is a good idea to relabel some parts of the filesystem before in-deep troubleshooting:

 # /sbin/restorecon -Rv /etc

or setup the machine to relabel all filesystems on the next reboot:

 # fixfiles onboot
and reboot the system.



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




--

Zdenek Pytela
Security SELinux team
_______________________________________________
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

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux