Protecting the daemon against attacks

The following measures have been taken to protect the OpenSLP daemon from attacks:
  • The OpenSLP daemon (slpd) must run as root initially in order to bind to the well known SLP port.  However, slpd will relinquish root privileges and suid() to the daemon user (if it exists).
  • If slpd includes paranoid SLP message checking code .  This slows down the operation of slpd slightly but ensures that malformed or intentionally malicious SLP messages will not cause segmentation faults in the daemon.

Protecting the integrity of service registrations

As of version 0.9.0, OpenSLP fully supports the SLPv2 message authentication blocks to ensure that registrations can not be modified in transit and that they are sent to and received from valid agents.   When properly installed and configured, OpenSLP will automatically provide this level of security to all SLP enabled applications with out any need to recompile or relink.   Installation of secure OpenSLP is a little involved...

Currently, OpenSLP uses DSS signatures to ensure the authenticity and integrity of certain SLP messages.  In order to do this, administrators need to: build a security enabled OpenSLP, provide  (or generate) a DSA  public and private keys, and setup the /etc/slp.spi file.   The administrator also has to ensure that OpenSSL crypto libraries are properly installed before secure OpenSLP will work.

Step 1:   Since we not sure how many installations will require OpenSLP security so the security features  are not currently built in by default.  To build a security into open slp OpenSLP you will have to use --enable-security on the ./configure command line

Step 2:  Generate DSA public and private key files in PEM format using the OpenSSL command line.   I'll provide details on exactly how this is done when I get more time in the mean time, you can figure it out by reading the openssl man pages.

Step 3: Copy the private DSA key PEM key file to very safe locations on hosts that will be registering services.  The public DSA key PEM file goes on all hosts that will be registering services and on all hosts that will be finding services.

Step 4: Edit the /etc/slp.spi file to assign an SPI to the DSA keys.  Details on how to do this are documented in the comments of the slp.spi file

User Level Access Control

Plans have been made to provide a mechanism that will enforce user level access control that will allow the administrator to specify the users or groups that can register services with SLP.


If you find a security hole in OpenSLP,  please bring it to the attention of the OpenSLP maintainer.  Thanks.