Allow a specific user or group root access without password to /bin/date

Question

I'd like to give a user or group full root access to the /bin/date command, including any manner of arguments as defined in the man pages.

I understand /etc/sudoers expects explicit command definitions, so currently I have the following:

%some_group ALL=(root) NOPASSWD: /bin/date

e.g. I want any user in some_group to be able to run:

sudo /bin/date +%T "12:34:56"

Plus countless other combinations of arguments.

I guess my question is, is there a way to use regex or safe (emphasis on safe!) wildcards to achieve the finer granularity?

UPDATE

I managed to achieve something similar with Cmnd_Alias. Why this doesn't work without is a mystery beyond having time to read further on the inner-workings of sudo and sudoers.

Your syntax wasn't quite accepted, but I managed to achieve what I needed with the following:

Cmnd_Alias DATE=/bin/date
%some_group ALL=(root) NOPASSWD: DATE

This did exactly what I needed as a member of the defined group.

Solution 1

You can use the sudo command to accomplish this. If you add the following rule to your /etc/sudoers file like so:

As root or using sudo from your normal user account:

$ sudo visudo

This will open up the /etc/sudoers file in vi/vim. Once opened, add these lines:

Cmnd_Alias NAMEOFTHIS=/bin/date
ALL ALL=NOPASSWD: NAMEOFTHIS

Where "users" is a unix group that all the users are a member of. You can determine what group users are in with either the groups <username> command or look in the /etc/groups and /etc/passwd files.

If you have a section like this, I'd add the rules above here like so:

## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL

# my extra rules
Cmnd_Alias NAMEOFTHIS=/bin/date
ALL ALL=NOPASSWD: NAMEOFTHIS

Solution 2

If you're on GNU/Linux and feel up to something "new"(sic) pam_cap.so can give particular users CAP_SYS_TIME which should let regular users change the system time without sudo or su. You basically just configure it as a session module for however they're authenticating (ssh or login or whatever), add the user/capabilities you want to /etc/security/capabilities.conf then do a setcap CAP_SYS_TIME+ei /bin/date and you're good to go. pam_cap can't do groups yet, though, so you would have to copy/paste for each user you want to do it.

If you want all system users to be able to change system time, you can forget all the pam_cap stuff, and just do a setcap CAP_SYS_TIME+ep /bin/date which is essentially Capabilities' analog for adding the setuid bit to a binary (similarly, you can't do it on scripts and if you write to the executable file capability flags and setuid/setgid bits are cleared by the kernel).

date is pretty safe to run through sudo (not many ways you can try to exploit such a simple utility except through out-right substitution, but the attacker would have to find a way to write to directories only root has write permissions to) so that's do-able, but capabilities make privilege granting to end-users seem more seamless (they don't have to think "oh I have to sudo on this" they just go do the thing they're trying to do and it works) and restricted (you're ony given them a specific set of elevated privileges). sudo is a setuid-only mechanism (for the time being at least) and can only think in terms of this or that executable, and whatever that file does (whether binary or script you wrote), it can do it with full root privileges, even privileges that have nothing to do with why you gave the user access to the executable.

setuid is an old old old mechanism that it basically on its way out on most GNU/Linux and Unix implementations. Giving full root access is for the birds, why give CAP_SYS_ADMIN or CAP_NET_ADMIN if you're just trying to let the users change system time? Sure I can't think of a way to exploit /bin/date to do something evil, but most exploits are non-intuitive until they're discovered and demonstrated (hopefully the software doesn't contain obvious exploits, I mean).

If you're on *BSD or Solaris, they have the same concept they're just called "Privileges" instead of "capabilities" since "capabilities" was already the name of a security-related mechanism on those platforms (roughly analogous to LxC and/or SELinux, fwiw). The implementation details differ between privileges and Linux capabilities but the base concept is the same (it's also how Solaris 11 implements the "root as role" security model).

Comments

[peterRepeater]

Excellent response and very interesting points. Information Security is a subject of interest to me, so you've given me some points on which to discover some extended reading. Thanks!

[Hauke Laging]

I don't get the sense of the "ALL ALL=NOPASSWD: users" line. What is that supposed to be, a user specification? Quoting from man sudoers: "The basic structure of a user specification is “who where = (as_whom) what”"

[peterRepeater]

Will vote when I have sufficient rep! :)

[peterRepeater]

Will vote when I have sufficient rep! :)

[slm]

@HaukeLaging - the line you're asking about is right out of the sudoers man page on Fedora. It says that anyone can run the commands in the Cmnd_Alias NAMEOFTHIS, without a password. linuxmanpages.net/manpages/fedora12/man5/sudoers.5.html