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.