Bug 1667524

I guess this was introduced by fixing [1]. Internally, authselect now calls selinux api to set proper label on generated files (setfscreatecon [2]). Obviously, SELinux is preventing authselect to use this function. Since the fix seems to be change in selinux policy, I'm moving this bug there.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1664650
[2] https://github.com/pbrezina/authselect/commit/9451dd55c43ce704e520dd4d62676466cc68b71e#diff-4f5513ba0e1cbc67450a675d4d7c228dR118

I am setting blocker? as this needs to be fixed in rhel 8.0. Since authselect is new tool that is replacing authconfig it would be very inconvenient if it can not be run inside containers and for this not being able to install e.g. ipa server.

Please, fix it in selinux policy if possible or advice me on how to fix this issue in authselect. Thank you.

Since you see avc denials I expect that the problem in container will be in selinux policy but I have another bug [1] where the same backtrace is caused by having selinux disabled. Do you have selinux enabled?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1668025

Yes, selinux is enabled (is in enforcing mode). And I wasn't able to reproduce this bug after execution of `setenforce 0` on host system, so I guess it's related to selinux.

Thank you. This is a different issue then [1]. There is a problem in [1] because authselect tries to obtain default selinux context for a file when selinux is disabled. In this bug, we fail to set default selinux context using setfscreate() because selinux policy does not allow authselect to do it. If there are any steps required in authselect, please advice me. Otherwise I would like you to ask selinux maintainers to fix it in policy.

The consequences of not having it in RHEL 8.0 is that authselect is not functioning inside containers and it will break tools such as ipa-client/server-install or reamld which relies on authselect to configure the system.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1668025

Why should authselect do anything with SELinux contexts in containers where (from the point of view of processes in the container) SELinux is disabled, and context are managed outside of the container confinement? Doesn't authselect try to do something that it has no business of doing?

Code-wise, authselect does this:
https://github.com/pbrezina/authselect/commit/9451dd55c43ce704e520dd4d62676466cc68b71e#diff-4f5513ba0e1cbc67450a675d4d7c228dR118

When creating configuration files, e.g. /etc/authselect/nsswitch.conf it:
1) Get default context for /etc/authselect/nsswitch.conf
2) Using setfscreatecon set the context to be used with next created file
3) Create temporary file /etc/authselect/nsswitch.conf.XXXXXX
4) Later it renames it to /etc/authselect/nsswitch.conf

So we set the selinux context for temporary file to match the final destination.

If selinux is disabled, why does it produce avc denial?

Why isn't all this done simply in the policy, rather than in the application code? It seems very error-prone.

SELinux acts as disabled in containers because you cannot do things like relabel in confined environment. But it does not mean that it is not active on the host, where an attempt to set setfscreatecon is caught.

This was advised upstream: https://github.com/pbrezina/authselect/issues/128

What is the correct solution?

Please talk to the SELinux team (Lukáš V.) for the best solution. If authselect runs in its own SELinux domain, file transition rule should be possible. If it does not run in its own domain, maybe it should. Even if it does not, perhaps filetrans_pattern could be used.

The SELinux team should be consulted.

Lukáš, can you please advise what the solution should be?

Authselect calls some selinux API to ensure that generated files have proper label, see comment #9. This does not seem to work in container, see the bug description.

Thank you.

Had small talk with Petr Lautrbach, there could be some issue in sssd SELinux part, where maybe miss some check for SELinux state. 

Petr, 
PTAL.

That could be the case ... but could please also comment on the general suitability of authselect code manipulating the SELinux contexts, instead of letting the SELinux policy do it?

I'm looking into this but it looks like authselect doesn't check whether SELinux is enabled before it tries to manipulate SELinux related process attributes:

