One thing that I've been thinking of in relation to the previous ticket is that we should consider not just what a user who walks away from their machine is allowing to happen but also a user who runs software that wasn't released by Fedora is subject to. For instance, if a user runs a plugin for firefox and that plugin has malicious code, what effect can that have and to what extent do we want to protect users from it?

FWIW, I have mentioned a firewall just as a random example of a non-PackageKit service, not necessarily implying that firewall is a good candidate.

Another (not the only) model that would make sense, and provide a better security guarantee without being more complicated, not to ask for passwords for local, active, admin users ''that have a screen lock configured''. This would allow us to fairly precisely say "we know that the user is a legitimate administrator unless they have left the machine unattended for more than $number minutes".

Removing meeting keyword for now. Waiting for concrete proposal.

What do you folks say about the following features?

• ability to launch my own VMs using virt-manager without
  authenticating every time.

• start / stop services without authenticating.

Some of these "features" seem to be a bit dangerous to me. e.g. stopping
a critical service.

However, if these abilities are (or can be) restricted to the users in
trusted group(s), then they might be OK-ish.

...

Maybe the first step in solving this problem can be to identify all the relevant use cases.

Lot of these use cases are listed on https://fedoraproject.org/wiki/Privilege_escalation_policy

Replying to [comment:6 halfie]:

Maybe the first step in solving this problem can be to identify all the relevant use cases.

That sounds good. Would you be able to drive this forward? (Asking on behalf of an excitingly unanimous FESCo vote.)

I'm willing to be the proxy driver on this, but I'd like to see a group effort happen via the Fedora Security SIG.

Adding meeting keyword since we punted #1115 forward at the last meeting, and this replaces that.

Replying to [comment:7 mattdm]:

Replying to [comment:6 halfie]:

Maybe the first step in solving this problem can be to identify all the relevant use cases.

That sounds good. Would you be able to drive this forward? (Asking on behalf of an excitingly unanimous FESCo vote.)

I have sent an email to the "devel" mailing list to identify more use cases.

https://lists.fedoraproject.org/pipermail/devel/2013-September/189003.html

As per fesco meeting, removing "meeting" keyword to pull this off the agenda. Please re-add that when/if further fesco action is needed.

AGREED: remove this ticket from meetings, because someone is currently working on it. Now FESCo action at the moment. (+5,-0,0)

It's been five months. Re-adding to the meeting to get an update.

• 1117 Generalize policy about privilege escalation and Administrator

  
  user accounts (sgallagh, 18:43:24)
• The default right now is that things requiring more privilege should
  come to fesco to be decided. (sgallagh, 18:51:39)
• AGREED: Since there is nobody with sufficient interest to
  generalize, and there's nothing really wrong about the current
  status, close the ticket == stop tracking this (+7, 0, -0)
  (sgallagh, 18:53:00)

Hi, as an FYI, we violate this policy in gnome-control-center so that we don't have to prompt admin users for a password when changing the time, hostname, system locale, and system keyboard layout. (We always require a password from non-admin users.)

I like the status quo and would prefer a policy change, because I'm not convinced the extra authentication dialogs make the user much safer. Justification: the attacker must have physical access to your unlocked computer to change any of these without authentication, and if so, he also has access to your home directory, and can read all your private data. For most users, that's probably much worse than the attacker changing e.g. your timezone.

"Another (not the only) model that would make sense, and provide a better security guarantee without being more complicated, not to ask for passwords for local, active, admin users that have a screen lock configured."

Interesting idea. But if you are concerned about attackers accessing your computer while you're gone, you should really enable screen lock: that is much more important. In Workstation, the screen locks after five minutes by default.

I like the status quo and would prefer a policy change, because I'm not convinced the extra authentication dialogs make the user much safer. Justification: the attacker must have physical access to your unlocked computer to change any of these without authentication, and if so, he also has access to your home directory, and can read all your private data. For most users, that's probably much worse than the attacker changing e.g. your timezone.

The fundamental principles of the privilege escalation policy inherently target a multi-user system; it allows any user to be careless about their own data (by setting it to world-readable, having a trivial password, or using any other method) but it should not allow any user to be careless about other users’ use of the system.

I don’t know, perhaps Workstation would like to explicitly target only single-user systems, and the policy to adjust to this (though I would suggest https://fedorahosted.org/fesco/ticket/1115#comment:12 may still apply, and the rise in popularity of tablets might actually ''increase'' the likelihood of a single family computer). We would have to figure out how to do this safely without compromising Server and Cloud deployments, though.

"Another (not the only) model that would make sense, and provide a better security guarantee without being more complicated, not to ask for passwords for local, active, admin users that have a screen lock configured."

Interesting idea. But if you are concerned about attackers accessing your computer while you're gone, you should really enable screen lock: that is much more important.

The idea is that ''if'' you have screen lock, you are not bothered with more prompts. See above about single-user/multi-user systems and carelessness.

I don't think we want to exclusively target single-user systems, no. I guess the difference is that I assume the admin user is... well, the admin user, surely allowed to be careless about others' use of the system (if there are any other users). Unprivileged users should definitely not be allowed to change system-wide settings.

I actually think my previous reading of the policy was wrong. It refers repeatedly to restricting "unprivileged user accounts;" I don't see anything that restricts the actions that may be performed by privileged user accounts. So maybe I'm wrong, actually, and it's fine.