On Wed, 2015-04-01 at 13:37 -0400, Miloslav Trmač wrote:
> > We should chat with Miloslav Trmač (mitr) about this. I've added him to
> > CC, hi Miloslav! The goal here is to use polkit to express the rule
> > "local admins can perform the action without entering any password, but
> > non-admin users must enter an admin password."
> Hum. Doesn’t http://fedoraproject.org/wiki/Privilege_escalation_policy
> require authentication at least with the users’ password?
Hm, I don't agree that gnome-control-center is violating that policy.
gnome-control-center allows only privileged (admin) users to change
certain settings without password authentication. That policy applies to
unprivileged users. In particular, this sentence seems to specifically
allow gnome-control-center's behavior:
"In the case of an approved Fedora spin which automatically grants
administrative privileges to the first created user account,
authentication as that user can be considered administrative
authentication; the same applies to any user account subsequently
granted those privileges by the system administrator."
_authentication as that user_ is what is requires.
The other thing that would be nice would be a way to get the real
group, rather than just guessing that it's wheel.
well-defined/stable answer. (It could change from call to call, in pathological cases
depending on whether the second is even/odd ☺, more plausibly it could be pulling from a
centralized configuration system.)
Note that openSUSE also violates this "policy" on an epic
they ship a .rules file that overrides every authorization rule. I think
that breaks pkla-check-authorization.
This is a Fedora policy, so OpenSUSE is not relevant.
> I am very uneasy about blanked auth_if_nonadmin in any
environment that is
> not physically secured (~ 2 different! people watching the computer to
> make sure nobody unauthorized is operating it), including the typical
> open-plan office. Not all physical access is the same; it is much easier
> to lean to a computer and type a single administrative command than to
> otherwise exploit an unlocked computer in the office (rebooting from an
> USB disk will be defeated by disk encryption, downloading and installing a
> keylogger running within the session requires a much larger amount of
> The above-mentioned ”authenticate within the last $five minutes” (or
> perhaps, more precisely, “no period of inactivity longer than $two minutes
> since last authentication”) solution would, I think, work reasonably well,
> and can be implemented as a polkit authentication agent without otherwise
> changing the rules. But at the moment the privilege escalation policy
> stands as it is, and AFAICS requires authentication.
Some places have different security requirements than others. :) I'm
pretty sure the defaults in Workstation should optimize for home users
that have no fear of a physical attacker, except the real risk a thief
might steal the computer.
You mean the Workstation “primarily be aimed at providing a platform for development of
server side and client applications”?
Even for corporate deployments, I'm not
convinced the password prompt provides meaningful security: here you
have a very real risk of corporate spies gaining physical access to your
computer, but they're trying to get your company's secrets from your
home directory or network storage (disaster!), not change your timezone
or look at core dumps. So I think it's safe to waive these password
prompts in many (or perhaps all) cases where auth_admin_keep would be
Perhaps there are good reasons to revisit the policy in some way, but that is not going to
happen in a private conversation between the few of us. (cf. also