3

Consider this sudo config for two users:

mary ALL = (ALL) NOPASSWD: /bin/ls, /bin/cat
bob ALL = (ALL) PASSWD: /bin/sort

Now, when user mary executes any command not in the list she has to authenticate every time.

$ sudo sort
[sudo] password for mary: 
Sorry, user mary is not allowed to execute '/bin/sort' as root on eagle.

If mary were to again try to execute some other disallowed command, she would be asked for the password. However, this is not true for bob, who gets asked only once and till the timeout period. Why does mary have to authenticate again and again when she has already been able to correctly supply her password in the recent past?

I did find at least one similar question but the answers/comments don't seem to clarify enough. There the issue was with entering password on sudo -v and here it is about commands not allowed by the config. Yes, the interaction of rules with PASSWD and NOPASSWD tags is a similarity.

Community
  • 1
pdp
  • 707
  • 7
  • 8

2 Answers2

3

In short, it's a security thing. You have said, that mary can run certain commands without the supplying of a password. That fails, then the "default action" is taken. Go and ask the password, then log the failed attempt.

With out getting horridly technical, it's the separation between authentication and authorization.

  1. is this mary trying to run a command - check that by asking for nothing if it is ls or cat, check that the default way if something else.
  2. Can't find a way to authorize mary. Fake it. -- Authentication failed, there is no way to authenticate mary when trying to run foo

as apposed to

  1. is this bob, no matter what check that with a password
  2. it is bob, is bob allowed to run foo
  3. nope, bob can't run foo -- Authentication via password was ok, cache that. But fail to authorize the command.

Basically, your saying that

  • with a password bob can run sort,
  • with out a password mary can run ls
  • if mary tries to run foo, then she can not authenticate (there is no method)
  • if bob tries to run foo, he can authenticate but is not authorized.

The reason mary gets prompted for a password is the same reason user bar would get prompted. So that a user could not tell, by running a dictionary of common commands against sudo to determine what is an isn't allowed by checking the output of the command.

Or another way of looking at it. Because the variable of "what can be run when authenticating with a password" is null for mary, then she can never authenticate with a password. Because the variable of "what can be run when authenticating with a password" is not null for bob, then he can authenticate with a password, but is not authorized to run some things.

coteyr
  • 4,280
  • 16
  • 24
  • Thanks for the response. However, it does not explain why bob's authentication is treated differently from that of mary when both are entering password for this purpose. Also, mary can run `sudo -l` with password and easily know the set of commands she is allowed to run. – pdp Aug 28 '15 at 07:23
  • It does. You said bob can run commands with a password, but that marry can not. So, "Can bob run something with a password? Yes. Cache Authenticaion, move to authorization. " v.s. "Can marry run something with a password? No. Is this one of her allowed commands? No. Fail everything." The alternative would be that marry could run ls, then have elevated permissions for every other [listed] command. The "path" for a user not using a password is different then one that is using a password. – coteyr Aug 28 '15 at 07:34
  • 1
    Another way to put it, is that because mary is never authenticating, the part that caches the authentication is never being executed. – coteyr Aug 28 '15 at 07:35
1

I downloaded the sudo SRPM from here, compiled and ran it from inside gdb to have a closer understanding. This tip on debugging setuid root programs was invaluable.

The thing is that sudo creates/updates the timestamp file (resides inside /var/db/sudo/<user>) only when the user is authorized to run the command and has been authenticated as well. Authentication involves keying of password and/or calling of a PAM module. Authorization is about validating if the user is allowed to run the given command. Note that there are two conditions here.

The implication of the NOPASSWD tag is to avoid authentication for the listed commands. So, if a user (e.g. mary) does not have any PASSWD entry in config then for a command that runs successfully, he not required to authenticate. No timestamp file is created because the user was not authenticated. Otherwise, if such a user runs a command that he is not authorized then authentication does take place. But again the file does not get created since he failed the authorization.

It follows that for a user with a PASSWD entry, the timestamp file gets created only when he has successfully run at least one command from such a list. The file does not get created when trying to run other commands that are unauthorized and sudo will try to authenticate each time.

Community
  • 1
pdp
  • 707
  • 7
  • 8