Bug 450304 - gnome-clock: please consider defaulting to auth_admin in PolicyKit configuration
gnome-clock: please consider defaulting to auth_admin in PolicyKit configuration
Product: Fedora
Classification: Fedora
Component: gnome-panel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
: FutureFeature
: 475672 (view as bug list)
Depends On:
Blocks: F11Target FedoraServerTracker
  Show dependency treegraph
Reported: 2008-06-06 11:35 EDT by Tomas Hoger
Modified: 2009-08-13 14:34 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-08-13 14:34:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2008-06-06 11:35:26 EDT
PolicyKit configuration for multiple org.gnome.clockapplet.mechanism.* actions
currently defaults to auth_self_keep_always, allowing any user to set time and
timezone after authentication using his/her own password.

This may be a reasonable default for single-user systems, however it may not be
a safe or expected default in multi-user system with not all local users being
system administrators.  For single-user systems, the user is usually also a
system administrator and knows the root password, so requirement of an admin
authentication may not be as much of the issue.

Please consider changing default to auth_admin and let system administrator
grant additional privileges to some or all users as required on the specific system.
Comment 1 Ray Strode [halfline] 2008-10-15 13:50:11 EDT
is the concern about log file mucking?
Comment 2 Tomas Hoger 2008-10-20 06:52:56 EDT
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 ;).
Comment 3 Ray Strode [halfline] 2008-10-22 14:07:35 EDT
I'm going to punt this decision to David, since he seems better suited.
Comment 4 Ray Strode [halfline] 2008-12-10 12:46:33 EST
*** Bug 475672 has been marked as a duplicate of this bug. ***
Comment 5 Michal Jaegermann 2009-02-15 13:24:21 EST
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".
Comment 6 Adam Williamson 2009-03-17 13:10:40 EDT
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
Comment 7 David Zeuthen 2009-03-17 13:37:13 EDT
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.
Comment 8 Tomas Mraz 2009-03-17 13:50:38 EDT
Perhaps we should also remove the dialog for user password in the gdm for the console users then - given the same logic.

Or not?
Comment 9 Colin Walters 2009-03-17 14:17:48 EDT
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.
Comment 10 David Zeuthen 2009-03-17 14:19:50 EDT
(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).
Comment 11 Adam Williamson 2009-03-17 15:10:00 EDT
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
Comment 12 Michal Jaegermann 2009-03-17 22:29:50 EDT
> 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.
Comment 13 Miloslav Trmač 2009-03-19 14:38:09 EDT
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.
Comment 14 Peter Glassenbury 2009-03-19 17:13:55 EDT
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
Comment 15 Colin Walters 2009-03-20 10:50:39 EDT
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.
Comment 16 Chris Adams 2009-03-26 20:01:45 EDT
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"/>

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

"Secure by default" shouldn't be just that other guy's mantra.
Comment 17 Kostas Georgiou 2009-03-31 06:43:06 EDT
As someone that manages machines with multiple users I also see this as a big problem.
Comment 18 Chris Adams 2009-08-12 18:36:57 EDT
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.
Comment 19 Matthias Clasen 2009-08-13 14:34:19 EDT
This will be fixed in gnome-panel-2.27.4-8.fc12

Note You need to log in before you can comment on or make changes to this bug.