> 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."
_authentication as that user_ is what is requires. > 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. Unfortunately, with JavaScript in the picture, this question does not have a 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 level, since > 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 > > 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. 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 > used. 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 https://fedorahosted.org/fesco/ticket/1117 ) Mirek
