how to disable PolicyKit?

[Oron Peled]

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, udev, dbus, network,
> etc. to work without a "policy kit" developed by GUI people (I
> understand it comes from Gnome).

NetworkManager didn't spring out ready and cooked. It gradually
developed features and fixed deficiencies. I'll try to give an
overview from my point of view (Fedora):
 * NetworkManager 0.65 (Fedora 7) was installed but *NOT* activated
   by default:
   - Because otherwise it would start sending DHCP requests on all
      interfaces, destroying the existing configuration.
   - Normal users, were not affected at all.
   - However, laptop users could enable it on boot. Disable the legacy
      /etc/init.d/network (so they don't fight over the interfaces)
      This would enable them to roam easily between wireless networks
      (a must have for mobile users).
   - It would choose the "best" interface (in his own opinion). E.g: plugging
     to a wired network would disconnect the wifi and connect to the wired
     network.

 * NetworkManager 0.7 (a pre-release included in Fedora 8) was enabled
    by default:
    - It had distribution dependent plugins that could parse the legacy
      configuration (/etc/sysconfig/network-scripts/ifcfg-* for Fedora)
    - So it only touched interfaces without legacy configuration.
    - It wasnt all or nothing anymore. You could have your wired connection
       with static config and Wifi with dynamic config.

 * Another feature added at roughly the same time was the ability to
   manage several connections and route among them!!!! WOW!!!
   Routing!!! What a novelty....

Sarcasm aside, NetworkManager today works reliably, handle
a wide variety of scenarious (GSM modems, VPN configuration, etc.)
and solves the problem of privilege separation (NetworkManager
handle the root stuff, nm-applet handle the UI).

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.

In fact there is a useless command line client named nm-tool. The problem
is that it only shows information, but don't have any arguments/options
to *control* NetworkManager.

Anybody pissed off by this (like me) is invited to write such a client
or keep quiet ;-)
[nm-tool may be used as a limited example)

> [While we are on the topic, I am still confused regarding when I am
> supposed to do
>          $ sudo service NetworkManager restart
If you want NetworkManager controlled interfaces.

> as opposed to
>          $ sudo service network restart
> and what the difference is.]
If you want the legacy configuration files.

> 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?

Yes, this is verbatim example from the manpage of PolicyKit.conf (OK,
you changed the user name ;-)

> I did this yesterday, but I have not had enough time
> to check that the annoying popups have disappeared.

If not:
  - Either a bug in PolicyKit -- please report
  - Or a pop up from something else.

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
באנו ווינדוס לגרש, בידינו פנגווין יש!