Package: sudo
Version: 1.6.8p7-1
Severity: normal

Hello,

When running a command, sudo checks for existence of the target
executable and it being an executable file. However, this is done only
under the UID of the runas_pw, not also under its GID. This means that
when the runas user has access to the executable only through its group,
sudo fails to stat() the executable. This is a regression from an older
version - I recently upgraded sudo and encountered the problem.

Consider this setup (id is a copy of /usr/bin/id):
#sudoers:
test2       saytrin=(test1) NOPASSWD: /tmp/test/id
and:
# ls -ld /tmp/test
drwxr-x---  2 root test1 60 Apr  5 12:52 /tmp/test
# ls -l /tmp/test/id
-rwxr-xr-x  1 root root 15992 Apr  5 12:51 /tmp/test/id

This means that the user test1 can enter the directory /tmp/test, since
its group (test1) has access to that dir. However, when running from
test2:

[EMAIL PROTECTED]:~$ sudo -u test1 /tmp/test/id
sudo: /tmp/test/id: command not found

and a strace shows that:
....
getcwd("/tmp", 4096)                    = 5
setreuid32(-1, 0)                       = 0
setuid32(0)                             = 0
setreuid32(-1, 1006)                    = 0
stat64("/tmp/test/id", 0xbffff76c)      = -1 EACCES (Permission denied)
setreuid32(-1, 0)                       = 0
setuid32(0)                             = 0
setregid32(-1, 1007)                    = 0
setreuid32(0, 1007)                     = 0
stat64("/tmp/test/id", 0xbffff76c)      = -1 EACCES (Permission denied)
...

Here 1006 is test1's uid and 1007 test2's uid. As you can see, only uid
changes are done, not also gid. Digging through the sources, I found out
that main() calls init_vars(). Here is the fragment of code, starting at
line 627 of sudo.c, in function init_vars():
    if (ISSET(sudo_mode, MODE_RUN)) {
        /* XXX - default_runas may be modified during parsing of sudoers */
        set_perms(PERM_RUNAS);
        rval = find_path(NewArgv[0], &user_cmnd, user_stat, user_path);
        set_perms(PERM_ROOT);
        if (rval != FOUND) {
        /* Failed as root, try as invoking user. */
        set_perms(PERM_USER);
        rval = find_path(NewArgv[0], &user_cmnd, user_stat, user_path);
        set_perms(PERM_ROOT);
        }
    }
The problem is that the definition of set_perms(PERM_RUNAS) changes only
the uid of process, not its gid also. So I think that here, either:
 * set_perms(PERM_RUNAS) does also a setegid/setgid, but this raises
   another question - should suplementary groups, or
 * init_vars does a set_pers(PERM_RUNAS_WITHGROUPS) (to be implemented;
   I don't think PERM_FULL_RUNAS is appropriate, since it does extra
   stuff), or
 * init_vars allows to skip the path checking

Thanks,
Iustin Pop

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.11.6
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages sudo depends on:
ii  libc6                       2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libpam-modules              0.76-22      Pluggable Authentication Modules f
ii  libpam0g                    0.76-22      Pluggable Authentication Modules l

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to