Geek Answers Handbook

Sudo command on macOS sierra does not honor timestamp_timeout

After switching to MacOS Sierra (10.12), my sudo works differently. See the following test case:

 # Run in terminal pane #1: (should prompt for password) sudo -v # Run in terminal pane #2: (should NOT prompt for password) sudo -v

The above works as expected in earlier versions of OS X. However, in Sierra, the second command again asks for the password. It does not request a password in the same terminal panel. This seems to be happening only to the root ; on all OS versions, including Sierra, the following is expected:

 # Run in terminal pane #1: (prompts for password) sudo -v -u "$USER" # Run in terminal pane #2: (does not prompt for password) sudo -v -u "$USER"

In /ect/sudoers value of timestamp_timeout not set to 0 . I briefly looked through the change log from 1.7 to 1.8 , but could not find anything significant other than mentioning the policy plugin for Sierra when running sudo -V .

Can someone help me figure out what has changed? I have a script that relies on the sudo timeout value for keepalive, and on Sierra it constantly asks for a password, as it seems to no longer use the timestamp for the root .

+5
source share
2 answers

After a ton of searching and comparing sudo configurations on older OS versions before Sierra ( sudo su; sudo -V ) it seems that Sierra allows tty_tickets to still cause the problems mentioned above by default. As far as I can tell, this was an undocumented change. To fix it, add the following to the /etc/sudoers file: sudo visudo ,

 Defaults !tty_tickets
+10
source

TL; DR; BAD IDEA. This is the old behavior, while the sudo option is used by default for the NO OTHER UNIX-y OS I've ever encountered. The reason is that it is trivial to use and when using malicious code does this, it will have full control over your system.

The original very long rant-y message, correctly labeled blahdiblah:

Lol that's funny. I came here from Google because I could not remember how to change the previous behavior to this new, correct one (used by all other UNIX-y OS there). I did not even notice that my new Sierra Mack was now behaving correctly.

I already wrote on the Mac forums about this previous behavior, which is a gaping security hole. I even presented a three-line proof of the concept of the script, which would just sit (like a regular user), waiting for the sudo event to appear anywhere , and then instantly get root access to the system. I was booed from the threads by fans, after which I was forbidden to call a lie. Apple seems to be listening. Good job, this time, Cupertino. Bad BAD idea to try to revert

For reference, here is three-line. It does nothing malignant, it simply adds a dummy file to the root of the file system after receiving sudo. Run it in a script (or just paste it somewhere that does not already have sudo), or execute sudo in another terminal application / window or an application that uses sudo (e.g. TrueCrypt / VeraCrypt or similar), and then look at its operation .

 tail -f -n 0 /var/log/system.log | grep -m 1 -E 'sudo\[[0-9]+\]:\s+'$USER echo "Gonna play around with root privs ..." sudo touch /kilroy-was-here
0
source

More articles:


All Articles