Import fix for CVE-2018-1113

[LucienLassalle]

Imported patch from redhat setup-2.8.71-10

From NIST:

/sbin/nologin and /usr/sbin/nologin to /etc/shells. This violates security assumptions made by pam_shells and some daemons which allow access based on a user's shell being listed in /etc/shells. Under some circumstances, users which had their shell changed to /sbin/nologin could still access the system.

[LucienLassalle]

Scratch Build : https://koji.xcp-ng.org/taskinfo?taskID=71209

[stormi]

It would be good to put the explanation you wrote in the PR description directly in the commit message. Is the patch identical to that of the Red Hat package (no patch description in their headers?)

[stormi]

Are we sure that this change is enough to remove nologin from XCP-ng? Will there be other components which assume this user exists and will try to use it?

[LucienLassalle]

Are we sure that this change is enough to remove nologin from XCP-ng? Will there be other components which assume this user exists and will try to use it?

The patch comes directly from the following version of redhat setup-2.8.71-10, there was no header.

Components use the "shells" file to validate that a user can use a shell. But each component is unique, if another one did not handle it that way, then we may have other CVEs to fix in the future.

In any case this fix does not solve a critical vulnerabilities. It can prevent a potential root access coming from a backdoor/reverse shell for example.

[stormi]

But each component is unique, if another one did not handle it that way, then we may have other CVEs to fix in the future.

My question was rather about the risk for a functional regression if a component expects the nologin shell to be a valid shell and it isn't listed as available anymore. Or worse, components which would fall back to an even more insecure behaviour when nologin is absent.

I think we should evaluate all this before we do such a change in a production release.