[sudo-users] fuzzy command acceptance?

[Woodward, Andrew]

So I've cleaned up my example and have found a specific issue. The sudoers
configuration, from files or LDAP doesn't like to accept additional
arguments if one is specified. The only way I've found to exclude this
behavior is to add a * to the end of the last argument. This however makes
me feel dirty.

Is this expected? Should I be worried about adding the wildcard?

Impacted versions:
Sudo version 1.6.9p17 -el5
Sudo version 1.7.4p5 -gentoo
Sudo version 1.7.5 -el4
Sudo version 1.7.6 -el4
Sudo version 1.7.6p1 - el5
--
Sudo version 1.8.1p1 -el5
Sudoers policy plugin version 1.8.1p1
Sudoers file grammar version 40
Sudoers I/O plugin version 1.8.1p1
--

access_user at aw-linux ~ $ sh test_sudo.sh
--test script--
#!/bin/bash

echo "--test script--"
cat $0
echo "--"
sudo -ll
echo "contents of test_args.sh"
cat /nfs/shared/general/sudo/test_args.sh
echo "--"
echo "ls of /nfs/shared/general/sudo"
ls -la /nfs/shared/general/sudo/test_args*
echo "--"
while read cmd; do
    echo "calling: $cmd"
    $cmd
    echo ""
done <<EOF
/nfs/shared/general/sudo/test_args.sh asdf 123 aa
sudo /nfs/shared/general/sudo/test_args.sh arga
sudo /nfs/shared/general/sudo/test_args.sh arga 1
sudo /nfs/shared/general/sudo/test_args.sh argb
sudo /nfs/shared/general/sudo/test_args.sh argb 1
sudo /nfs/shared/general/sudo/test_args2.sh arga
sudo /nfs/shared/general/sudo/test_args2.sh arga 1
sudo /nfs/shared/general/sudo/test_args3.sh arga
sudo /nfs/shared/general/sudo/test_args3.sh arga 1
sudo /nfs/shared/general/sudo/test_args4.sh arga
sudo /nfs/shared/general/sudo/test_args4.sh arga 1
EOF


--
Matching Defaults entries for access_user on this host:
    env_keep+=HOME, !authenticate, !requiretty

User access_user may run the following commands on this host:

Sudoers entry:
    RunAsUsers: root
    Commands:
        NOPASSWD: /nfs/shared/general/sudo/test_args3.sh
    RunAsUsers: root
    Commands:
        /nfs/shared/general/sudo/test_args4.sh arga

LDAP Role: test_args
    RunAsUsers: root
    Options: !authenticate
    Commands:
        /nfs/shared/general/sudo/test_args.sh arga
        /nfs/shared/general/sudo/test_args.sh argb*
        /nfs/shared/general/sudo/test_args2.sh
contents of test_args.sh
#!/bin/bash

echo "Args: $#"; echo "$@"
--
ls of /nfs/shared/general/sudo
-rwxr-xr-x 4 andreww Corp_User 40 May  2 15:36
/nfs/shared/general/sudo/test_args.sh
-rwxr-xr-x 1 andreww Corp_User 39 May  2 15:22
/nfs/shared/general/sudo/test_args.sh~
-rwxr-xr-x 4 andreww Corp_User 40 May  2 15:36
/nfs/shared/general/sudo/test_args2.sh
-rwxr-xr-x 4 andreww Corp_User 40 May  2 15:36
/nfs/shared/general/sudo/test_args3.sh
-rwxr-xr-x 4 andreww Corp_User 40 May  2 15:36
/nfs/shared/general/sudo/test_args4.sh
--
calling: /nfs/shared/general/sudo/test_args.sh asdf 123 aa
Args: 3
asdf 123 aa

calling: sudo /nfs/shared/general/sudo/test_args.sh arga
Args: 1
arga

calling: sudo /nfs/shared/general/sudo/test_args.sh arga 1
Sorry, user access_user is not allowed to execute
'/nfs/shared/general/sudo/test_args.sh arga 1' as root on aw-linux. .

calling: sudo /nfs/shared/general/sudo/test_args.sh argb
Args: 1
argb

calling: sudo /nfs/shared/general/sudo/test_args.sh argb 1
Args: 2
argb 1

calling: sudo /nfs/shared/general/sudo/test_args2.sh arga
Args: 1
arga

calling: sudo /nfs/shared/general/sudo/test_args2.sh arga 1
Args: 2
arga 1

calling: sudo /nfs/shared/general/sudo/test_args3.sh arga
Args: 1
arga

calling: sudo /nfs/shared/general/sudo/test_args3.sh arga 1
Args: 2
arga 1

calling: sudo /nfs/shared/general/sudo/test_args4.sh arga
Args: 1
arga

calling: sudo /nfs/shared/general/sudo/test_args4.sh arga 1
Sorry, user access_user is not allowed to execute
'/nfs/shared/general/sudo/test_args4.sh arga 1' as root on aw-linux. .

-

Andrew Woodward


-----Original Message-----
From: sudo-users-bounces at courtesan.com
[mailto:sudo-users-bounces at courtesan.com] On Behalf Of Woodward, Andrew
Sent: Friday, April 08, 2011 4:26 PM
To: Todd C. Miller
Cc: sudo-users at sudo.ws
Subject: Re: [sudo-users] fuzzy command acceptance?

That's what I thought. /bin/su hasn't been caring for the parameter order,
but instead I'm getting asked for my password by sudo instead of the command
running as expected with !authenticate or given an error depending on the
host.

(root) NOPASSWD: /bin/su oracle
$ sudo su oracle -
Sorry, user ... is not allowed to execute '/bin/su oracle -' as root on ....
$ sudo -V
Sudo version 1.7.4p4

On another host (sudoers is configured by LDAP BTW) $ sudo su oracle -
Password:
Sorry, try again.
Password:
sudo: 1 incorrect password attempt
$ sudo -V
Sudo version 1.6.9p17 

On yet another host:
$ sudo -u stacyy sudo su oracle -
Sorry, user ... is not allowed to execute '/bin/su oracle -' as root on ....
$ sudo -V
Sudo version 1.7.5

Andrew Woodward

-----Original Message-----
From: Todd C. Miller [mailto:Todd.Miller at courtesan.com]
Sent: Thursday, April 07, 2011 8:19 AM
To: Woodward, Andrew
Cc: sudo-users at sudo.ws
Subject: Re: [sudo-users] fuzzy command acceptance?

On Wed, 06 Apr 2011 17:49:20 PDT, "Woodward, Andrew" wrote:

> I thought this was working but might have been my imagination
> 
> sudoCommand = "/bin/su mysqladmin"
> 
> user types "sudo su mysqladmin -"
> 
> I was expecting that to pass as OK, is there an option to allow this 
> short of adding every permutation of the command, or do I have to add 
> the * wildcard to the end?

The rule is that if there are any command line arguments specified in the
sudoers file they need to match what is given by the user.
So, for something like:

    user host = /bin/su

The user would be able to run su, su -, su - mysqladmin, etc because no
arguments were specified.  You may want something like:

    user host = /bin/su mysqladmin, /bin/su - mysqladmin

Note that the '-' is an argument to su and should come before the user.
It's possible you are using a version of su that doesn't care about the
order, though (GNU getopt usually allows flags to be interspersed with other
arguments).

You can also use wildcards like '*', '?', as well as ranges.

 - todd