[prev in list] [next in list] [prev in thread] [next in thread]
List: sudo-users
Subject: [sudo-users] Odd sudo behavior: some users can, others cannot
From: "Axley, Jason" <jason.axley () wamu ! net>
Date: 2006-04-27 21:26:29
Message-ID: 81BDAEBB3ED1DB4B9A1D799880C93DA4032CDCDC () exmsea017 ! us ! wamu ! net
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic