On Thu, 2009-06-18 at 11:02 -0400, Matthias Clasen wrote: > On Thu, 2009-06-18 at 11:58 +0200, Nils Philippsen wrote: > > > > > As it is, malware need only sit in the background and wait for e.g. a > > PolicyKit-enabled user manager to acquire the authorization for user > > creation to be able to easily install a backdoor account. > > Nils, this is somewhat inaccurate (or to put it more strongly, it is > misinformation...). I'm glad that you say that (and for your explanation below) -- I read the documentation for the new polkit version but didn't find that information. I have some questions below where I'd appreciate a bit of clarification though. > First of all, unless the policy specifies _keep, you can only do things > once after getting the authorization. With the hypothetical user manager app, would this mean I'd have to authenticate once in the program so that I could add a number of users and re-authenticate if I ran the program for a second time, or would this be only valid for one user added? > And even with _keep, it is not true that PolicyKit "automatically > authorizes all other applications running on the same desktop". > > The retained authorization is only valid for the subject that obtained > it, which will typically be a process (identified by process id and > start time) or a canonical bus name. And your malware does not have > either. So authorizations wouldn't carry over if I ran an app for the second time if I specify _keep? > Here is a little demo to show how this works: > > The org.freedesktop.policykit.example.pkexec.run-frobnicate action has > auth_self_keep in its policy. > > Now if you try running pkexec pk-example-frobnicate in a terminal, > PolicyKit retains the authorization that you obtain by entering your > password, and the subject it associates it with is the parent process of > pkexec, ie the shell you are running this in. Repeating the pkexec call > in the same shell will not ask you for your password again. But if you > open a new terminal or tab and repeat it there, you will get asked > again. So for my example above, an authorization isn't "attached to" the user manager app process, but its parent (the panel)? Thanks, Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
