Full_Name: Pat lashley Version: 1.2.0 OS: FreeBSD 3.1R URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.179.79.194) Under the most common usage SLAPD has no reason to run as root except to bind to the privileged socket. Once that has been done, it could easily irrevocably give up root permissions; thereby reducing the potential damage of any security exploits in the bulk of the code. It would be very easy to add user and group commands to the slapd.conf file to indicate that root privileges should be surrendered and the daemon should continue to run as the specified user and group. The default behavour if no user or group is specified should be to retain root privileges. (I.e. Run as it does now.) This provides complete backwards compatability. Surrendering root privileges should not affect the use of ldbm databases at all (assuming that the underlying files are readable by the new user/group.) On systems using shadow passwords or similar schemes, it will probably prevent passwd back-ends from retrieving the encrypted user password from the system. (This may be construed as a feature, depending upon the site's intended usage of the LDAP access to the passwd database.) It will also interfere with shell back-ends which require root privileges to operate properly. On the other hand, it should improve the security of those that may run as non-privileged users.
patl@phoenix.volant.org wrote: > Under the most common usage SLAPD has no reason to run as root except to bind > to > the privileged socket. Once that has been done, it could easily irrevocably > give > up root permissions; thereby reducing the potential damage of any security > exploits > in the bulk of the code. Beware. The Netscape server does this, and it's proven to be a *&(*$@#&#^ pain in the butt, despite being a great idea. You have to be very careful what files you open or create before and after changing process identity. It's easy to mess up and end up with files owned by the wrong user/group or trying to access a file which you can't under the current process identity. Of course you need to open the config file before the identity change, otherwise you wouldn't know what to change your identity to.
On Wed, Mar 10, 1999 at 03:56:49AM +0000, dboreham@netscape.com wrote: > Of course you need to open the config file before > the identity change, otherwise you wouldn't know > what to change your identity to. You would also have to have this user/group attribute come before any of the database definitions or else a database might still be opened by root. I think the best solution is command line arguments, that way it switches immediately, and independently of config file attributes. The other solution is running under inetd which would allow you to specify the user to run as, but performance, inetd usage isn't preferable to most. -- ----- -- - -------- --------- ---- ------- ----- - - --- -------- Ben Collins <b.m.collins@larc.nasa.gov> Debian GNU/Linux OpenLDAP Core - bcollins@openldap.org bcollins@debian.org UnixGroup Admin - Jordan Systems The Choice of the GNU Generation ------ -- ----- - - ------- ------- -- ---- - -------- - --- ---- - --
Ben Collins writes: >On Wed, Mar 10, 1999 at 03:56:49AM +0000, dboreham@netscape.com wrote: >> Of course you need to open the config file before >> the identity change, otherwise you wouldn't know >> what to change your identity to. > > You would also have to have this user/group attribute come before any > of the database definitions or else a database might still be opened by > root. As long as the "user" command in slapd.conf is given before any command which opens the databases, that should be early enough. The "user" command could abort with an error message if it is given afterwards, maybe except if the database is opened in read-only mode. I suggest that if no user is specified, slapd should change uid to the owner of slapd.conf, or maybe of the database files of the first "database" command. > I think the best solution is command line arguments, that way it > switches immediately, and independently of config file attributes. Personally I dislike command line arguments for configuration. I'd prefer to go the opposite way: Provide slapd.conf statements that can be used instead of most of the command line arguments. But of course I don't slapd having command line arguments in addition, as long as I don't have to use them:-) > The other solution is running under inetd which would allow you to > specify the user to run as, but performance, inetd usage isn't > preferable to most. Hm... actually we _could_ use a similar approach: If the sysadmin doesn't trust the great big slapd program, he could use a small program which opens a socket as root, changes uid, and starts slapd with that socket as file descriptor 0. -- Hallvard
Oops, I missed an important word - > of course I don't ...mind... > slapd having command line arguments in addition, as long as I don't > have to use them:-) -- Hallvard
On Fri, Mar 12, 1999 at 05:59:23PM -0800, Kurt D. Zeilenga wrote: > The uid/gid/root changes may also only be feasible with a subset of > the backends (ie: ldbm/bdb2). For example, back-passwd requires > privledged access to the system password file. back-perl and pack-tcl > also have special requirements. As far as the back-passwd, most systems can work around it with "-u nobody -g shadow" and could be mentioned in the README as a workaround. This atleast still leaves some level of system protection. back-{perl,tcl} should not have any different requirements for privildges than the database backends, slapd will simply need 'rw' access to the data they are serving (since the perl/tcl scripts are loaded into memory upon startup, they wont run as subprocesses) -- ----- -- - -------- --------- ---- ------- ----- - - --- -------- Ben Collins <b.m.collins@larc.nasa.gov> Debian GNU/Linux OpenLDAP Core - bcollins@openldap.org bcollins@debian.org UnixGroup Admin - Jordan Systems The Choice of the GNU Generation ------ -- ----- - - ------- ------- -- ---- - -------- - --- ---- - --
moved from Incoming to Software Enhancements
At 04:27 AM 3/12/99 -0800, Kurt D. Zeilenga wrote: >As far as uid/gid support goes, I'd like to see it modeled after >named (under FreeBSD at least) -u/-g options. These allow specification >of the uid/gid by name or id. If gid is not specificied, then getgroups() >is used (which opens access to to all groups that this uid is in). named also supports a chroot() sandbox. This would be another feature that could be added. slapd -u openldap -g openldap -t ~openldap/sandbox Of course, getting chroot right is even harder than uid/gid changes. The uid/gid/root changes may also only be feasible with a subset of the backends (ie: ldbm/bdb2). For example, back-passwd requires privledged access to the system password file. back-perl and pack-tcl also have special requirements. Kurt
changed notes changed state Open to Test
changed state Test to Closed
Experimental solution committed to -devel.