FreeIPA 4.2.3 - freeipa-server-4.2.3-1.1.fc23.x86_64[[BR]]
sssd - sssd-1.13.2-1.fc23.x86_64[[BR]]
Fedora release 23 (Twenty Three)[[BR]]
Linux 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

_comment0: FreeIPA 4.2.3 - freeipa-server-4.2.3-1.1.fc23.x86_64
sssd - sssd-1.13.2-1.fc23.x86_64 => 1450716442484335
_comment1: FreeIPA 4.2.3 - freeipa-server-4.2.3-1.1.fc23.x86_64[[BR]]
sssd - sssd-1.13.2-1.fc23.x86_64[[BR]]
Fedora release 23 (Twenty Three)[[BR]]
Linux lx-prd-global-sys-im-01.unix.timwe.com 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
=> 1450716462676385

Well, root can do anything including adding a custom PAM module to the stack or installing a keylogger. Wouldn't something like https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace be a more systematic solution?

This ticket appears to have been filed to SSSD 1.13.4 directly, moving to needs_triage.

milestone: SSSD 1.13.4 => NEEDS_TRIAGE

The main problem is: "user that somehow gains root access". If someone has root access then he can do anything. Install custom packages which will send password anywhere. Change pam-stack and steal password there ...

Even obfuscated password will not help because root can collect them and transform to normal form.

cc: => lslebodn
description: In a fully AD<->IPA integrated environment, a user that somehow gains root access in one of the servers, can, by stracing the sssd_pam process obtain the domain user's password for each user that logs into the server.
Is it viable to create some kind of password obfuscation method for this inter process communication? => In a fully AD<->IPA integrated environment, a user that somehow gains root access in one of the servers, can, by stracing the sssd_pam process obtain the domain user's password for each user that logs into the server.
Is it viable to create some kind of password obfuscation method for this inter process communication?

I really do not know what sssd can do to prevent such situation.

Regarding root privileges that's true but it's one thing to have local user accounts compromised and a totally different one to have domain users accounts compromised.[[BR]]
But I understand your point and that's a risk we have to weigh if we choose to go for this centralized authentication solution.

Tks

Well, not only that but if you're a local root[*] nothing prevents you from installing a pam module that dumps all passwords or even a keylogger...

[*] and if we ignore stuff like SELinux

Fields changed

resolution: => invalid
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3946

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.