Inmutable bit in some binaries
amesbury at umn.edu
Fri Feb 5 01:16:12 UTC 2010
Jeremy Chadwick <freebsd at 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
> 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
> 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
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.
OIT Security and Assurance
University of Minnesota
More information about the freebsd-stable