post-save command to "ipa-getcert request" not working

[Ranbir]

Hello Everyone,

I'm running an updated CentOS 8 KVM on an up to date CentOS 7 host. My
freeipa servers CentOS 7 hosts and fully updated, too. In the KVM I'm
requesting a certificate from my freeipa CA, which in and of itself
works just find. But, when I add a post-save command, that command is
never executed.

Here's the request I'm making:

ipa-getcert request -g 2048 -k /etc/pki/containers/sabnzbd-
server/sabnzbd-server.key -f /etc/pki/containers/sabnzbd-
server/sabnzbd-server.cert -K HTTP/sabnzbd.theinside.rnr -N
"CN=sabnzbd.theinside.rnr,O=THEINSIDE.RNR" -D sabnzbd.theinside.rnr -C
/usr/local/sbin/sabnzbd-server-certs -v -w

The content of that script is just a one liner for podman to copy the
contents of the /etc/pki/containers/sabnzbd-server/ directory to my
container. The script works without issue if I run it manually. I'm
also able to successfully run the podman command at a terminal.

At first I had the command in the script entered directly in the
request, which also didn't work. The bash script was my last attempt at
getting the post-save command to work.

I don't see any errors in the logs or in the terminal. In fact, it
looks like certmonger doesn't even attempt to run the post-save
command. Here's a short snippet from the log:

-- Logs begin at Sat 2021-07-24 17:02:34 EDT, end at Mon 2021-07-26 00:43:48 EDT. --
Jul 26 00:16:16 containment01 certmonger[109481]: Certificate in file
"/etc/pki/containers/sabnzbd-server/sabnzbd-server.cert" issued by CA and
saved.
Jul 26 00:16:16 containment01 certmonger[30743]: 2021-07-26 00:16:16 [30743] No hooks set
for pre-save command.
Jul 26 00:16:16 containment01 certmonger[30743]: 2021-07-26 00:16:16 [30743] Certificate
issued (0 chain certificates, 0 roots).
Jul 26 00:16:16 containment01 certmonger[30743]: ".
Jul 26 00:16:16 containment01 certmonger[30743]: -----END CERTIFICATE-----

Am I doing something wrong or have I hit a bug?



-- 
Ranbir

[Rob Crittenden]

Ranbir via FreeIPA-users wrote:
>  Hello Everyone,
>  
>  I'm running an updated CentOS 8 KVM on an up to date CentOS 7 host. My
>  freeipa servers CentOS 7 hosts and fully updated, too. In the KVM I'm
>  requesting a certificate from my freeipa CA, which in and of itself
>  works just find. But, when I add a post-save command, that command is
>  never executed.
>  
>  Here's the request I'm making:
>  
>  ipa-getcert request -g 2048 -k /etc/pki/containers/sabnzbd-
>  server/sabnzbd-server.key -f /etc/pki/containers/sabnzbd-
>  server/sabnzbd-server.cert -K HTTP/sabnzbd.theinside.rnr -N
>  "CN=sabnzbd.theinside.rnr,O=THEINSIDE.RNR" -D sabnzbd.theinside.rnr -C
>  /usr/local/sbin/sabnzbd-server-certs -v -w
>  
>  The content of that script is just a one liner for podman to copy the
>  contents of the /etc/pki/containers/sabnzbd-server/ directory to my
>  container. The script works without issue if I run it manually. I'm
>  also able to successfully run the podman command at a terminal.
>  
>  At first I had the command in the script entered directly in the
>  request, which also didn't work. The bash script was my last attempt at
>  getting the post-save command to work.
>  
>  I don't see any errors in the logs or in the terminal. In fact, it
>  looks like certmonger doesn't even attempt to run the post-save
>  command. Here's a short snippet from the log:
>  
>  -- Logs begin at Sat 2021-07-24 17:02:34 EDT, end at Mon 2021-07-26 00:43:48 EDT. --
>  Jul 26 00:16:16 containment01 certmonger[109481]: Certificate in file
> "/etc/pki/containers/sabnzbd-server/sabnzbd-server.cert" issued by CA and
> saved.
>  Jul 26 00:16:16 containment01 certmonger[30743]: 2021-07-26 00:16:16 [30743] No hooks set
> for pre-save command.
>  Jul 26 00:16:16 containment01 certmonger[30743]: 2021-07-26 00:16:16 [30743] Certificate
> issued (0 chain certificates, 0 roots).
>  Jul 26 00:16:16 containment01 certmonger[30743]: ".
>  Jul 26 00:16:16 containment01 certmonger[30743]: -----END CERTIFICATE-----
>  
>  Am I doing something wrong or have I hit a bug? 
Perhaps the command isn't executable?

