[sudo-users] Odd sudo behavior: some users can, others cannot

[Axley, Jason]

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