Security
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.
Help
If you find a security hole in OpenSLP, please bring it to
the attention of the OpenSLP
maintainer. Thanks.