Re: ITS#98 'user' patch for BSD systems

[patl@phoenix.volant.org]

>                                            The chroot/gid/uid changes
> should be done before executing any backend call.

Or at lease before executing any backend call that is allowed to
access system resources.

> Under "early"/"late" configuration, you'd have to scan the configuration
> information twice.  That's easy (a simple buffer could be used).  What's
> hard is to determine what to do early and what to do late such that it
> all works when the environment is changed between early and late.

I don't think that's really necessary.  As I understand it, currently
there is a per-backend-type initialization function called when the
database is declared during the config file reading.  I don't think
that any of the standard backends actually open files or access other
system resources during that initialization.  The concern is that some
contributed back-end might do so.

It seems to me that the solution is simple.  Just add another init
function pointer to the database structure.  The semantics would be
defined such that the existing init would be prohibited from accessing
system resources; but the new one would be allowed to do so.  Then,
after the rest of the basic server initialization (socket open, chroot,
setuid/gid, etc.), grovel through the list of databases calling the
new final init function.

> You'll find that many configuration steps done today will need to be
> completely redesigned to split them apart.
> 
> Personally, I think this is a lot of work for arguably little gain.
> Many believe that parsing parsing configuration files as root is very
> dangerous (in fact, this should be considered the prime target).  If
> any one configuration file is left writable, the process can be subject
> to a wide range of attacks.  Not only can a cracker read any file on
> the system (using include), trash any file (using args/pid file), make
> the system unbootable (setting args file to /kernel or other file needed
> at boot) and crash the system (setting pid file to /dev/kmem or like).

I'm not sure the 'read any file via include' is really a problem - it
would generally immediately generate a config error and abort.  Trashing
any file via the args/pid command is a bigger problem; but it should
be solvable by hard-coding a test for ownership, type, and size of
existing files before overwriting them.

But more importantly, if the config file is only writeable by root,
then the ability to tweak it to cause damage implies the ability to
write -any- file anyway.
 

> To get the maximum benefit of chroot/uid/gid, it should be done as early
> as possible.  Especially, it should be done before reading configuration
> files.  Additional safeguards on configuration files should also be
> put in place (read-only to uid/gid, etc.) and that directories for
> args/pid files not be group or world writable.

If the chroot/uid/gid setting is after the config file is read, then
it can be set up so that after the initialization, the server doesn't
even have read access to it's configs any more.

> The only issue is that the listener info must be specified on the
> command line.  This is ALREADY the case.  We'd only need to relocate
> the bind() call to before the configuration file parsing.  The listen()
> and args/pid file creation could be left were they are.
> 
> This is much simpler to implement and get right.

Only if you agree that the listener info SHOULD only be settable via
the command-line.  I'd prefer to have config-file options for every
command-line option except the one that specifies the config file itself.

> I'd like to point out that if LDAP to authenticate access to your system
> (via pam_ldap or the like), it really doesn't matter what root/gid/uid
> slapd is running under.  If it's cracked, you've wide open.  I guess this
> is true with most other system account authentication services.

Absolutely.



-Pat