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
Fwd: AVC denied for docker while trying to set labels for tmpfs mounts
by Sujithra P
*Thanks Ondrej. Sorry about that, please find the details below.*
On Fri, Jul 23, 2021 at 1:31 AM Ondrej Mosnacek <omosnace(a)redhat.com> wrote:
>
> On Thu, Jul 22, 2021 at 9:25 PM Sujithra P <sujithrap(a)gmail.com> wrote:
> > Thanks Ondrej.
> >
> > Kernel version: Linux #2 SMP Fri Apr 23 09:05:57 PDT 2021 x86_64
> > x86_64 x86_64 GNU/Linux
>
> Somehow that string doesn't contain the actual version :) uname -r
> should return the right version string (something like
> "4.18.0-305.el8.x86_64").
*uname -r5.4.17-2102.201.3.el8uek.x86_64*
>
> > yum list installed | grep selinux
> > container-selinux.noarch
> > 2:2.162.0-1.module+el8.4.0+20195+0a4a4953 @ol8_appstream
> > libselinux.x86_64 2.9-5.el8
> > @ol8_baseos_latest
> > libselinux-utils.x86_64 2.9-5.el8
> > @ol8_baseos_latest
> > python3-libselinux.x86_64 2.9-5.el8
> > @ol8_baseos_latest
> > rpm-plugin-selinux.x86_64 4.14.3-13.el8
> > @ol8_baseos_latest
> > selinux-policy.noarch 3.14.3-67.0.1.el8
> > @ol8_baseos_latest
> > selinux-policy-targeted.noarch 3.14.3-67.0.1.el8
> > @ol8_baseos_latest
> >
> > No unusual errors/warnings in dmesg except
> >
> > SELinux: mount invalid. Same superblock, different security settings
> > for (dev mqueue, type mqueue)
> >
> > but I believe this is not harmful?
>
> Yes, that should be unrelated and (probably) harmless.
>
> FWIW, I did find a data race bug in the related code, but at this
> point I don't see how it would cause the behavior you're seeing. I
> also haven't been able to reproduce the issue by trying to trigger the
> race condition. So it may be just a red herring or I'm just missing
> some key element that makes it happen. I'll keep digging...
>
*Please let me know if any additional info could help?*
*I could reproduce this issue and can provide any needed debug information.*
Thanks.
> > Thanks.
> >
> > On Thu, Jul 22, 2021 at 3:07 AM Ondrej Mosnacek <omosnace(a)redhat.com>
wrote:
> > >
> > > On Thu, Jul 22, 2021 at 12:23 AM Sujithra P <sujithrap(a)gmail.com>
wrote:
> > > > Hi SELinux Experts,
> > > >
> > > > The following issue is described in the below post as well.
> > > > https://github.com/containers/container-selinux/issues/141
> > > >
> > > > Occasionally running into the following selinux denials for docker
> > > >
> > > > type=AVC msg=audit(1626732057.636:4583): avc: denied { associate }
> > > > for pid=57450 comm="dockerd" name="/" dev="tmpfs" ino=150014
> > > > scontext=system_u:object_r:container_file_t:s0:c263,c914
> > > > tcontext=system_u:object_r:lib_t:s0 tclass=filesystem permissive=0
> > > >
> > > > type=AVC msg=audit(1626812823.170:9434): avc: denied { associate }
> > > > for pid=20027 comm="dockerd" name="/" dev="tmpfs" ino=198147
> > > > scontext=system_u:object_r:container_file_t:s0:c578,c672
> > > > tcontext=system_u:object_r:locale_t:s0 tclass=filesystem
permissive=0
> > > >
> > > >
> > > > level=error msg="Handler for POST
> > > >
/v1.40/containers/a3a875e7896384e3bff53b8317e91ed4301a13957f42187eb227f28e09bd877c/start
> > > > returned error: error setting label on mount source
> > > > '/var/lib/kubelet/pods/f7cee5b2-bcd9-4aa1-9d67-c75b677ba2a1/volumes/
kubernetes.io~secret/secret':
> > > > failed to set file label on
> > > > /var/lib/kubelet/pods/f7cee5b2-bcd9-4aa1-9d67-c75b677ba2a1/volumes/
kubernetes.io~secret/secret:
> > > > permission denied"
> > > >
> > > >
> > > > Docker is not able to set labels for these tmpfs mounts because they
> > > > end up having wrong labels when they are created (sometimes
> > > > "locale_t", sometimes "lib_t" which of course is not the
> > > > default/correct context for tmpfs fs).
> > > > Apparently semodule -R and deleting these tmps files or reboot of
the
> > > > node fixes the problem.
> > > > Not sure what is causing the tmpfs mounts to get wrong labels in the
> > > > first place.
> > > >
> > > > Everything seems to be fine to begin with, but as the system keeps
> > > > scheduling pods on the node, this behavior is observed sometimes
(not
> > > > always consistent).
> > > >
> > > >
> > > > OS Details:
> > > >
> > > > NAME="CentOS Linux"
> > > > VERSION="8 (Core)"
> > > > ID="centos"
> > > > ID_LIKE="rhel fedora"
> > > > VERSION_ID="8"
> > > > PLATFORM_ID="platform:el8"
> > > > PRETTY_NAME="CentOS Linux 8 (Core)"
> > > >
> > > > Docker Version:
> > > > Client: Docker Engine - Community
> > > > Version: 19.03.13
> > > > API version: 1.40
> > > > Go version: go1.13.15
> > > > Git commit: 4484c46d9d
> > > > Built: Wed Sep 16 17:02:36 2020
> > > > OS/Arch: linux/amd64
> > > > Experimental: false
> > > >
> > > > Kubernetes Version*
> > > > v1.20.8-gke.1500
> > > >
> > > >
> > > > Any help on how to debug this issue would be greatly appreciated.
> > >
> > > This looks really weird. Could be some subtle kernel bug. What is your
> > > kernel version (run `uname -r`)? Are there any unusual errors/warnings
> > > in the kernel log (`dmesg`) when this happens?
> > >
> > > --
> > > Ondrej Mosnacek
> > > Software Engineer, Linux Security - SELinux kernel
> > > Red Hat, Inc.
> > >
> >
>
> --
> Ondrej Mosnacek
> Software Engineer, Linux Security - SELinux kernel
> Red Hat, Inc.
>
2 years, 11 months
Policies rules generated using "audit2allow -R" questions (risks)
by Todd Sandor
I'm a selinux newbie using RHEL7.9 and I'm in the process of creating
a "private/application" selinux policy for a
large legacy application.
For some AVCs/denials I've been using the audit2allow to generate some
of the rules/interfaces to resolve the AVCs/denials.
Questions about using the "-R" option to generate the policy rules:
1. What are the risks of using the "-R" option?
Do people use the "interfaces" which the "-R" generates in the
policies deployed in production environments?
When "-R" is used, how does the tool itself determine which
"interface" to use? Is it Linux distribution and release specific so
if we upgrade will it be a problem?
The redhat documentation and man page (and other vendor's
documentation) specify it is a risk to use this tool (see [1][2]).
2. When the "-R" option is not used, separate rules are generated that
do not include "interface" rules.
Is it safe to use the rules audit2allow generates (without "-R") or
are those a risk as well?
3. Any other suggestions for resolving AVCs/denials ?
[1]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
[2] audit2allow man page
man audit2allow
...
-R | --reference
Generate reference policy using installed macros. This
attempts to match denials against interfaces and may be
inaccurate.
Thanks
2 years, 11 months
How to solve constraint violation
by Daniel Skip
Hello, I have narrowed my problem down to a constraint violation in my own policy module I am working on but can't seem to fix. I understand that the constrain I need to fix is the following:
constrain lnk_file { create relabelfrom relabelto } ((u1 == u2)) or (t1 == can_change_object_identity)
and then it has this allow rule after the constrain avc violation which is:
allow myuser_t user_tmp_t:lnk_file_create;
"Possible cause is the source user(myuser_u) and target user (system_u) are different."
Any help is appreciated, thank you.
2 years, 11 months
AVC denied for docker while trying to set labels for tmpfs mounts
by Sujithra P
Hi SELinux Experts,
The following issue is described in the below post as well.
https://github.com/containers/container-selinux/issues/141
Occasionally running into the following selinux denials for docker
type=AVC msg=audit(1626732057.636:4583): avc: denied { associate }
for pid=57450 comm="dockerd" name="/" dev="tmpfs" ino=150014
scontext=system_u:object_r:container_file_t:s0:c263,c914
tcontext=system_u:object_r:lib_t:s0 tclass=filesystem permissive=0
type=AVC msg=audit(1626812823.170:9434): avc: denied { associate }
for pid=20027 comm="dockerd" name="/" dev="tmpfs" ino=198147
scontext=system_u:object_r:container_file_t:s0:c578,c672
tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0
level=error msg="Handler for POST
/v1.40/containers/a3a875e7896384e3bff53b8317e91ed4301a13957f42187eb227f28e09bd877c/start
returned error: error setting label on mount source
'/var/lib/kubelet/pods/f7cee5b2-bcd9-4aa1-9d67-c75b677ba2a1/volumes/kubernetes.io~secret/secret':
failed to set file label on
/var/lib/kubelet/pods/f7cee5b2-bcd9-4aa1-9d67-c75b677ba2a1/volumes/kubernetes.io~secret/secret:
permission denied"
Docker is not able to set labels for these tmpfs mounts because they
end up having wrong labels when they are created (sometimes
"locale_t", sometimes "lib_t" which of course is not the
default/correct context for tmpfs fs).
Apparently semodule -R and deleting these tmps files or reboot of the
node fixes the problem.
Not sure what is causing the tmpfs mounts to get wrong labels in the
first place.
Everything seems to be fine to begin with, but as the system keeps
scheduling pods on the node, this behavior is observed sometimes (not
always consistent).
OS Details:
NAME="CentOS Linux"
VERSION="8 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8 (Core)"
Docker Version:
Client: Docker Engine - Community
Version: 19.03.13
API version: 1.40
Go version: go1.13.15
Git commit: 4484c46d9d
Built: Wed Sep 16 17:02:36 2020
OS/Arch: linux/amd64
Experimental: false
Kubernetes Version*
v1.20.8-gke.1500
Any help on how to debug this issue would be greatly appreciated.
Thanks
Sujithra.
2 years, 11 months
'tor' default port
by lejeczek
Hi guys
In selinux-policy-3.14.3-67.el8.noarch it works but
selinux-policy-3.14.3-72.el8.noarch prohibit 'tor' to bind
to default 9080(perhaps more)
Should this be a bug report or we individually should
generate rules locally?
many thanks, L.
2 years, 11 months
