On 11/23/2009 07:01 PM, Gregory Maxwell wrote:
> On Mon, Nov 23, 2009 at 6:43 PM, Jesse Keating <jkeating@xxxxxxxxxxxxxxx> wrote:
>> This is precisely the dialog that has been removed from F12 and is not
>> planned to be returned.
>
> My understanding was that this was removed because collecting the root password
> during a user session is insecure because there could be a sniffer or the dialog
> could be faked.
That reason isn't /quite/ right. One big problem is that if you train a
user to input the root password over and over, what he learns is to type
the root password into a dialog box. The result is that when some
non-privileged application asks for the root password so it can do bad
things with it later, the user will type in the root password, and voila,
a local attack against a user is now a root exploit.
The way around this is role-based privileges, which is what polkit is
implementing - it means that for some actions, the user is automatically
authorized by being assigned a role (for some actions, that is by being a
member of the desktop_admin_r group). For some actions, the user may need
to prove that he's who he says by entering /his/ password, but not the root
password. The user does not thus get trained to enter the root password
into dialog boxes.
The important part here is that there's granularity on the actions - it's not
"assume root access", it's "assume access to start $task that performs $action",
so a) if the fake dialog attack does occur, it's a password with limited
abilities which gets betrayed, and b) the admin is not necessarily giving
free reign to the user in the first place.
The model here is actually pretty good. The policy was clearly not what
it should have been, and documentation/communication of the various
roles and the rollout plan could have been better. Though tbf, on the polkit
side there's plenty of "how this works" documentation that is useful and
thorough; the communication of the roles and associated policy itself,
that is, how PackageKit is using polkit and what admins need to know
to lock a machine down, is what I'm talking about.
> If I understand you correctly you are saying that even if this weakness were
> addressed (e.g. through whatever means make fast user switching secure) that
> the feature would not be re-introduced. Am I misunderstanding?
I don't understand what it is you think fast user switching does. You're just
logged on as a different user. It's just like being logged in with a different
getty on tty2 than on tty1.
--
Peter
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
