On Wed, 2015-04-01 at 13:37 -0400, Miloslav Trmač wrote: > Hello, > > 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." You could make a case that applies only to spins rather than official products, I suppose. > > The polkit manual is pretty clear that applications should never do > > this: > > > > "Authorization rules are intended for two specific audiences > > That thing is fairly impractical, > https://bugzilla.redhat.com/show_bug.cgi?id=956005 . IMO, _that_ is not as > much a blocker as the escalation policy above. OK, thanks. Well then let's try to resolve https://bugs.freedesktop.org/show_bug.cgi?id=80921 where I've added a comment to answer David Z's request. The other thing that would be nice would be a way to get the real admin group, rather than just guessing that it's wheel. Note that openSUSE also violates this "policy" on an epic level, since they ship a .rules file that overrides every authorization rule. I think that breaks pkla-check-authorization. > 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 premediation). > > 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. 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 used. Michael
