clock riddle

[Gregory Maxwell]

On Tue, Feb 24, 2009 at 10:08 AM, Patrick O'Callaghan
<pocallaghan at gmail.com> wrote:
> On Mon, 2009-02-23 at 15:57 -0700, Michal Jaegermann wrote:
>> Due to a default "auth_self_keep_always" once you allowed yourself
>> such changes modyfing defaults will not remove those authorizations.
>
> I'm not sure what you're saying (I have a very limited knowledge of
> PolicyKit), but it appears to be "once you lower security for the clock
> functions -- using the root password of course -- it stays lowered". Is
> that correct?
>
> If so, in what way is this more serious than, say, removing the root
> password entirely? I'm not trying to be confrontational, it's just that
> so far you haven't really explained your point.

Not using the root password. Using your own user account password.

If the root password were involved, caching it by default would be a poor
practice worthy of repair, but not a vulnerability.  But it is not involved
as far as I can tell. The current settings allow random users to change
the system time without any administrative credentials. It's basically
equivalent to giving clock the suid bit.

The "ask for the users password; then remember it" behaviour is weird.
Should the system ever be doing that? I can see cases where you might want
to prove that requested action is, in fact, on behalf of the user… but if
the authentication is kept that use case is defeated, so I'm not sure what
purpose it serves other than to level people with the mistaken impression
that the root password is required as would be proper.