-    fd = mkstemp(tmpfile);;
-    if (fd == -1) {
-        ret = errno;
+    ret = selinux_mkstemp_of(filepath, &tmpfile);
+    if (ret != EOK) {
+        ERROR("Unable to create temporary file for [%s] [%d]: %s",
+              filepath, ret, strerror(ret));

The fix could be to use is_selinux_enabled() and based on result use mkstemp or selinux_mkstemp_of(), something like:

if (is_selinux_enabled() == 1) 
  ret = selinux_mkstemp_of(filepath, &tmpfile);
else
  ret = mkstemp_of(filepath, &tmpfile);

The same problem appears on a system with SELinux disabled:

[root@rhel-8-nightly ~]# sestatus 
SELinux status:                 disabled

[root@rhel-8-nightly ~]# authselect select sssd with-sudo --force
Backup stored at /var/lib/authselect/backups/2019-02-11-17-02-04.7bIHyp
[error] Unable to get current fscreate selinux context!
[error] Unable to create temporary file for [/var/lib/authselect/system-auth] [5]: Input/output error
[error] Unable to write temporary file [/var/lib/authselect/system-auth] [5]: Input/output error
[error] Unable to write generated system files [5]: Input/output error
[error] Unable to activate profile [sssd] [5]: Input/output error
Unable to activate profile [5]: Input/output error

As for the AVC denial message, the setfscreate() is not necessary inside a container and it has no effect anyway:

[root@fec78fb03e1a /]# python3
Python 3.7.2 (default, Jan  3 2019, 09:14:01) 
[GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import selinux
>>> selinux.setfscreatecon('system_u:system_r:passwd_t:s0')
0
>>> f = open('/file', 'w')
>>> f.close()
>>> 

[root@fec78fb03e1a /]# attr -S -g selinux /file
Attribute "selinux" had a 30 byte value for /file:
system_u:object_r:fusefs_t:s0


Everything inside the container runs with system_u:system_r:container_t:s0 and all internal files seem to be assigned with system_u:object_r:fusefs_t:s0 context.

Thank you for the analysis.

Do you see a possibility of removing all SELinux-related code from authselect, and doing the equivalent (filetranses or similar) in the SELinux policy?

SELinux policy rules can cover only SELinux type, not the whole context; while the referenced github issue and patch try to restore/set the user part of context. the code in authselect is wrong. You can use libuser code as an example - https://pagure.io/libuser/blob/master/f/lib/util.c#_696 Notice that there's always is_selinux_enabled() and it uses context from the original file instead of the default context.

The destination file does not yet exist, we are creating it so there is no original file. Therefore it obtains default context for the destination file. I used is_selinux_enabled to fix the issue when selinux is disabled, will it fix also this issue in the container?

It was fixed in authselect-1.0-12.

Actually to be more precise the file may or may not exist so it should detect if it should use fgetfilecon or obtain the default context.

Oleg, can you please retest this with latest authselect-1.0-12 to se if using is_selinux_disabled() fixed this issue as well? Thank you.

(In reply to Pavel Březina from comment #22)
> Actually to be more precise the file may or may not exist so it should
> detect if it should use fgetfilecon or obtain the default context.
> 
> Oleg, can you please retest this with latest authselect-1.0-12 to se if
> using is_selinux_disabled() fixed this issue as well? Thank you.
Works fine now with updated version. Workaround for image building is not need more. Tested with RHEL8 host + RHEL image. Thanks! 

# rpm -qa | grep authselect
authselect-1.0-12.el8.x86_64
authselect-compat-1.0-12.el8.x86_64
authselect-libs-1.0-12.el8.x86_64
# rpm -qa container-selinux
container-selinux-2.75-1.git99e2cfd.module+el8+2769+577ad176.noarch
# rpm -q podman
podman-1.0.0-2.git921f98f.module+el8+2784+9a0c1dfe.x86_64
# getenforce 
Enforcing

Thank you Oleg. I am closing this bug as current release.

I created upstream ticket to address Petr's concerns and do it for next release:
https://github.com/pbrezina/authselect/issues/136