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, 4 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, 4 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, 4 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, 4 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, 4 months
