Red Hat Bugzilla – Bug 439532
System update from non privledged account
Last modified: 2008-03-28 21:29:06 EDT
Description of problem: Let me write some activities that I did, and then YOU decide if I am dreaming or stupid about reporting this SECURITY PROBLEM. 1) Power on computer and boot desktop system. 2) Log onto root, 3) Initiate software update 4) Copy xorg.conf to desktop in preparation of collecting data for response to another bug 5) Mouse locks up, with strange cursor symbol during update. 6) I tried to get out of it. In the meantime, software updates are being downloaded. 7) I did the obvious CTL-ALT-BACKSPACE, Logon Prompt appeared. 9) Logged onto insecure account -- regular user (my account) 10) Clicked on icon (brown star) to initiate a system update. 11) NO PASSWORD PROMPT WAS ISSUED. IT JUST WENT INTO THE UPDATE MODE. AND YES, UPDATES COMPLETED COMPLETELY. IS THIS A NEW FEATURE? Version-Release number of selected component (if applicable): Mother Board intel d945gnt. RAM 3.5gigs, Hard disk 330gig Video -- Integrated Driver -- Intel How reproducible: This occurred once. I am not dreaming. Does it mean that if I start a large update (many files), that I can logout (via ctl-alt-backspace) and I can log in as a regular user and start the update, without having to present a password? Steps to Reproduce: 1. Read Introduction (above) 2. 3. Actual results: System was updated Expected results: I should have been prompted for root password. Additional info: The gnome "Star" that shows I am running with root privileges was not presented. Selinux is in permissive mode, as some system updates would not take place otherwise. I am happy it is Rawhide, and not Fedora8. I will try the same with 8, now that my curiosity is raised.
Leslie, because packagekitd is a system service, it continues to run when you log out or fast user switch. This is a good thing, as it prevents nuking your rpmdb just by doing ctrl-alt-backspace. When you logged in to your user account, the update system was still running in the background. What you probably want to try to convince youself, is wait until the next lot of rawhide updates. In your _user_ session, try to update the system and you will be prompted for the root password. The fact that you authorised the action in one session means that it's valid in all local sessions. Checkout polkit-gnome-authorization and you'll see the number and type of permissions you can set. I don't think the mouse locking up is due to the system update, if the packages are just being downloaded then there is no action on the filesystem - we can just blame Xorg or the kernel for that. Richard.
Hi Richard. What started all the research in this area was some other problems with X11. I cannot force X to recreate the xorg.conf, and it causes a loss of mouse left-or-right button click. But, here is a question that you may want to answer off-line.. If in userid1 I start the update and then ctl-alt-backspace and log as user2, with the update/download still going, will I have system priviledges in user2 because the x minutes given user1 did not elapse. It shouldn't, but this is newer code, and to support your reply, in Fedora8, there was no problem of this type.
>will I have system priviledges in user2 because the x minutes given user1 did not elapse Nope, you don't get system priviledges when you do the update, you only give permission to the dameon to do one sort of action. In this way the policy is fine-grained, and is not exploitable. You might want to checkout http://www.packagekit.org and http://people.freedesktop.org/~hughsient/public/introduction-to-packagekit.pdf as it explains things in more detail.