>This allows administrative users travelling with laptops to change the timezone without getting an authentication prompt.
Why is saving the traveling admin from typing their password a couple of times a day worth compromising security for everyone else? No, seriously. Why? >Your attack vector assumes that an administrative user is going to leave an >open session unattended. Yes, my assumption is that users will forget to lock their machines, because it happens all the time. This is especially true if it's a personal machine, and they are the ONLY user. >If that is the case, there are a whole slew of attacks that are possible, and >don't require changing the date. For example, creating scripts in ~/bin that >are higher in the path then system binaries. Even if that number is high, that's no excuse. Is your stance really "Well, they could compromise security 100 ways, so what's one more?" Plus, how many of those attacks require 0 external resources, and creating 0 additional files on the system, and would leave little trace beyond a hiccup in the time/date? >Since your local security policy is different than what is shipped in a >general purpose operating system... Wanting a slightly more secure system is more of an edge case than changing the time zone repeatedly? REALLY? Does Windows 8 count as general purpose to you? It requires escalation to change the date and time. Maybe their escalation system isn't very good, but it's still better than blithely letting admins change the system time without so much as a prompt. Also, their security system doesn't rely on file timestamps, so it's less likely to grant someone root access. > 1- Requiring your administrative users to lock their workstation when they > are left unattended. People make mistakes. Are you telling me you've NEVER forgotten to lock your workstation? You've NEVER seen another admin forget to lock theirs? > 2- Requiring your administrative users to use "sudo -k" to forcibly > invalidate cached credentials. That only works on a per pty/tty basis on ubuntu. It only "invalidates" one of the sessions, and it "invalidates" it by changing the timestamp to a date to Dec. 31, 1969 or Jan. 1, 1970. You could try "sudo -K", which deletes the file, but again only on a per pty/tty basis. > 3- Removing the policykit-desktop-privileges package, or overriding the > policy with a local one. Oh good, more administrative work, all to save typing a password! Pity about all the users who don't know what policykit-desktop-privileges is or does though... > 4- Disabling ntp, or setting up ntp authentication. Disabling ntp wouldn't help, since the whole point is that the user can change the time to anything manually anyhow. > 5- Setting a firmware password on local machines. This doesn't help if they walked away and forgot to lock their machines. I especially love how #2 requires the user to remember to execute a command before they close their terminal, and adds an extra 7 keystrokes PER TTY/PTY. All this to save a hypothetical traveling admin from having to type his password once when he moves to a different timezone. If they want to save themselves a few keystrokes to change the timezone, let /them/ change policy kit. Don't stick every unsuspecting user with a security hole. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-control-center in Ubuntu. https://bugs.launchpad.net/bugs/1219337 Title: Users can change the clock without authenticating, allowing them to locally exploit sudo. Status in Cinnamon: New Status in Unity: Invalid Status in “gnome-control-center” package in Ubuntu: Opinion Bug description: Under unity and cinnamon, it is possible for a user to turn off network-syncronized time and then change the time on the system. It is also possible to "cat /var/log/auth.log" and find the last time a user authenticated with sudo, along with which pty they used. If a user had used a terminal and successfully authenticated with sudo anytime in the past, and left the sudo file in "/var/lib/sudo/<username>/", a malicious user could walk up to an unlocked, logged in machine and gain sudo without knowing the password for the computer. To do this, a user would only need to launch a few terminals, figure out which pty they were on via "tty", find the an instance in /var/log/auth.log where sudo was used on that PTY, and set the clock to that time. Once this is done, they can run (for example) "sudo -s" and have a full access terminal. 1) This has been observed on Ubuntu 13.04, and may work on other versions. 2) This may have an effect on various window managers, but I confirmed it on Unity and Cinnamon 3) I expected to have to authenticate when I changed the time and date, as I do on Gnome and KDE. I also expected to be denied permission to auth.log 4) I was able to change the system time to whatever I wanted, and view auth.log. This was sufficient to access sudo without having to type my password. Note: This bug also affects any version of OS X, though the mechanism is different. Some versions don't require you to authenticate to change the time through the GUI, but some do. No version I've seen requires authentication to use the "systemsetup" command, which can alter the time from the command line. This may be an overall bug in sudo. Why can I bypass security by changing the time?! To manage notifications about this bug go to: https://bugs.launchpad.net/cinnamon-desktop/+bug/1219337/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
