Bug 1676961 - sss_cache ignores effective uid
Summary: sss_cache ignores effective uid
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 33
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: sssd-maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-13 17:03 UTC by Thomas Walker Lynch
Modified: 2021-03-02 01:01 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-23 13:03:02 UTC
Type: Bug


Attachments (Terms of Use)

Description Thomas Walker Lynch 2019-02-13 17:03:36 UTC
Description of problem: 

The sss_cache command can not be run from a setuid root script.  It appears to be looking at the inherited uid instead of at the effective uid under which it is running.  I'm surmising this because sudo currently has a bug where it sets the inherited uid to zero, as well as effectively running as root.


Version-Release number of selected component (if applicable):


How reproducible: very


Steps to Reproduce:
1.https://github.com/Reasoning-Technology/subu/tree/master/try/sss_cache_probs
2. make clean; make
3. sudo ./setuid_root  
4. ./sss_cache

Actual results: 
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  <--!! ut oh!
sss_cache failed



Expected results:
as above but without the ut oh! line and the sss_cached failed line

Additional info:
This is probably why checking ruid instead euid hasn't been noticed:  https://bugzilla.redhat.com/show_bug.cgi?id=1672447

Comment 1 Jakub Hrozek 2019-02-13 17:14:06 UTC
Yes:
https://github.com/SSSD/sssd/blob/master/src/tools/tools_util.h#L36

(I'm just confirming that the code checks the real ID, whether this is OK or not I'll leave for someone else..)

Comment 2 Ben Cotton 2019-08-13 19:33:10 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 3 Fedora Admin user for bugzilla script actions 2020-06-18 14:59:27 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 4 Ben Cotton 2020-11-03 15:09:45 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Sumit Bose 2021-02-23 13:03:02 UTC
Hi,

I do not understand why 'sudo sss_cache ...' isn't used here. To me this sounds like the more modern solution with better access control and auditing. So I'd prefer to not change the current behavior and will close the ticket. Feel free to reopen the ticket if using sudo does not work in your use-case.

bye,
Sumit

Comment 6 Thomas Walker Lynch 2021-02-23 17:32:04 UTC
I am having some difficulty parsing that prior message as it appears  to speak to a different context than that of system programming in C and making system calls from a set uid program.  I do not think that comment would be relevant to this issue, and I hope you would not close the ticket based on not grocking the issue rather than based on understanding the issue and providing an explanation - though I do not think there is an explanation.  Sudo's behavior relative to zeroing out the inherited uid to zero and running as root makes it impossible to write programs to help users to do system tasks.  The inherited uid should be left as the user who started the sequence of events, so that the setuid script can know who it is working for as it does system stuff.  The current behavior also kills the audit trail, by zeroing out the inherited user id, the user who begins the mischief becomes anonymous.  -Thomas

Comment 7 Thomas Walker Lynch 2021-02-23 17:36:15 UTC
to be more clear, to write programs to help users do system tasks, where the knowledge of who the user is is required.  That is why there is an inherited uid in addition to the effective uid.  There are workarounds, such as passing identifying information through the environment, but those work arounds are not secure, because, unlike the inherited uid, the environment may be spoofed. .. that is why the inherited uid and such identification is handled by the OS instead of the application layer, but sudo is currently defeating this mechanism.  And thus, indeed, I do  believe it is a bug.

Comment 8 Sumit Bose 2021-02-25 15:08:40 UTC
Hi,

thanks for explaining your use case. I would recommend to use auditd do record which user is doing what with sudo, see e.g. https://sudoedit.com/log-sudo-with-auditd/.

As an example. If I set

    sudo auditctl -a exit,always -F arch=b64 -F euid=0 -F path=/usr/sbin/sss_cache -S execve -k sudo_audit

and a user with UID 1000 then calls

    date ; sudo sss_cache -E
    Thu Feb 25 14:59:56 UTC 2021

then the administrator can later call

    sudo ausearch -ua vagrant -k sudo_audit -x /usr/sbin/sss_cache

    time->Thu Feb 25 14:59:56 2021
    type=PROCTITLE msg=audit(1614265196.620:5737): proctitle=7373735F6361636865002D45
    type=PATH msg=audit(1614265196.620:5737): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=153852 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=PATH msg=audit(1614265196.620:5737): item=0 name="/sbin/sss_cache" inode=606020 dev=fd:01 mode=0104555 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
    type=CWD msg=audit(1614265196.620:5737): cwd="/home/vagrant"
    type=EXECVE msg=audit(1614265196.620:5737): argc=2 a0="sss_cache" a1="-E"
    type=SYSCALL msg=audit(1614265196.620:5737): arch=c000003e syscall=59 success=yes exit=0 a0=561aea8a88b8 a1=561aea8b0178 a2=561aea8c7160 a3=1 items=2 ppid=59080 pid=59082 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="sss_cache" exe="/usr/sbin/sss_cache" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sudo_audit"

So you get full path of the command with options, execution time and 'auid=1000'



If you prefer to do this manually in scripts you can check /proc/self/loginuid, e.g.

    sudo  cat /proc/self/loginuid
    1000



I hope one of this will work for you.

bye,
Sumit

Comment 9 Thomas Walker Lynch 2021-03-02 01:01:10 UTC
Gosh it seems that I have raised a systems program issue but am being pulled into a systems administration discussion.  I get this impression because there is no discussion about the purpose of the inherited user id, the use case code I put up on github as noted in the original approach,  or any other systems programming stuff.

For example, the work around Sumit posts just above for recovering the inherited user id is a lot of unnecessary work and probably would not be reliable or secure.  i.e. that the (formerly) short system program should go to the file system, parse a log file and in some reliably manner in a dynamic system find the exact entry corresponding to its own invocation, and then go to /etc/password and parse that file also, so as to translate a user name back to the uid. Please keep in mind, we are talking about a (formerly) short C program doing this, not a Python program, and not a human being. Being able to provably get the correct line from the log file and making sure that /etc/password is still coherent data, and perhaps another couple of end cases, are non-trivial programming problems in this context.  Wouldn't it be much better to just not zero out the 4 bytes in the first place so that they do not have to be recovered???

Surely the person who closes this bug report would be flaunting his or her understanding of the systems programming issues and explain why it was a worthwhile trade off to change the many years now conventional behavior of Unix in passing this 4 byte inherited uid register through the OS, instead of to going to the file system while solving a relatively complex parsing problem.  Where is the advantage in forcing this new situation?

Anyway, what is it to me? I can just patch the binary to not zero out the register if need be.  I just thought someone would appreciate the issue being raised, if nothing else, then for a good systems programming discussion and a better understand of Linux personality.


Note You need to log in before you can comment on or make changes to this bug.