Bug 1672447
| Summary: | sudo is resetting the real user id in the process tables | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas Walker Lynch <thomas.walker.lynch> |
| Component: | sudo | Assignee: | Marek Tamaskovic <mtamasko> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | dkopecek, kzak, mattdm, mtamasko, rsroka, tosykora |
| Target Milestone: | --- | Keywords: | Reopened, Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-04-01 09:08:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Thomas Walker Lynch
2019-02-05 00:06:55 UTC
This affects applications that desire to provide a service to a specified user, particularly those that are called by programs that have been called by sudo. The question within such a program will be 'which user?'. As noted above this question can be perhaps be reliably answered by examining the SUDO_USER variable in the target program called by sudo, I'm not really sure as the environment variable passing system was not designed to be bullet proof (?), but demonstrably not in secondary programs that sudo target program calls. Note, however, setuid root programs do preserve the real id. -r-sr-x---. 1 root morpheus 18440 Feb 5 11:47 real_id_suid_root Where this is the same program as given in the bug report above, runs as: > ./real_id_suid_root real_id: 49972 effective_id: 0 Which is the expected behavior. People have suggested instead using getlogin(3) or programs that call it, but that is based on utmp, as the manpage notes, https://linux.die.net/man/3/getlogin, " Unfortunately, it is often rather easy to fool getlogin()." Others have suggested reading other log files that have similar problems. All of this because the real id is missing. In addition because setuid root programs function as expected, even if such a solution was found, another sudo target program that calls such a program would not know to use this workaround. (Once the real id is lost, it remains lost to all children processes.) Perhaps one solution is to say that a program run by sudo should never call a service that needs to know who the user who it is providing the service for really is. That would be really tough rule for programmers to verify. In addition, today, because the real id has been reset to user, any such program will assume that it is providing the service for root. That is a bad thing. It has surely already happened that root data has been affected by this. This looks to be a manifestation of this bug. Here is the output of a setuid script that outputs sss_cache errors because the program thinks it is not root. I.e. it is examining the realid that sudo has reset, instead of examining the effective id which determines if it has root privilege. Testers using sudo will not see the problem. sss_cache must be run as root useradd: sss_cache exited with status 1 useradd: Failed to flush the sssd cache. sss_cache must be run as root useradd: sss_cache exited with status 1 useradd: Failed to flush the sssd cache. The source code for the setuid root program that calls useradd with fork/exec/wait may be found here: https://github.com/Reasoning-Technology/subu/tree/master/try/useradd_probs this calls sss_cache directly instead of invoking it through useradd: https://github.com/Reasoning-Technology/subu/tree/master/try/sss_cache_probs > make clean > make > sudo ./setuid_root.sh > ./sss_cache Checking we are running from a user and are setuid root. uid 49972, gid 49972, euid 0 egid 49972 yes, uid is not zero, and euid is zero, so we are setuid to the root user. dispatching sss_cache -U to clear users dispatching: arg: 0x7ffdbebdf6f0 /usr/sbin/sss_cache arg: 0x7ffdbebdf6f8 -U /usr/sbin/sss_cache must be run as root <----- error issued by sss_cache sss_cache failed I see your point but if you add stay_setuid in sudoers it is behaving like you intended. here is man sudoers: stay_setuid Normally, when sudo executes a command the real and effective UIDs are set to the target user (root by default). This option changes that behavior such that the real UID is left as invoking user's UID. In other words, this makes sudo act as a setuid wrapper. This can be useful on systems that disable some potentially dangerous functionality when a program run setuid. This option is only effective on systems that support either the setreuid(2) or setresuid(2) system call. This flag is off by default. There are some serious disadvantages to resetting the real UID, some are described in posts above, and it is also noted in the first post that the author of the pam login module man page warns administrators not to do it. So this begs the question: what is it that sudo is buying here by resetting the real UID and losing that information, that is of such value that it overwhelms the disadvantages? It can't be part of giving processes run under it different permissions because the effective UID does that. That there is an option that I can set on my system to change this behavior is a local convenience, but that doesn't help with sharing code that requires real UID information. That covers a large class of programs that need reliable information on who they are providing services for. Unfortunately the alternative mechanism is not secure, that of using environment variables. Many people are using that method. So that is a second problem. It was a lot of work documenting this. Do we just wave our hands and ignore the warnings in the pam docs. Can you not provide a single reason for this behavior before closing this? |