Jeremy Chadwick <free...@jdc.parodius.com> said:
It's possible installworld will break (fail/exit) when trying to
overwrite some of these binaries. However...
It will totally break installworld where installworld tries to replace
the file. Been there, done that, and have the collector's edition
soundtrack.
[snip]
What you're attempting to solve, ultimately, is security through
obscurity and gets you a very large headache. :-) Your schg idea would
only work if you planned on using kern.securelevel=1 or higher. This
sounds great in concept, but many a time on this list have people posted
problems with system administrative tasks (re: upgrading) when this
sysctl is set to non-default (-1).
I run at kern.securelevel=2 on most hosts at work and home. The only
problems I've encountered are
a) you can't do an installworld reliably (but see below!)
b) buildworld sometimes fails
c) X and other devices that use /dev/io break
Workstation-class hosts don't use securelevel specifically because of
"c". I don't need X on my servers so it doesn't get installed; no
problems there.
If you plan on using this, I would advocate *all* installation/work be
done in single-user mode. I know quite a few people who completely
ignore the "boot into single user" step of src/Makefile and instead do
it in multi-user mode -- only to be found later screaming/crying when
[snip]
100% agreement! I admit to occasionally taking shortcuts on this, but
the majority of the time installworld and mergemaster are done in
single-user. Every time I've had a problem with installworld while
*not* doing this could be attributed to trying to do it in multi-user.
The fact that buildworld will only *sometimes* fail in multi-user with
kern.securelevel=2 is something that I consider to be a bug in the
buildworld process, but not one serious enough that I've dug into it to
find the root cause. The failure is almost always when attempting to
touch the SSH binaries that show up under /usr/obj during the build;
schg gets set on those at some point... but, again, I haven't bothered
to figure out when or how. In those instances, I'm willing to reboot
with securelevel disabled, do my work, then enable it again when I'm
finished. This seems to work well.
The only problems I see with applying schg and friends to other files is
that it will complicate your upgrades. I suspect it's doable, though,
provided you keep track of which files you're modifying. Then you can
remove the flags prior to an upgrade, let buildworld/installworld do its
thing, and reapply them when the work's complete. It's possible that
mtree(8) might be very useful for documenting this sort of thing.
Otherwise, I'm pretty sure others here have made use of read-only
environments, such as read-only NFS root filesystems (sometimes
accomplished via PXE) and/or /usr, or CD-based OS (good luck changing
any files there). I can't help in that regard.
Actually, sysutils/ezjail puts together a pretty nice framework that
makes use of what's effectively a read-only OS with other things
overlaid on top of it. That might work as an example, if one's needed.
--
Alan Amesbury
OIT Security and Assurance
University of Minnesota
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
