Bug 450304

is the concern about log file mucking?

Rather more general - setting system time has traditionally been a system administrator privilege, that may still be relied on in multi-user setups, or in setups where the box is being administered by someone else as usual console user.  Thinking in terms of Fedora being RHEL upstream, this may not be the best default for RHEL for example.

I believe this setting was introduced as a convenience for home users.  As noted in the description, for those users, it should not matter much if it's user or root password having to be entered once (assuming user does not change recommended default to keep authorization forever).  Actually, no password at all may be as good default for home usage as the current one, imo (if you forget to lock your computer before going to toilette, there are lot worse things your nasty colleagues / room-mates can do to you than mess your time settings ;).

I'm going to punt this decision to David, since he seems better suited.

*** Bug 475672 has been marked as a duplicate of this bug. ***

The current default policies for clockapplet are totally screwed.  They would be great with changes affecting only what is displayed in a desktop session.  Unfortunately changes are system-wide and as things stand right now everybody with login can grant themselves perpetual rights to mess up with time-zone changes, system clock and hardware clock.  The next time they will be not even asked for a password.  A sysadmin may change those policy defaults but first s/he has to catch up with what is going on.

NTP goes to great lengths not to jump clock values and here everybody got a monkey wrench to corrupt such vital system setting at will.  Instead of "low" this should be classified "security".

Changing the classification of this bug (although most people pay it little heed...) and adding it as an F11 blocker. This has clear security implications on a proper multi-user system; someone with ill intent can mess with a lot of stuff by screwing with the system date and time.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Sorry but all these "security" concerns are completely bullshit since this scenario only applies to users logged in at the _local_ console. By design, the OS trusts users at the local console. The user might as well just use an axe to destroy the machine or boot into single user mode and do whatever the hell he wants.

Users with more sophisticated setups (where the local console is physically separate from the machine, e.g. kiosk setups) need to customize the defaults / authorizations / defaults accordingly. Just like these users need to set a password on the BIOS, the bootloader and so on.

I think this bug should just be closed WONTFIX.

Perhaps we should also remove the dialog for user password in the gdm for the console users then - given the same logic.

Or not?

I don't understand why we're prompting for the user password at all - this one strikes me as falling into the same bucket as shutdown/reboot.

tmraz: I know you're being sarcastic, but I think what we should be keeping in mind here is the intended threat model.  My suggestion for that threat model (in the context of home/self-managed users) is that the threat is a semi-knowledgable person with a minute or two of access to the computer.  Say I have a guest over and I go to the bathroom.  The password protection from screensaver/gdm works fine there.

Does it really make sense to call local users changing the time a threat, given this model?  I don't think so - the integrity and confidentiality of /home and the system is going to be preserved.

(In reply to comment #8)
> Perhaps we should also remove the dialog for user password in the gdm for the
> console users then - given the same logic.
> 
> Or not?  

No, this is a terrible default. With this any unauthorized entity can walk up to your machine and pretend to be you. That would be a security hole. 

Of course, if your machine is in a secure location you can do this... hence why things like autologin actually exists (though it is more widely used on non-Linux operating systems). But we cannot assume this is the case hence why it's not the default.

Frankly, the default for the clock should be to never prompt for authentication if you are logged in at the local console. Password dialogs like these are mostly security theater; they only slow down users. Snake-oil, really.

Don't get me wrong, for some situations we _need_ to be careful and check the user really is the user (by making him authenticate as himself) or that the user really is an administrator (by making him authenticate as root) before carrying out an action. But these cases are not very common. One example is installing unsigned/untrusted software (which could install a backdoor). Another is to make a modem call to a untrusted telephone number (to avoid the machine calling some 1-900 number at $50 / minute).

It seems like the one thing everyone agrees on is that the current default is a nonsense - it's requiring an authentication which means almost nothing.

So either we decide it doesn't need to be protected at all and default to allowing it, or we protect it properly. But a one-time-then-remembered-user-password entry is clearly about the worst possible choice :)

so can it get changed one way or another?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

> I believe this setting was introduced as a convenience for home users.

So maybe there should be some "bowdlerized" version of a distro? Let's call it "Fedora Home".  I guess that for a "convenience" it should run everything under root.  And another one with sane defaults.

In case you did not notice "one user per machine at home" is very far from the only model of use for Fedora; besides exactly "home users" should not be given too much rope to hang themselves.

Consider an university computer lab.

The thread of an user using an axe, or yanking the power cord, is mitigated by the people watching the lab.  The clock change (which can skew access logs, which are quite important in a public lab) can't be mitigated by watching users, the system needs to prevent this action.

As a runner of university labs, this is a serious security concern. We depend on the times being correct and run our own stratum 1 server to make it so. If you are looking at keeping the hole for home users, could the release notes include 
a list of this and any other security holes that need to be configured for normal users. (caused a bit of a panic there to make sure it wasn't in the F10 we are running) Cheers

The default CD download is going to be oriented towards "home" use precisely because we can't assume there's a system administrator to change the security policy so they can reboot the machine, set the system clock, etc.

I would be fine with making the RPM packages be very "traditional Unix" and having the desktop kickstart flip settings to be more "home" use, but if we're going down that route we need to be explicit about it.

The time setting ability (without the snakeoil prompt) is definitely desirable for the home desktop and I would like to see it in one place or another, be that the RPM config or the kickstart.

If "console user can do anything" is the target, why set a root password that is then required for just about all other system-level maintenance?

Even home systems can have multiple users (see the whole fast-user-switching work for example), and having one user change the clock out from under another can be confusing at best.  Emails will have invalid timestamps, notifications won't happen, etc.

I think the packages should ship with a default that is secure everywhere (following a few decades of Unix sysadmin expected behavior), and the if the desktop spin wants a looser default, it could insert:

    <match action="org.gnome.clockapplet.mechanism.*">
        <return result="yes"/>
    </match>

(or similar) in /etc/PolicyKit/PolicyKit.conf if desired.

"Secure by default" shouldn't be just that other guy's mantra.

As someone that manages machines with multiple users I also see this as a big problem.

Is there going to be any update on this?  As in comment 11, it appears just about everybody thinks the current default setting is wrong, but that setting went into Fedora 11 and it appears it is still in rawhide as Fedora 12 approaches.

This will be fixed in gnome-panel-2.27.4-8.fc12