authenticating users for the control socket

Michael Biebl mbiebl at gmail.com
Mon Jun 11 16:33:27 UTC 2007


2007/6/11, martin f krafft <madduck at debian.org>:
> Hi all,
>
> my vision was to provide a control socket to which client programmes
> can bind and issue commands to netconfd. /sbin/ifup would then be
> reimplemented to simply connect to the socket and send the IFUP
> command to netconfd.
>
> In the long run, I would like to give users the ability to run ifup
> without becoming root. If netconfd receives a command such as IFUP,
> it would check the policy for the requested interface and see
> whether the requesting user can control it.
>
> In order to do this in a secure manner, the user thus has to be
> properly authenticated, but in using a socket, I give up the
> possibility to find out who actually issued the command.
>
> Thus, the authentication needs to happen via the socket protocol,
> and this is where it becomes interesting. If /bin/ifup can be
> invoked by a normal user, the control socket must have mode a+w.
> This means that anyone can connect to it and we cannot rely anymore
> on the authentication data provided in the protocol.
>
> I see a number of solutions:
>
>   1. use kerberos and send along tickets, thus making kerberos
>      Debian default. No. But it's a fun thought, isn't it? :)
>
>   2. use PAM. Similarly: no.
>
>   3. make ifup/ifdown/ifupdown/ifstatus setgid netconf and make the
>      control socket belong to group netconf and have mode g+w,o-rw.
>
>   4. provide a setgid proxy which receives data on stdin, connects
>      to the socket, provides the auth info to the daemon, then
>      connects stdin/stdout to the socket passthrough-style.
>
> (4) seems like the best solution, but it's not nice. Thus I am
> wondering if anyone has a better idea.
>
> Or do you think letting non-root users control netconf is silly? It
> does seem somewhat silly, but when you think network-manager and the
> possibility of having a GUI control netconf from the GNOME panel (or
> the like), it becomes all the more attractive^W necessary.
>
> Comments welcome, cheers,

Why not use D-Bus as IPC for client applications? The python dbus
binding are very good.
You could write the core netconf daemon without D-Bus dependencies and
a separate D-Bus proxy, which would make it very easy to connect to
and use from 3rd party apps.
Via D-Bus policies you can then control the access to the D-Bus service.


Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



More information about the netconf-devel mailing list