[sudo-users] Odd sudo behavior: some users can, others cannot
Axley, Jason
jason.axley at wamu.net
Thu Apr 27 17:26:29 EDT 2006
Posting to the sudo-users list as well, but we're having a very strange problem with our sudo configuration on Solaris where sudo is not being consistent about who is allowed and who is not.
We have a rule like the following that works for some users, but not for others:
Host_Alias UATAPP = appu711, appu712, appu713, appu714
Runas_Alias WLOGIC = weblogic, blah
%somegroup UATAPP = (WLOGIC) /opt/weblogic/bin/script.sh
Both users are members of somegroup and are running this on the box appu711:
sudo -u weblogic /opt/weblogic/bin/script.sh
UserA:
sudo -l
(weblogic, blah) /opt/weblogic/bin/script.sh
Shows that he is authorized to run the command, but when he tries to run the command:
UserA is not allowed to run sudo on appu711. This incident will be reported.
Syslog shows:
Apr 27 15:31:36 appu711 sudo: [ID 702911 auth.alert] UserA : user NOT authorized on host ; TTY=pts/6 ; PWD=/home/UserA ; USER=weblogic ; COMMAND=/opt/weblogic/bin/script.sh
However, for UserB, the user can execute the same command just fine:
Apr 27 15:31:28 appu711 sudo: [ID 702911 auth.notice] UserB : TTY=pts/2 ; PWD=/home/UserB ; USER=weblogic ; COMMAND=/opt/weblogic/bin/script.sh
The only functional difference between the accounts is the group membership. UserB is a member of additional groups than UserA.
In the code, parse.c, it looks like this is the code that sets the flag to trigger the error UserA sees:
if (pwflag)
pwcheck = (pwflag == -1) ? never : sudo_defs_table[pwflag].sd_un.tuple;
else
pwcheck = 0;
/*
* Assume the worst. If the stack is empty the user was
* not mentioned at all.
*/
if (def_authenticate)
error = VALIDATE_NOT_OK;
else
error = VALIDATE_NOT_OK | FLAG_NOPASS;
if (pwcheck) {
SET(error, FLAG_NO_CHECK);
} else {
SET(error, FLAG_NO_HOST); /* THIS LINE */
if (!top)
SET(error, FLAG_NO_USER);
}
Why would FLAG_NO_HOST be set for some users, but not others? A parser bug in sudo? A bug in the sudoers config file? I can't see a reason that sudo -l would list a command correctly that a user should be able to execute and then deny them execution of that command--unless there is some sort of bug lingering here.
I can provide a larger section of the sudoers file with additional rules for these group members if you like. I'll have to sanitize it first.
Thanks!
-Jason
Jason Axley, CISSP
Sr. Security Engineer
More information about the sudo-users
mailing list