Inmutable bit in some binaries

[Alan Amesbury]

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 
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