>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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1219337 Title: Users can change the clock without authenticating, allowing them to locally exploit sudo. To manage notifications about this bug go to: https://bugs.launchpad.net/cinnamon-desktop/+bug/1219337/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
