[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Enhancing lan:/ and rlan:/
From:       Tim Jansen <ml () tjansen ! de>
Date:       2003-06-24 18:29:37
[Download RAW message or body]

On Tuesday 24 June 2003 12:44, Brad Hards wrote:
> The daemon is then an SA and a UA?

Yes.

> > - SLP packets are not used for communication between the daemon and the
> > library. Instead a completely different protocol is used for IPC.
> I'm not sure I follow you. Is the intent that if the daemon is exploited,
> that it will be more difficult to use the IPC mechanism than if the daemon
> simply passed SLP packets?

Yes. OpenSLP's slpd acts like a DA for libslp. When you register a service, 
libslp sends a SrvRegRqst packet to slpd, and slpd replies with a SrvRegRply. 
If there's a buffer overflow in the parsing function for SrvRegRply, an 
attacker can execute code in slpd's context and then use the same exploit to 
execute code in libslp's context.

> > - the daemon monitors the state of the system's network interfaces and
> > reacts accordingly. 
> How portable is this? Do you poll interfaces?

I do this by calling getifaddrs() every minute and comparing the result to 
previous results. For older Linux systems I backported the glibc 2.3 
implementation of getifaddrs(). 
Right now the server runs only on Linux - one of the reasons why the API must 
support OpenSLP, it is my portability layer :)
getifaddrs() is not the problem though, BSDs have it and the glibc code should 
work fine on SystemV Unices. The Linux dependency will hopefully disappear 
when Thiago's new network API is finished. I am planning to switch from POSIX 
code to this API then, not only for portability but also for IPv6 support. 


> > Beside the RFC 2614 API it is possible to use the IPC protocol directly
> > or implement additional APIs that use the IPC protocol. One of these API
> > is the KDE API that I am currently working on. The API can also be used
> > with OpenSLP, but you can't use the new features then.
> Can you post this interface? Or just send me a copy?

I created doxygen docs and posted them at http://www.tjansen.de/knot/kdeapi

I have also created a snapshot of the source. To use it, unpack it in 
kdenonbeta, make -f Makefile.cvs reconfigure and so on.... 
http://www.tjansen.de/knot/snapshots/knot-03-06-24.tar.gz


> So if you are in a zeroconf environment (where addresses are subject to
> change) or are roaming, or whatever, and the IP changes (or hostname
> changes), this is handled by the daemon?

Yes. You must register the service with the service URL scheme and localhost 
as host (service:abstracttype:type://localhost(.*)). When the daemon receives 
a request for that service as SA, it will then replace 'localhost' with the 
IP address of the interface that received the request. If the daemon forwards 
the service to a DA, it replaces 'localhost' with the IP address of the 
interface that received the DA's DAAdvert.

bye...

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]