Re: how to disable PolicyKit?
On Saturday 31 October 2009 23:42:49 Oron Peled wrote: You can try wicd, I tested it under Debian and it was pretty good. I don't know how it will break Fedroa by killing NetworkManager and installing wicd What does it have to do with the subject? We discussed PolicyKit, integration with NetworkManager, lack of good command line integration and how bad is running big program stacks (GUI) as suid programs: 1. wicd is a GUI program (it uses GTK). wicd is a network manager replacement. It works (more or less) the same way NM works: with a deaomon which does the lower level operations, and several GUIs (a GTK version, and a ncurses version). I don't want to change the subject, as Im afraid to steer the debate from the original problem (as you mentioned). I am just pointing that for the NM problem, there is another solution which tries to solve more or less the same problem. It's just different. You know, GTK vs. Qt argument. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: how to disable PolicyKit?
On Sat, Oct 31, 2009 at 11:42:49PM +0200, Oron Peled wrote: On Saturday, 31 בOctober 2009 16:40:47 Diego Iastrubni wrote: On Friday 30 October 2009 01:40:07 Oron Peled wrote: I rather hate NetworkManager, too ;-). However, from the system point of view, I'd naively expect hal, udev, dbus, network, etc. to work without a policy kit developed by GUI people (I understand it comes from Gnome). Please try to cut the lines better next time. It looks like I said the above paragraph, while in reality it was Oleg... However, you are correct that it's easy to see its GNOME origins. There is no command line client. This is not because the design is bad or architectural limitations --- nobody bothered writing one yet. You can try wicd, I tested it under Debian and it was pretty good. I don't know how it will break Fedroa by killing NetworkManager and installing wicd What does it have to do with the subject? We discussed PolicyKit, integration with NetworkManager, lack of good command line integration and how bad is running big program stacks (GUI) as suid programs: 1. wicd is a GUI program (it uses GTK). wicd does not rely on the gnome keyring and hence needs no GUI to run. 2. Like many similar older programs, there's no NetworkManager integration. 3. Therefore they all need to run as root (via suid/sudo/kdesu/etc) Like WhatEverCapitalKit, wicd's client connects with the daemon through dbus and does not require sudo. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best ICQ# 16849754 || friend ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: how to disable PolicyKit?
On Friday 30 October 2009 01:40:07 Oron Peled wrote: I rather hate NetworkManager, too ;-). However, from the system point of view, I'd naively expect hal, udev, dbus, network, etc. to work without a policy kit developed by GUI people (I understand it comes from Gnome). ... However, you are correct that it's easy to see its GNOME origins. There is no command line client. This is not because the design is bad or architectural limitations --- nobody bothered writing one yet. You can try wicd, I tested it under Debian and it was pretty good. I don't know how it will break Fedroa by killing NetworkManager and installing wicd. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: how to disable PolicyKit?
On Saturday, 31 בOctober 2009 16:40:47 Diego Iastrubni wrote: On Friday 30 October 2009 01:40:07 Oron Peled wrote: I rather hate NetworkManager, too ;-). However, from the system point of view, I'd naively expect hal, udev, dbus, network, etc. to work without a policy kit developed by GUI people (I understand it comes from Gnome). Please try to cut the lines better next time. It looks like I said the above paragraph, while in reality it was Oleg... However, you are correct that it's easy to see its GNOME origins. There is no command line client. This is not because the design is bad or architectural limitations --- nobody bothered writing one yet. You can try wicd, I tested it under Debian and it was pretty good. I don't know how it will break Fedroa by killing NetworkManager and installing wicd What does it have to do with the subject? We discussed PolicyKit, integration with NetworkManager, lack of good command line integration and how bad is running big program stacks (GUI) as suid programs: 1. wicd is a GUI program (it uses GTK). 2. Like many similar older programs, there's no NetworkManager integration. 3. Therefore they all need to run as root (via suid/sudo/kdesu/etc) Cheers, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron May the Source be with you! ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: how to disable PolicyKit?
I reordered the topics... On Thursday, 29 בOctober 2009 00:10:54 Oleg Goldshmidt wrote: Does anyone know how I can disable the bloody thing globally so that it shuts up once and for all? I am wary of uninstalling it bluntly after I tried to trace the RPM dependencies and got lost in the forest - the dependency net is cast widely indeed. Is it safe to rpm -e --nodeps? Will anything serious break? 1. Obviously. The dependencies are not there just for kicks. If you try to run: yum remove PolicyKit You'll see that if you approve (don't) it will remove most of the system. 2. It is pretty integrated with modern Linux distributions, as it is part of the new Linux plumbing, together with udev, dbus, hal (migrating to DeviceKit), NetworkManager and other *Kit thingies. It seems to be a complicated and cumbersome authentication/security framework that so far has not done me much harm (I think), but I blame it for popping up annoying and meaningless (to me) authorization dialog forms requiring username and password for all kinds of weird things, URLs, etc. http://scripts.felloweb.com comes to mind as one of the recent ones, 3. Not all authentication/authorization pop ups belong to PolicyKit. First check you are not blaming it for some other pop up generator. Some examples from the top of my head: * Firefox - to control access to web sites passwords. * kwallet - to control personal passwords for all KDE related apps (konqueror web site passwords, kopete, kmail etc.) * gnome-keyring - ditto, for GNOME apps. * gpg-agent (via pinentry) - for access to gpg private keys. * ssh-agent - for the ssh private keys (or you may configure gpg-agent to work for ssh as well...) Note: Obviously, it would be nice to unite them all together, but it's not trivial -- who is going to implement WalletKit ;-) 4. Before PolicyKit, different distros/desktops implemented workarounds for running privileged operations from the desktop. Examples: - kdesu from the KDE folks. - Something from gnome (forgot its name). - The venerable sudo. - Some pam tricks (used by Fedora) to enable selected GUI administrative programs to be run by a normal desktop user, after entering a password. Note that all these mechanisms also ask for passwords... and for the life of me I can't figure out why, on top of sudo, pam, SElinux, and everything else I need this thing from the fscking Gnome (pardon my French - I don't even use Gnome, but there is PolicyKit-kde as well). 5. First, there's more than one way to do it ;-) 6. The only overlap I see is with the old tricks mentioned in 4. which will gradually phase out as PolicyKit support enters more applications. All others serve totally different needs. 7. PolicyKit is about delegation of control: - In the old days, we only used su/sudo/other-suid-program for this. - But we don't want to run whole dekstop application as root (think about running network configuration GUI as root. How many buffer overflows are hiding in the whole GUI stack?) - So split architectures started to emerge (e.g: NetworkManager). A non-privileged GUI (e.g: nm-applet) talks to a privileged system service (NetworkManager itself). - PolicyKit provide a uniform desktop independent API to such application writers that so they know which client requests to respect and which to deny. It also provides a central control mechanism for administrators. What I really want to do is to kill the beast once and for all. Too late, it already escaped the cage some years ago ;-) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron First we take Manhattan , then we take Berlin...(Leonard Cohen). Linux and Open Source - The Revolution of Choice ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: how to disable PolicyKit?
Hi Oron, Thanks for your response. Your explanations are, as always, enlightening, if not entirely convincing in this particular case. There is a specific question in the end - feel free to skip right to it. On Thu, Oct 29, 2009 at 9:43 AM, Oron Peled o...@actcom.co.il wrote: 1. Obviously. The dependencies are not there just for kicks. If you try to run: yum remove PolicyKit You'll see that if you approve (don't) it will remove most of the system. Which is why I asked for advice. However, there should be a way to tell the system I don't want it (cf. SElinux, etc.) 2. It is pretty integrated with modern Linux distributions, as it is part of the new Linux plumbing, together with udev, dbus, hal (migrating to DeviceKit), NetworkManager and other *Kit thingies. I realize that. I rather hate NetworkManager, too ;-). However, from the system point of view, I'd naively expect hal, udev, dbus, network, etc. to work without a policy kit developed by GUI people (I understand it comes from Gnome). See below. Right now, all the stuff mentioned above depends on PolicyKit. I know I am idealistic, but frankly, it seems a mess to me. 3. Not all authentication/authorization pop ups belong to PolicyKit. I understand, I only blame unexpected/unfamiliar ones on it. ;-) I wouldn't be surprised if a password dialog popped up when I, say, go to a website. These popups appear totally unsolicited, and refer to things I don't recognize. First check you are not blaming it for some other pop up generator. I cannot be sure, but after a bit of investigation PolicyKit was the only suspect. Ideas are welcome. Some examples from the top of my head: * Firefox - to control access to web sites passwords. It would only prompt for passwords to websites that are familiar to me, and only when I try to access them. besides, I hardly ever use Firefox at home and I don't let it keep any passwords (prefer kwallet as more general). * kwallet - to control personal passwords for all Again, all that stuff would be familiar. KDE related apps (konqueror web site passwords, kopete, kmail etc.) Ditto. * gnome-keyring - ditto, for GNOME apps. * gpg-agent (via pinentry) - for access to gpg private keys. * ssh-agent - for the ssh private keys (or you may configure gpg-agent to work for ssh as well...) I use ssh, but on the command-line only. Again, those dialogs would be familiar. 4. Before PolicyKit, different distros/desktops implemented workarounds for running privileged operations from the desktop. There must be something fundamentally wrong if GUI becomes responsible for security. 7. PolicyKit is about delegation of control: - In the old days, we only used su/sudo/other-suid-program for this. - But we don't want to run whole dekstop application as root (think about running network configuration GUI as root. How many buffer overflows are hiding in the whole GUI stack?) This sounds plainly as lousy design to me. Network configuration should not depend on whether I use GUI or CLI as the front-end, and should be a privileged application that can be sudoed properly (and then do setuid(2) for the briefest necessary moment). The GUI should be non-privileged. This seems to be consistent with what you say a few lines below. - So split architectures started to emerge (e.g: NetworkManager). A non-privileged GUI (e.g: nm-applet) talks to a privileged system service (NetworkManager itself). - PolicyKit provide a uniform desktop independent API to such application writers that so they know which client requests to respect and which to deny. It also provides a central control mechanism for administrators. This does not compute. If the GUI application does not need privileges, why does it need PolicyKit? It seems to me that the root cause is that it does need privileges, which is wrong in the first place, as you yourself point out. What I really want to do is to kill the beast once and for all. Too late, it already escaped the cage some years ago ;-) Hmm... This is the first time I've heard about it. I noticed NetworkManager a few months ago only. How could I live without them all these years?!? ;-) [While we are on the topic, I am still confused regarding when I am supposed to do $ sudo service NetworkManager restart as opposed to $ sudo service network restart and what the difference is.] Anyway, if I have a personal, single user computer that is *mine*, up to now I only had to put a single line in /etc/sudoers and forget the root password. Now I also have to configure PolicyKit.conf, and possibly something else? Anyway, if I put match user=oleg return result=yes/ /match in /etc/PolicyKit/PolicyKit.conf will it shut up forever and not bother me again? I did this yesterday, but I have not had enough time to check that the annoying popups have disappeared. Thanks a lot again, -- Oleg Goldshmidt
Re: how to disable PolicyKit?
On Oct 29, 2009, at 10:56 AM, Oleg Goldshmidt wrote: There must be something fundamentally wrong if GUI becomes responsible for security. This is a carryover from Windows. When anti-spyware became popular, Microsoft purchased Giant Anti Sypware, changed the name to Windows Defender and gave it away for free to genuine windows users. Windows Defender is fairly nice to use, it rarely does anything noticable if you are careful about where you go on the web. The problem with that is marketing. What good is a program you never know you have? When Microsoft integrated Windows Defender into Windows Vista, they made it annoying. It would often ask you for your password, just so that you know you had it there and it was protecting you. It seems to me that the number two question Windows Vista users asked when they first got the system, was how do I get it to stop asking me for my password. As for a GUI being responsible for security, it scares me. My linux boxes do things, and almost all of it is automatic, or via command line SSH. The one box that has a monitor on it and is used in GUI mode runs a version of MythTV, and is controlled by a remote control. Could you imagine, putting in a DVD and being asked to enter a password? Or accessing a network share? While I'm all for taking the good things that Microsoft does for Windows, re-engineering them and using them in Linux, this to me is a non solution to a non problem, and may be sacrificing headless systems (which make up the bulk of Linux systems currently installed) for a possible future gain in desktop users. IMHO that will never happen because people will never migrate from Windows to Linux if it has all the faults of Windows, they will only migrate if they see a real gain. Geoff. -- geoffrey mendelson N3OWJ/4X1GM Jerusalem Israel geoffreymendel...@gmail.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: how to disable PolicyKit?
As usual, I'll reorder topics to confuse everybody ;-) On Thursday, 29 בOctober 2009 10:56:29 Oleg Goldshmidt wrote: Hmm... This is the first time I've heard about it. I noticed NetworkManager a few months ago only. How could I live without them all these years?!? ;-) Using an old distribution: * Network Manager first shipped with Fedora 7 [Fedora 12 will ship in 3 weeks - 17/11). * PolicyKit first shipped with Fedora 8 (exactly two years ago). There must be something fundamentally wrong if GUI becomes responsible for security. GUI is not responsible to system security. However, GUI and hotplug hardware present new security challenges which are not addressed by the old (static) models. Some examples from the top of my head. They may not be perfect but they should give the general idea: * A usb web-camera is plugged into the computer: - Who should have access to this device? - Should we also allow access remotely via ssh? (Hmmm...) * Someone leaves her desktop with a screen lock. Her partner comes and use fast user switching for a new session (or maybe he is an oldie like us and does the equivalent): ALT-F2 login startx -- :1 - Who should have access to the speakers? To the microphone? - Should it be the same before/after the switch? - Would your answer be different if these were two console/ssh logins and not GUI desktops? * You plug your disk-on-key to your laptop. After a while you log out (forgetting to unplug it) - Who was the owner of the mount before logout? - If later your partner login to the same computer, can she safely umount your DOK? * A user disable the RF-kill switch on her laptop after landing at an airport. Therefor the wireless card is hotplug to a working state. - Who is authorized to configure its IP, DNS resolving etc? - Would the answer be different for the wired network connection used by the laptop at the corporate offices? - Would the answer be different if this computer was one of the workstations at an Internet cafe? I don't claim all these questions/problems are solved. However, the new mechanisms address many of them. - In the old days, we only used su/sudo/other-suid-program for this. - But we don't want to run whole dekstop application as root (think about running network configuration GUI as root. How many buffer overflows are hiding in the whole GUI stack?) This sounds plainly as lousy design to me. Correct. That's why it is phased out. Network configuration should not depend on whether I use GUI or CLI as the front-end, Agreed. So lets talk from now on about a (privileged) backend and (non-privileged) frontend and should be a privileged application that can be sudoed properly (and then do setuid(2) for the briefest necessary moment). The GUI should be non-privileged. I don't see how you think to implement such a scheme: * Using setuid(2) would help *loose* privilege, not gain it. So a non-privileged program cannot use it for gaining root permissions (e.g: to configure a network interface after a laptop resume). * Running the whole GUI as suid from start sucks as we both agreed. 7. PolicyKit is about delegation of control: - So split architectures started to emerge (e.g: NetworkManager). A non-privileged GUI (e.g: nm-applet) talks to a privileged system service (NetworkManager itself). - PolicyKit provide a uniform desktop independent API to such application writers that so they know which client requests to respect and which to deny. It also provides a central control mechanism for administrators. This does not compute. If the GUI application does not need privileges, why does it need PolicyKit? Aha! I wasn't clear enough in my previous mail, so you got it backwards. Let's try to clear it up: * The frontend does NOT use PolicyKit directly * It's the privileged backend that is consulting with the policy so it would know if to carry the privileged operation on behalf of the frontend. * Obviously, for security, the policy can only express facts that can be verified by the backend *without* trusting the frontend. Examples: - The frontend runs on the local machine (connect through local socket). - The local user is foobar (uid can be passed via a local socket and the identity verified (you don't have to trust the other end). - The user knows some secret (e.g: a password) So the flow goes roughly like this (via dbus messages): * Frontend calls backend with some request (e.g: scan WiFi around) * Backend check policy (via PolicyKit library) * Backend can optionally request authentication from frontend (depending on policy). * If policy authorize the operation, backend carries on. * A result/status is sent to frontend. I rather hate NetworkManager, too ;-). However, from the system point of view, I'd naively expect hal,