It works fine for me, and IPA relies on it.

[root@ipa] # cat /usr/local/sbin/testme
#!/bin/sh
touch /tmp/hello
[root@ipa]# ls -l /tmp/hello
ls: cannot access '/tmp/hello': No such file or directory
[root@ipa]# ipa-getcert request -f /etc/pki/tls/certs/test.pem -k
/etc/pki/tls/private/test.key -D `hostname` -K host/`hostname` -C
/usr/local/sbin/testme -w -v
New signing request "20210726121048" added.
State NEWLY_ADDED_READING_KEYINFO, stuck: no.
State GENERATING_CSR, stuck: no.
State SUBMITTING, stuck: no.
State SAVING_CERT, stuck: no.
State MONITORING, stuck: no.
[root@ipa]# ls -l /tmp/hello
-rw-------. 1 root root 0 Jul 26 08:10 /tmp/hello

certmonger logging around hooks is not the best. It logs when it adds a
hook for a request (at level 3) and when there is no hook to execute for
 a request, but it doesn't log when it executes a hook unless something
goes wrong.

rob

[Ranbir]

On Mon, 2021-07-26 at 08:20 -0400, Rob Crittenden via FreeIPA-users
wrote:
>  Perhaps the command isn't executable? 
It's definitely executable because I ran the script on its own. The
podman command works if I use it directly instead of from the script.
That's why I'm confused!


>  It works fine for me, and IPA relies on it. 
I'll try creating another cert and using a different command. Maybe
it'll work. If it does, then there's something else going on that's
preventing certmonger from using podman (I assume).


-- 
Ranbir

[Ranbir]

On Mon, 2021-07-26 at 08:20 -0400, Rob Crittenden via FreeIPA-users
wrote:
>  [root@ipa] # cat /usr/local/sbin/testme
>  #!/bin/sh
>  touch /tmp/hello
>  [root@ipa]# ls -l /tmp/hello
>  ls: cannot access '/tmp/hello': No such file or directory
>  [root@ipa]# ipa-getcert request -f /etc/pki/tls/certs/test.pem -k
>  /etc/pki/tls/private/test.key -D `hostname` -K host/`hostname` -C
>  /usr/local/sbin/testme -w -v
>  New signing request "20210726121048" added.
>  State NEWLY_ADDED_READING_KEYINFO, stuck: no.
>  State GENERATING_CSR, stuck: no.
>  State SUBMITTING, stuck: no.
>  State SAVING_CERT, stuck: no.
>  State MONITORING, stuck: no.
>  [root@ipa]# ls -l /tmp/hello
>  -rw-------. 1 root root 0 Jul 26 08:10 /tmp/hello
>   
I ran your test on my server, but it failed to run the command on my
end. Also, the steps reported by certmonger are different for me:

New signing request "20210726231003" added.
State NEWLY_ADDED_READING_CERT, stuck: no.
State MONITORING, stuck: no.

This time I don't see any new denials. O_O


-- 
Ranbir

[Ranbir]

On Mon, 2021-07-26 at 19:21 -0400, Ranbir via FreeIPA-users wrote:
>  I ran your test on my server, but it failed to run the command on my
>  end. Also, the steps reported by certmonger are different for me:
>  
>  New signing request "20210726231003" added.
>  State NEWLY_ADDED_READING_CERT, stuck: no.
>  State MONITORING, stuck: no. 
Oh, this one is my bad: I didn't delete the cert and key generated from
the previous run. :/

