Date: Sat, 18 Apr 1998 14:13:29 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Mike Smith <mike@smith.net.au> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Discussion : Using DHCP to obtain configuration. Message-ID: <Pine.BSF.3.96.980418140428.15725H-100000@trojanhorse.pr.watson.org> In-Reply-To: <199804180553.WAA00781@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Apr 1998, Mike Smith wrote: > > On Thu, 16 Apr 1998, Mike Smith wrote: > > > Actually, what I want is a stub version of the LDAP client library that > > > can be linked into a few of the items that run early on (init, mount, > > > fsck, dhclient, etc), before the network is up. Once the net is up, > > > everything parametric ought to be indirected through a generic "get me > > > a parameter" API. > > > > See, so the reason I find this concerning is that it stores the > > configuration information (presumably) in a single repository, and the > > kernel enforcement of the security on this repository can't be made finer > > grained. > > The kernel has little or nothing of a say in the matter. If you stop a > moment and realise that the information in question may not even be > local to the system in question, you'll realise that access controls > have to be a part of the parameter store itself. > > Fortunately for your peace of mind, LDAP supports ACL controls. This may be the case for a DHCP-configured diskless client, but if I have a hard-configured web server running user CGI applications, I am far more interested in preventing any changes to key config files when the securelevel is >0. For example, I don't want key system binaries, the fstab file, etc, to be changed in a high securelevel, where a root compromise could affect them. The alternative I would accept would be the /etc portalfs daemon (to pick a paradigm for implementing this) to run "special" like init -- i.e., not allow debuggers to be attached after securelevel++, etc. Securelevels provide the kernel with the ability to protect itself, in an appropriately configured system. It's the whole supervisor-mode kernel vs. uid 0 difference. > > If the two approaches can be made compatible, I am all for a more sane > > configuration system :). If not, then I see problems. > > If we can't come up with an acceptable compromise, then naturally it's > not going to be accepted. One thing at a time - make it happen at all > first. 8) I think it is very much in the interest of FreeBSD to provide a consistent, clean, distributed configuration system. On the other hand, I don't want to see our chances of creating a secure firewall system shot either. :) A central configuration storage utility running in userland opens another opportunity for potential security problems. Perhaps if the database, when running locally, backed onto two different database files? One protected against write in a high securelevel, the other writable in the high securelevel? Fstab information, if stored locally in the unwritable file, would be retrieved before less secure local configs, or remote configs. And during boot, the securelevel-protected data would be first hit in a search for the data (which would, optionally, pass into less-secure and netdb modes). Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980418140428.15725H-100000>