usertools: force local user for sssd process user

[ikerexxe]

System hardening by forcing the sssd user to be loaded from a local database (/etc/passwd) instead of using any remote user. This could happen in very special conditions and might change the owner of the sssd databases and generate a denial of service.

Moreover, clarify user option in sssd.conf, as it accepts both the user name and the id as input. The only constraint is that the user should be present in the local database (/etc/passwd).

[alexey-tikhonov]

There are memory leaks:
https://s3.eu-central-1.amazonaws.com/sssd-ci/PR-5867/3/debian10/ci-make-check-valgrind.log

FAIL: usertools-tests
FAIL: responder_common-tests

Did you try to run make check-valgrind-memcheck locally?

[ikerexxe]

Failure in debian is not related with my changes. From logs:

The following additional packages will be installed:
  fuse
The following NEW packages will be installed:
  fuse sshfs
0 upgraded, 2 newly installed, 0 to remove and 14 not upgraded.
Need to get 118 kB of archives.
After this operation, 268 kB of additional disk space will be used.
Err:1 http://deb.debian.org/debian buster/main amd64 fuse amd64 2.9.9-1+deb10u1
  Temporary failure resolving 'debian.map.fastlydns.net' Temporary failure resolving 'deb.debian.org'
Err:2 http://deb.debian.org/debian buster/main amd64 sshfs amd64 2.10+repack-2
  Temporary failure resolving 'debian.map.fastlydns.net' Temporary failure resolving 'deb.debian.org'


Stderr from the command:

E: Failed to fetch http://deb.debian.org/debian/pool/main/f/fuse/fuse_2.9.9-1+deb10u1_amd64.deb  Temporary failure resolving 'debian.map.fastlydns.net' Temporary failure resolving 'deb.debian.org'
E: Failed to fetch http://deb.debian.org/debian/pool/main/s/sshfs-fuse/sshfs_2.10+repack-2_amd64.deb  Temporary failure resolving 'debian.map.fastlydns.net' Temporary failure resolving 'deb.debian.org'
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Moreover, I executed the CI on demand for debian and it works. So, @alexey-tikhonov I think you can do another round of reviews.

[alexey-tikhonov]

Hi @ikerexxe,

Probably, #5867 (comment) should be answered first.

Imo, humber of changes can be reduced significantly (and thus some other comments will not require addressing).

[alexey-tikhonov]

Thanks for your patience, ACK.

[ikerexxe]

Thanks for investing so much time reviewing it and giving feedback.

[pbrezina]

Pushed PR: #5867

• master
  • 3d25724 - man: sssd.conf and sssd-ifp clarify user option
  • 9c447dc - usertools: force local user for sssd process user

[alexey-tikhonov]

Hi @ikerexxe,

This could happen in very special conditions

what was that special conditions?

If we are talking about 'sssd user', wouldn't _SSS_LOOPS actually protect from using external user resolvable by SSSD?
Or did you mean some "3rd party" NSS modules? And what actually the issue in this case?

[sumit-bose]

Hi,

yes, it is about 3rd party modules as well. The issue was that with some special configuration it was possible that SSSD was not able to access its own cache files anymore, but I can't remember the details, maybe Iker still has the description of the special setup. There might be other solutions to fix it.

But I think Jonathan's suggestion from the bugzilla ticket to use libnss_altfiles as a fallback is worth to consider as well.

bye,
Sumit

[ikerexxe]

But I think Jonathan's suggestion from the bugzilla ticket to use libnss_altfiles as a fallback is worth to consider as well.

I also agree. If SSSD is unable to find the user in the "standard" database it should fallback to the ones provided by libnss_altfiles.

[alexey-tikhonov]

But I think Jonathan's suggestion from the bugzilla ticket to use libnss_altfiles as a fallback is worth to consider as well.

Sumit, what do you mean "to use libnss_altfiles as a fallback"?

I read his comment as "let glibc do it's job, just refrains from resolving this user in SSSD" (and this is exactly what _SSS_LOOPS was already doing).

I also agree. If SSSD is unable to find the user in the "standard" database it should fallback to the ones provided by libnss_altfiles.

And when RHCOS switches to systemd-sysusers?
This feels like reimplementing glibc NSS subsystem within SSSD.