I'll have to run the test again...after I take a break.

-- 
Ranbir

[Sam Morris]

If you are running SELinux in enforcing mode then it's possible that your script is
being confined by the certmonger_t domain, which could prevent your file copy from
working.

You can search for AVC denials related to certmonger_t with the command:

# ausearch --interpret --context certmonger_t

If you see output corresponding to the time certmonger ran your script then you're
probably hitting this issue. You can also look at the 

The way I solved it was to set things up so that the script runs in the
certmonger_unconfined_t domain, which will allow the script to do anything. The way to do
this is change the file context of the script to certmonger_unconfined_exec_t. I wrote up
some notes about how to do this here:

https://robots.org.uk/CertmongerSELinux

(It would be really handy if this was explained by the official Certmonger
documentation...)

--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

[Ranbir]

On Mon, 2021-07-26 at 16:38 +0000, Sam Morris via FreeIPA-users wrote:
>  If you are running SELinux in enforcing mode then it's possible
> that
>  your script is being confined by the certmonger_t domain, which could
>  prevent your file copy from working.
>  
>  You can search for AVC denials related to certmonger_t with the
>  command:
>  
>  # ausearch --interpret --context certmonger_t 

Drat! I briefly considered selinux as being the culprit, but I didn't
delve into it, at all. I don't know why. Here's one of the denials:

type=PROCTITLE msg=audit(2021-07-26 00:16:16.758:5255) :
proctitle=/usr/sbin/certmonger -S -p /run/certmonger.pid -n -d2 
type=SYSCALL msg=audit(2021-07-26 00:16:16.758:5255) : arch=x86_64
syscall=execve success=no exit=EACCES(Permission denied)
a0=0x7ffe1d3ee2e0 a1=0x564a48565c60 a2=0x564a48577110 a3=0x564a4857c1c0
items=0 ppid=30743 pid=109480 auid=unset uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none)
ses=unset comm=certmonger exe=/usr/sbin/certmonger
subj=system_u:system_r:certmonger_t:s0 key=(null) 
type=AVC msg=audit(2021-07-26 00:16:16.758:5255) : avc:  denied  {
execute } for  pid=109480 comm=certmonger name=podman dev="dm-0"
ino=7421320 scontext=system_u:system_r:certmonger_t:s0
tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file
permissive=0


This is easier to read:

type=AVC msg=audit(1627272976.758:5255): avc:  denied  { execute } for
pid=109480 comm="certmonger" name="podman" dev="dm-0"
ino=7421320
scontext=system_u:system_r:certmonger_t:s0
tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file
permissive=0

	Was caused by:
		Missing type enforcement (TE) allow rule.


>  If you see output corresponding to the time certmonger ran your
> script
>  then you're probably hitting this issue. You can also look at the  

Also what?! Also WHAAAAT?! lol (your reply was cut off)


>  The way I solved it was to set things up so that the script runs in
> the
>  certmonger_unconfined_t domain, which will allow the script to do
>  anything. The way to do this is change the file context of the script
>  to certmonger_unconfined_exec_t. I wrote up some notes about how to do
>  this here: 
Unfortunately, that didn't work.

Is there an selinux boolean I need to enable to allow certmonger to
execute podman?


-- 
Ranbir

[François Cami]

On Mon, Jul 26, 2021 at 7:25 PM Ranbir via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org&gt; wrote:

