On 13-09-04 10:19 AM, Mark Smith wrote: >> 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?
It only compromises security for people who use sudo on their workstation, and don't add the -k flag to the command line when they do. I suspect there are more users who travel with their laptops than there are people who use sudo on them. > > >> 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 you can't rely on admins to properly lock their session, you can't rely on them to not leave a console open with sudo rights either. At some point a minimum is required. Locking their console, or using sudo with -k is the minimum. > > >> 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? I'm saying preventing the admin user from modifying the system clock is security theatre if the system is configured to use ntp, or doesn't prevent access to changing the clock in the system firmware. Even if the admin user needs a password to change the clock, anyone can step up to the workstation and plug in a network cable to a fake ntp server. If you want to be able to trust the system time, you need to harden a lot more than simply requiring a password prompt. > > >> 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. There's a fine balance between security and usability, and not everyone is comfortable with the same level of security. As I've mentioned before, it is trivial to modify the defaults to achieve the level of security that is appropriate for your environment. > > >> 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? Yes, this happens, and is quite unfortunate. What I'm saying is being able to change the system clock is only one of a whole series of possible attacks if the session is left unattended. > >> 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. Sudo considers cached credential files with epoch timestamps to be invalid, even if you do set the clock to epoch. (Unless you're vulnerable to CVE-2013-1775). Adding -k to your sudo commands will prevent caching. > > >> 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. Disabling ntp is a required part of the process if you don't want an attacker to be able to alter the system clock. > > >> 5- Setting a firmware password on local machines. > > This doesn't help if they walked away and forgot to lock their machines. Again, it is a required part of the process if you don't want an attacker to simply reboot and change the clock in the firmware. > > > 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 just need to add "-k" to every sudo command. You can simply create an alias for sudo if you keep forgetting. -- 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