Bug 2091979

(In reply to Renaud Métrich from comment #0)
> Description of problem:
> 
> There are multiple issues encountered when enabling poly-instantiation while
> SELinux is enabled (the default).
> I'm filing this against PAM because a global solution to the issues below
> has to be implemented.
> 
> 1. Default directories /tmp-inst and /var/tmp/tmp-inst are not labeled
> properly when created by the admin manually (as recommended in
> /etc/security/namespace.conf)

I guess you should request this point to the SELinux team.

> 
>    IMHO /etc/security/namespace.conf should tell to start the service
> "pam_namespace.service" manually, which is simple and safe.

I haven't used pam_namespace much but when I tested it in RHEL8 some months ago I don't remember having to start "pam_namespace.service" manually. Are you sure about this point?

> 
> 2. I cannot find in our documentation any word about enabling required
> boolean "polyinstantiation_enabled"
> 
>     The more recent documentation on this is RHEL7.

Do you mean "allow_polyinstantiation"?

For further reference: https://access.redhat.com/solutions/5268601

> 
> 3. Users cannot ssh password-less with their key
> 
>     This is because sshd at this step reads non-instantiated home directory
> (/home/<user>/.ssh/authorized_keys) instead of instantiated one.
>     Additionally once poly-instantiation is enabled the user cannot manage
> this file anymore, preventing the user from "fixing" keys.
> 
> 4. Using "restorecon" on /tmp-inst breaks the labels, "default_t" gets
> applied
> 
>     This is because the policy only knows "/tmp-inst" to be labeled with
> "tmp_t" but not "/tmp-inst/.*" to be labeled with "<<none>>".
> 

Again, I guess you should request this point to the SELinux team.

> 5. "pam_namespace.service" should run before users can log in
> (Before=systemd-user-sessions.service)
> 
>     This is needed to avoid a race where users may try to log in but
> directories do not exist yet.
> 

Please check point number 1.

> 6. "pam_namespace_helper" executed by "pam_namespace.service" doesn't read
> additional files in /etc/security/namespace.d
> 

You are right.

Finally, did you try the poly-instantion from the graphical environment? It's not clear from your report. If so, maybe you are hitting https://bugzilla.redhat.com/show_bug.cgi?id=1861836

> I haven't used pam_namespace much but when I tested it in RHEL8 some months ago I don't remember having to start "pam_namespace.service" manually. Are you sure about this point?

Creating directories manually, using just "mkdir /tmp-inst" doesn't work, we need "mkdir -Z /tmp-inst".
Since "pam_namespace.service" does this job actually, we could just tell the admin to start the service manually if he doesn't want to reboot.

> Do you mean "allow_polyinstantiation"?

The boolean is "polyinstantiation_enabled" on RHEL and Fedora

> did you try the poly-instantion from the graphical environment

I tested without graphical env, just ssh.

Regarding SELinux related parts, yes I will make them aware so that they fix it.
However we should then state that /tmp-inst and /var/tmp/tmp-inst is NOT an example but the "standard directories" to use on RHEL and if customer wants to use something else, he will have to generate file contexts.

I've had some time to test the problems that you mentioned and these are my findings.

The default instance directory is /tmp/tmp-inst and not /tmp-inst. That's why you might be experiencing problems, like the one related to "restorecon". The labelling that this tool applies to the folder is the correct one.

/tmp/tmp-inst and /var/tmp/tmp-inst are created automatically by pam_namespace. So there's no need to start pam_namespace.service or to create them manually.

In point 3 you state that passwordless ssh isn't working. I'm unable to ssh at all when enabling the polyinstatiation for the home directory. Can you provide the reproduction steps?

> The default instance directory is /tmp/tmp-inst and not /tmp-inst.

I don't have this: on a vanilla RHEL9, I have this in /etc/security/namespace.conf:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
#/tmp     /tmp-inst/       	level      root,adm
#/var/tmp /var/tmp/tmp-inst/   	level      root,adm
#$HOME    $HOME/$USER.inst/     level
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Si by just uncommenting the lines, I'll get /tmp-inst

> /tmp/tmp-inst and /var/tmp/tmp-inst are created automatically by pam_namespace. So there's no need to start pam_namespace.service or to create them manually.

This requires a reboot to happen to have the service execute. And the text in /etc/security/namespace.conf states the "preferred approach" is creating manually:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# Instance parent directories must exist for the polyinstantiation
# mechanism to work. By default, they should be created with the mode
# of 000. pam_namespace module will enforce this mode unless it
...
# at boot by pam_namespace_helper, but in a live system, system
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# administrators should create the parent directories before enabling
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# them here.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

> In point 3 you state that passwordless ssh isn't working. I'm unable to ssh at all when enabling the polyinstatiation for the home directory. Can you provide the reproduction steps?

I think you didn't enable the boolean: "semanage boolean -m polyinstantiation_enabled --on"
This is requirement.

(In reply to Renaud Métrich from comment #4)
> > The default instance directory is /tmp/tmp-inst and not /tmp-inst.
> 
> I don't have this: on a vanilla RHEL9, I have this in
> /etc/security/namespace.conf:
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------
> #/tmp     /tmp-inst/       	level      root,adm
> #/var/tmp /var/tmp/tmp-inst/   	level      root,adm
> #$HOME    $HOME/$USER.inst/     level
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------
> 
> Si by just uncommenting the lines, I'll get /tmp-inst
> 

You are right, sorry for the confusion.

> > /tmp/tmp-inst and /var/tmp/tmp-inst are created automatically by pam_namespace. So there's no need to start pam_namespace.service or to create them manually.
> 
> This requires a reboot to happen to have the service execute. And the text
> in /etc/security/namespace.conf states the "preferred approach" is creating
> manually:
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------
> # Instance parent directories must exist for the polyinstantiation
> # mechanism to work. By default, they should be created with the mode
> # of 000. pam_namespace module will enforce this mode unless it
> ...
> # at boot by pam_namespace_helper, but in a live system, system
>                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> # administrators should create the parent directories before enabling
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> # them here.
> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8<
> --------
> 

This is to avoid any security problem, that was the point that I was missing. We should also improve this in the documentation.

> > In point 3 you state that passwordless ssh isn't working. I'm unable to ssh at all when enabling the polyinstatiation for the home directory. Can you provide the reproduction steps?
> 
> I think you didn't enable the boolean: "semanage boolean -m
> polyinstantiation_enabled --on"
> This is requirement.

Reproduced, thanks for you help. However, I wonder if this is a PAM or sshd bug.

> However, I wonder if this is a PAM or sshd bug.

I would say PAM bug, or more precisely missing pam_namespace somewhere in /etc/pam.d/sshd stack so that auth goes with pam_namespace already set up, which is not the case for now.
Since /etc/pam.d/sshd includes /etc/pam.d/password-auth, it ends up being PAM bug :)

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.