>  On Mon, 2021-07-26 at 16:38 +0000, Sam Morris via FreeIPA-users
> wrote:
>  > If you are running SELinux in enforcing mode then it's possible that
>  > your script is being confined by the certmonger_t domain, which could
>  > prevent your file copy from working.
>  >
>  > You can search for AVC denials related to certmonger_t with the
>  > command:
>  >
>  > # ausearch --interpret --context certmonger_t
>
>
>  Drat! I briefly considered selinux as being the culprit, but I didn't
>  delve into it, at all. I don't know why. Here's one of the denials:
>
>  type=PROCTITLE msg=audit(2021-07-26 00:16:16.758:5255) :
>  proctitle=/usr/sbin/certmonger -S -p /run/certmonger.pid -n -d2
>  type=SYSCALL msg=audit(2021-07-26 00:16:16.758:5255) : arch=x86_64
>  syscall=execve success=no exit=EACCES(Permission denied)
>  a0=0x7ffe1d3ee2e0 a1=0x564a48565c60 a2=0x564a48577110 a3=0x564a4857c1c0
>  items=0 ppid=30743 pid=109480 auid=unset uid=root gid=root euid=root
>  suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none)
>  ses=unset comm=certmonger exe=/usr/sbin/certmonger
>  subj=system_u:system_r:certmonger_t:s0 key=(null)
>  type=AVC msg=audit(2021-07-26 00:16:16.758:5255) : avc:  denied  {
>  execute } for  pid=109480 comm=certmonger name=podman dev="dm-0"
>  ino=7421320 scontext=system_u:system_r:certmonger_t:s0
>  tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file
>  permissive=0
>
>
>  This is easier to read:
>
>  type=AVC msg=audit(1627272976.758:5255): avc:  denied  { execute } for
>  pid=109480 comm="certmonger" name="podman" dev="dm-0"
> ino=7421320
>  scontext=system_u:system_r:certmonger_t:s0
>  tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file
>  permissive=0
>
>          Was caused by:
>                  Missing type enforcement (TE) allow rule.
>
>
>  > If you see output corresponding to the time certmonger ran your script
>  > then you're probably hitting this issue. You can also look at the
>
>
>  Also what?! Also WHAAAAT?! lol (your reply was cut off)
>
>
>  > The way I solved it was to set things up so that the script runs in the
>  > certmonger_unconfined_t domain, which will allow the script to do
>  > anything. The way to do this is change the file context of the script
>  > to certmonger_unconfined_exec_t. I wrote up some notes about how to do
>  > this here:
>
>  Unfortunately, that didn't work.
>
>  Is there an selinux boolean I need to enable to allow certmonger to
>  execute podman?
>  
I don't think so but:
https://bugzilla.redhat.com/show_bug.cgi?id=1777368#c4
contains a list of macros that might be useful in your policy module.
Please continue to post results on the list!

Thanks
François


>  --
>  Ranbir
>
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  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.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Rob Crittenden]

Ranbir via FreeIPA-users wrote:
>  On Mon, 2021-07-26 at 16:38 +0000, Sam Morris via FreeIPA-users
> wrote:
> > If you are running SELinux in enforcing mode then it's possible that
> > your script is being confined by the certmonger_t domain, which could
> > prevent your file copy from working.
> >
> > You can search for AVC denials related to certmonger_t with the
> > command:
> >
> > # ausearch --interpret --context certmonger_t
>  
>  
>  Drat! I briefly considered selinux as being the culprit, but I didn't
>  delve into it, at all. I don't know why. Here's one of the denials:
>  
>  type=PROCTITLE msg=audit(2021-07-26 00:16:16.758:5255) :
>  proctitle=/usr/sbin/certmonger -S -p /run/certmonger.pid -n -d2 
>  type=SYSCALL msg=audit(2021-07-26 00:16:16.758:5255) : arch=x86_64
>  syscall=execve success=no exit=EACCES(Permission denied)
>  a0=0x7ffe1d3ee2e0 a1=0x564a48565c60 a2=0x564a48577110 a3=0x564a4857c1c0
>  items=0 ppid=30743 pid=109480 auid=unset uid=root gid=root euid=root
>  suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none)
>  ses=unset comm=certmonger exe=/usr/sbin/certmonger
>  subj=system_u:system_r:certmonger_t:s0 key=(null) 
>  type=AVC msg=audit(2021-07-26 00:16:16.758:5255) : avc:  denied  {
>  execute } for  pid=109480 comm=certmonger name=podman dev="dm-0"
>  ino=7421320 scontext=system_u:system_r:certmonger_t:s0
>  tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file
>  permissive=0
>  
>  
>  This is easier to read:
>  
>  type=AVC msg=audit(1627272976.758:5255): avc:  denied  { execute } for
>  pid=109480 comm="certmonger" name="podman" dev="dm-0"
> ino=7421320
>  scontext=system_u:system_r:certmonger_t:s0
>  tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file
>  permissive=0
>  
>  	Was caused by:
>  		Missing type enforcement (TE) allow rule.
>  
>  
> > If you see output corresponding to the time certmonger ran your script
> > then you're probably hitting this issue. You can also look at the 
>  
>  
>  Also what?! Also WHAAAAT?! lol (your reply was cut off) 
He linked to his notes at https://robots.org.uk/CertmongerSELinux

