Re: Lockdown nm-applet once again

[Tambet Ingo <tambet gmail com>]

On Wed, Jan 20, 2010 at 02:07, Dan Williams <dcbw redhat com> wrote:
> On Tue, 2010-01-12 at 10:30 +0100, van Schelve wrote:
>> Hi.
>>
>> In the archives I have found this entry:
>>
>> http://www.mail-archive.com/networkmanager-list gnome org/msg13808.html
>>
>> The question that was talked about there was how to lockdown the
>> nm-applet.
>>
>> I have successfully tried to lockdown the nm-applet by changing the dbus
>> config as descripted by Dan.
>>
>> It looks like this would be a valid workaround. But I don't know if it is
>> possible
>> to have this config part in a seperate file? I didn't found anything
>> useful in the
>> freedesktop dbus documentation for this question.
>
> For enable networking and enable wifi/wwan, the best way would be with
> PolicyKit.  Unfortunately that's not quite implemented yet and we'll
> need to do a bit of work to PK-enable these properties since dbus-glib
> doesn't have an easy way of intercepting property get/set calls.  But
> that's the perfect future :)

We (Novell) wrote full PK support to lockdown pretty much everything
in NM. I believe Lance Wang worked on that, Lance, can you share the
patch so it can be included in upstream?

Tambet

>
>> In general it would be very fine to configure the whole nm-applet in a
>> single
>> config file (f.e. /etc/NetworkManager/nm-applet.conf). Currently there are
>> three
>> steps to lockdown nm-applet:
>>
>> 1. dbus config to disalbe the enable/disable Network option
>> 2. gconf for notification behaviour
>> 3. chmod, selinux, apparmor or whatever for nm-connection-editor
>
> I believe that in general the two places for lockdown should be
> PolicyKit (for NM in general) and GConf (for nm-applet specifically).
> PolicyKit lets administrators lock down the behavior for *all* clients
> generically (command-line, Gnome, KDE) while applet-specific behavior
> gets locked down by that desktop environment's normal methods.
>
> I'd hope that in this bright shiny future you'd never have to deal with
> either (1) or (3) from your list above since it would already be handled
> by PK and GConf/K-whatever.
>
> Dan
>
>
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
>