Bugzilla – Bug 1095670
Problem with suid pgms on Leap-15.0
Last modified: 2023-04-06 09:15:55 UTC
I am upgrading an older SuSE-13.2 box to Leap. I have done a fresh Leap-15.0 install and ported over the source code that we ran on the 13.2 box. It builds fine but I am having an issue. The program is/has to be an suid pgm. It also uses fork/execvpe/wait to execute some external scripts. And that is where my problem lies. The user is a member of several groups but these group memberships seem to disappear when these external scripts are executed. For instance the user is a member of the cdrom group so he can eject and work with a DVD. I have created a simple example script and source for a pgm that execvpe's that script which shows my problem. test.sh script: #!/bin/sh whoami id test.c pgm source: #define _GNU_SOURCE #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <string.h> int main() { char *path = getenv("PATH"); char pathenv[strlen(path) + sizeof("PATH=")]; sprintf(pathenv, "PATH=%s", path); char *envp[] = {pathenv, NULL}; char *tests[] = {"./test.sh", NULL}; execvpe(tests[0], tests, envp); } #cc test.c #/a.out markh uid=5076(markh) gid=100(users) groups=100(users),19(floppy),200(lcrs),484(tape),485(lp),488(disk),489(dialout),490(cdrom) Then as root: #chown root ./a.out #chgrp root ./a.out #chmod +s ./a.out Then as user #./a.out markh uid=5076(markh) gid=100(users) groups=100(users) Once the pgm is owned by root and suid, I lose all my group memberships for some unknown reason. It is not proper to me. This all works fine on 13.2 but does not on Leap 15 or Leap 42.3. Is there some security setting somewhere that broke this?
As described it is specific to bash which explicitly resets list of supplementary groups in disable_priv_mode () (patch bash-4.4.dif). So forwarding to bash maintainer ...
POS36-C: "Consequently, it is recommended that a program relinquish supplementary group IDs immediately before relinquishing root privileges." rpmlint warns about a missing-call-to-setgroups-before-setuid.
(In reply to Jan Ritzerfeld from comment #2) > POS36-C: "Consequently, it is recommended that a program relinquish > supplementary group IDs immediately before relinquishing root privileges." > rpmlint warns about a missing-call-to-setgroups-before-setuid. That is the reason why the setgroup is there: @@ -1277,6 +1278,7 @@ disable_priv_mode () { int e; + setgroups(0, NULL); if (setuid (current_user.uid) < 0) { e = errno; ...maybe the initgroups(3) (g)libc call would be better as this does inherent setgroups(2) with users groups as well. Also it would help if rpmlint would mention initgroups(3) as the better option
Was it ever submitted upstream? Was it rejected? If yes, why? In any case, upstream or not, this needs documentation. Behavior is entirely undocumented, not even in changelog, and is incompatible with other distributions and upstream.
(In reply to Andrei Borzenkov from comment #4) > Was it ever submitted upstream? Was it rejected? If yes, why? > > In any case, upstream or not, this needs documentation. Behavior is entirely > undocumented, not even in changelog, and is incompatible with other > distributions and upstream. This was a simple left over done to silent the rpmlint messages for an other bug. I had never added this to changelog as it slipped out. (In reply to Mark Hounschell from comment #0) > I am upgrading an older SuSE-13.2 box to Leap. I have done a fresh Leap-15.0 > install and ported over the source code that we ran on the 13.2 box. It > builds fine but I am having an issue. The program is/has to be an suid pgm. > It also uses fork/execvpe/wait to execute some external scripts. And that is > where my problem lies. The user is a member of several groups but these > group memberships seem to disappear when these external scripts are > executed. For instance the user is a member of the cdrom group so he can > eject and work with a DVD. I have created a simple example script and source > for a pgm that execvpe's that script which shows my problem. You might give version of the latest bash in project Base:System a try as here I have replaced the setgroup(2) system call with the initgroup(3) libc call: https://build.opensuse.org/package/binary/download/Base:System/bash/openSUSE_Leap_15.0/x86_64/bash-4.4-lp150.361.1.x86_64.rpm If this works for you I'll submit the fix tu upstream and will see if Chet does accept this.
https://build.opensuse.org/package/binary/download/Base:System/bash/openSUSE_Leap_15.0/x86_64/bash-4.4-lp150.361.1.x86_64.rpm This did not work for me. Same results. Did it work for you with the provided test case?
(In reply to Mark Hounschell from comment #6) > https://rudin.suse.de:8894/package/binary/download/Base:System/bash/ > openSUSE_Leap_15.0/x86_64/bash-4.4-lp150.361.1.x86_64.rpm > > This did not work for me. Same results. Did it work for you with the > provided test case? Hmmm ... I see a SIGSEGV due not initialized current_user.user_name ... but with fixing that I see abuild@noether:/tmp> cat checkgrp.c #define _GNU_SOURCE #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <string.h> int main() { char *path = getenv("PATH"); char pathenv[strlen(path) + sizeof("PATH=")]; sprintf(pathenv, "PATH=%s", path); char *envp[] = {pathenv, NULL}; char *tests[] = {"/tmp/id.sh", NULL}; execvpe(tests[0], tests, envp); } abuild@noether:/tmp> cat id.sh #!/bin/sh whoami id abuild@noether:/tmp> ll total 32 -rw------- 1 root root 101 Jun 4 10:43 .xauthEJxh4h0IyV -rwsr-sr-x 1 root root 16936 Jun 4 10:48 checkgrp -rw-r--r-- 1 abuild abuild 352 Jun 4 10:48 checkgrp.c -rwxr-xr-x 1 abuild abuild 20 Jun 4 10:48 id.sh abuild@noether:/tmp> ./checkgrp abuild uid=399(abuild) gid=399(abuild) groups=399(abuild),488(video),489(tape),495(cdrom),496(audio)
>Hmmm ... I see a SIGSEGV due not initialized current_user.user_name ... but with >fixing that I see" I don't see that SIGSEGV. Might I ask what you did to fix that. In any case I double checked, I still loose my group memberships using the rpm you pointed me to.
(In reply to Mark Hounschell from comment #8) > >Hmmm ... I see a SIGSEGV due not initialized current_user.user_name ... but with >fixing that I see" > > I don't see that SIGSEGV. Might I ask what you did to fix that. In any case > I double checked, I still loose my group memberships using the rpm you > pointed me to. You might retry the now latest https://build.opensuse.org/package/binary/download/Base:System/bash/openSUSE_Leap_15.0/x86_64/bash-4.4-lp150.362.1.x86_64.rpm as this includes the fixed version
Yes, that one seems to work properly for me in my test case and in my application.
I don't understand how " POS36-C: "Consequently, it is recommended that a program relinquish > supplementary group IDs immediately before relinquishing root privileges." would affect the original submitter. The problem was the loss of supplementary group ID's upon becoming root, where as the POS36C section that was quoted says to relinquish such ID's before relinquishing root privs. As an aside -- since it was an SUID program it would relinquish it's root privs upon exit, so it seems pointless to relinquish any groups as the process goes away. Maybe in some other circumstance that wouldn't be the case, but the 1st point still stands -- the POS36c statement above doesn't say to relinquish groups upon becoming root, but on transitioning away from root. Ideally, the groups active at the beginning of a root session would be those retained when transitioning away from root. I.e this would put things back exactly the way before the UID change. No doubt it is a fear of people not getting it right and having additional groups added as root that propagate to a user. However, reiterating: the above POS36 **recommendation** (not requirement), only would seem to apply when transitioning away from root -- so the original submitter should not have encountered a problem.
(In reply to L. A. Walsh from comment #11) > [...] > The problem was the loss of supplementary group ID's upon becoming root [...] Actually, his problem was the loss of supplementary group IDs when transitioning away from root.
This is an autogenerated message for OBS integration: This bug (1095670) was mentioned in https://build.opensuse.org/request/show/621861 Factory / bash
Submit requests running
Try SR#173129
SUSE-RU-2018:3079-1: An update that has three recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1095661,1095670,1100488 CVE References: Sources used: SUSE Linux Enterprise Module for Basesystem 15 (src): bash-4.4-9.7.1
openSUSE-RU-2018:3139-1: An update that has three recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1095661,1095670,1100488 CVE References: Sources used: openSUSE Leap 15.0 (src): bash-4.4-lp150.8.3.1