Incidentally, Sam's problem can probably be worked around using the
-o/-O and -m/-M getcert options to change owner and mode of the private
key/cert/database files.

> > The way I solved it was to set things up so that the script runs
> in the
> > certmonger_unconfined_t domain, which will allow the script to do
> > anything. The way to do this is change the file context of the script
> > to certmonger_unconfined_exec_t. I wrote up some notes about how to do
> > this here:
>  
>  Unfortunately, that didn't work.
>  
>  Is there an selinux boolean I need to enable to allow certmonger to
>  execute podman? 
There isn't.

rob

[Sam Morris]

>  On Mon, 2021-07-26 at 16:38 +0000, Sam Morris via FreeIPA-users
> wrote:
>  type=PROCTITLE msg=audit(2021-07-26 00:16:16.758:5255) :
>  proctitle=/usr/sbin/certmonger -S -p /run/certmonger.pid -n -d2 
>  type=SYSCALL msg=audit(2021-07-26 00:16:16.758:5255) : arch=x86_64
>  syscall=execve success=no exit=EACCES(Permission denied)
>  a0=0x7ffe1d3ee2e0 a1=0x564a48565c60 a2=0x564a48577110 a3=0x564a4857c1c0
>  items=0 ppid=30743 pid=109480 auid=unset uid=root gid=root euid=root
>  suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none)
>  ses=unset comm=certmonger exe=/usr/sbin/certmonger
>  subj=system_u:system_r:certmonger_t:s0 key=(null) 
>  type=AVC msg=audit(2021-07-26 00:16:16.758:5255) : avc:  denied  {
>  execute } for  pid=109480 comm=certmonger name=podman dev="dm-0"
>  ino=7421320 scontext=system_u:system_r:certmonger_t:s0
>  tcontext=system_u:object_r:container_runtime_exec_t:s0 tclass=file
>  permissive=0 
Hm... so that means (I think) that certmonger_t is not allowed to execute things labelled
with container_runtime_exec_t.


I'm surprised setting your script to certmonger_unconfined_exec_t didn't help - -
can you try the ausearch command after doing so & confirm that your script is now
running in the certmonger_unconfined_t domain?

There's another approach: set the certmonger_t domain to permissive mode (where it no
longer confines at all). Details at <https://danwalsh.livejournal.com/24537.html>;,
but it's a larger hammer than should be needed for this nail...

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

[Ranbir]

On Mon, 2021-07-26 at 22:02 +0000, Sam Morris via FreeIPA-users wrote:
>  
>  I'm surprised setting your script to certmonger_unconfined_exec_t
>  didn't help - - can you try the ausearch command after doing so &
>  confirm that your script is now running in the certmonger_unconfined_t
>  domain? 
I ran ausearch and didn't see anything new after setting the script to
the context you suggested. However, I did see a new denial:


