[Date Prev][Date Next]
Re: ITS#98 'user' patch for BSD systems
Hallvard B Furuseth wrote:
> > If no password entry was available for the uid, exit.
But exit if uid was given but no group.
My statement was in the 'if no group' clause....
> For security, or for simplicity?
Security and simplicity go hand in hand.
> > I would recommend chroot'ing BEFORE reading the configuration files.
> If it's done that early, couldn't the sysadmin just as well
> use the chroot shell command?
Yes, along with uid/gid changes (the bounded streams would have to
be opened by the wrapper and passed across an exec()). But I rather
not detach security handling to an auxiliary program.
> > I also recommend changing uid/gid before reading the configuration
> > file.
> Then the startup sequence must be rearranged quite a bit.
Well, getting chroot/gid/uid settings right can be messy business,
especially if you introduce "early" and "late" configuration
issues. We currently start the listener AFTER we initialize/startup
backends. This would have to be changed. The chroot/gid/uid changes
should be done before executing any backend call.
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.
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).
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.
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.
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.