Date: Thu, 21 Dec 2000 12:38:49 +0000 From: David Pick <D.M.Pick@qmw.ac.uk> To: freebsd-security@FreeBSD.ORG Subject: Re: Read-Only Filesystems Message-ID: <E1494zh-0007HA-00@xi.css.qmw.ac.uk> In-Reply-To: Your message of "Wed, 20 Dec 2000 18:05:58 PST." <657B20E93E93D4118F9700D0B73CE3EA024346@goofy.epylon.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
> The only way I could think of to do his securely in the current
> implementation is to chflags most of the etc dir (with the exception
> of files that did need to be cahnged like passwd master.passwd
> aliases, etc.).. mainly the rc files.. but this makes administering
> remotely a pain in the ass.. Of course, security in many cases comes
> with a hassle factor.
Some years ago I was running a RISCiX system and wanted to use
it in a number of different locations on the network. I set up
a slightly unusual disc structure as follows:
1) The / filesystem was mounted read-only - permamently
2) There was no separate /usr filesystem
3) For each of the "changeable" files there was a symbolic
link of the form: /etc/passwd -> /config/etc/passwd
4) Early in the "rc" scripts the system asked which configuration
it should use, and this was used to chose which of a number of
small filesystems should be mounted on /config providing the
details for that particular "configuration"
5) /home was, of course, a separate filesystem
6) /var was linked as in item 3, giving separate sets of logs
for each "configuration"
and various other small points of detail.
This does not actually help the original problem, but did make
the separation between read-only (apart fron systems update) files
and "configuration" files much cleaner. It would have allowed
the root filesystem to have been on a hardware-locked read only
disc drive (or a CD but they weren't around then), and that's a big
win. I couldn't have put /var, but could have put the remains of
/etc on a floppy and used the write-protect tab.
Using the filesystem "flags" is s different approach to trying to
protect files that should not normally change. It's less safe than
the approach I took, but more flexible. I wasn't primarily trying
to get 100% security, but did get a fair bit as fallout. It's
quite a lot of work to get something like this configured, but
people who *know* there are strangers out there trying to "get"
at their conputers might think it's worthwhile.
--
David Pick
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1494zh-0007HA-00>