type=USER_AVC msg=audit(1627342577.060:139): pid=978 uid=81
auid=4294967295 ses=4294967295
subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied
{ send_msg } for msgtype=error
error_name=org.freedesktop.systemd1.NoSuchDynamicUser dest=:1.46 spid=1
tpid=6439 scontext=system_u:system_r:init_t:s0
tcontext=system_u:system_r:certmonger_unconfined_t:s0 tclass=dbus
permissive=0  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=?
terminal=?'UID="dbus" AUID="unset" SAUID="dbus"

	Was caused by:
		Missing type enforcement (TE) allow rule.


Running audit2allow on that says:


#============= init_t ==============
allow init_t certmonger_unconfined_t:dbus send_msg;


I don't know if doing that would introduce a security hole.



-- 
Ranbir

[Sam Morris]

I've seen similar before.

In this case, your script probably wanted to look up information about a user by UID. To
do so, it called each of the NSS modules listed in the passwd: line of /etc/nsswitch.conf.
One of those modules made a D-Bus call to a process confined by init_t, which was allowed.
But the SELinux policy prevented the process within init_t from sending its reply back to
the client running in unconfined_t.

This is basically a bug in the policy:
https://github.com/SELinuxProject/refpolicy/issues/18

If you can reproduce this on Fedora or CentOS Stream then it's worth filing a bug on
Red Hat bugzilla (but of course have a search first to see if this particular behaviour
has been seen before).

As for what you can do to fix it in the short term, the suggested policy from audit2allow
looks OK to me. If you're worried about processes within init_t attacking
certmonger_unconfined_t via D-Bus messages then maybe not... there is a macro,
init_dbus_chat, that you might want to use in order to make your policy module a bit more
declerative...

You might have to go around this loop a few times until your script starts working fully.
At that point you could ask on the SELinux mailing list for advice on how to clean the
policy up properly.

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

[Ranbir]

On Tue, 2021-07-27 at 08:45 +0000, Sam Morris via FreeIPA-users wrote:
>  If you can reproduce this on Fedora or CentOS Stream then it's
> worth
>  filing a bug on Red Hat bugzilla (but of course have a search first
>  to see if this particular behaviour has been seen before). 
I migrated the host to CentOS Stream and see the same behaviour with
the same selinux denials.

I think certmonger should be able to do what I'm doing, which is:

podman cp /etc/pki/bloop/blah/derp.cert \
	[rando container:/some/path/inside

I have no idea how everyone else manages certs in their containers.
But, that is how I'd like to be able to since it would be a one time
setup on my end.  I can think of some workarounds: for example, watch
the folder on the host and kick off my script when the files are
updated. But, that's more complicated than it needs to be.

-- 
Ranbir

[Rob Crittenden]

Ranbir via FreeIPA-users wrote:
>  On Tue, 2021-07-27 at 08:45 +0000, Sam Morris via FreeIPA-users
> wrote:
> > If you can reproduce this on Fedora or CentOS Stream then it's worth
> > filing a bug on Red Hat bugzilla (but of course have a search first
> > to see if this particular behaviour has been seen before).
>  
>  I migrated the host to CentOS Stream and see the same behaviour with
>  the same selinux denials.
>  
>  I think certmonger should be able to do what I'm doing, which is:
>  
>  podman cp /etc/pki/bloop/blah/derp.cert \
>  	[rando container:/some/path/inside
>  
>  I have no idea how everyone else manages certs in their containers.
>  But, that is how I'd like to be able to since it would be a one time
>  setup on my end.  I can think of some workarounds: for example, watch
>  the folder on the host and kick off my script when the files are
>  updated. But, that's more complicated than it needs to be.
>   
We can't anticipate every possible script one may want to run.

It was suggested you ask the SELinux folks about the AVCs you're seeing.
Have you done that?

rob

[Ranbir]

On Mon, 2021-08-02 at 18:05 -0400, Rob Crittenden via FreeIPA-users
wrote:
>  We can't anticipate every possible script one may want to run.
>   
Yes, that's not lost on me and I completely understand. Still, I wish
there wasn't a denial! lol

>  It was suggested you ask the SELinux folks about the AVCs you're
>  seeing.
>  Have you done that? 
Not yet. That's on my to do list.

-- 
Ranbir