HI all, I'm hardening one test box and at present I'm planning to do: # chflags -R schg <file> where <file> will be some binaries that seems to be common targets for rootkits and lammers: ls du ps find top locate strings ifconfig netstat login I wonder if changing these files permissions as I've shown above will be cause some troubles in future upgrade (recompilation, the classic way, not the binary upgrade one) process. ?It will? -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear.
On Wed, Feb 03, 2010 at 01:33:15PM +0100, Jordi Espasa Clofent wrote:> HI all, > > I'm hardening one test box and at present I'm planning to do: > > # chflags -R schg <file> > > where <file> will be some binaries that seems to be common targets > for rootkits and lammers: > > ls > du > ps > find > top > locate > strings > ifconfig > netstat login > > I wonder if changing these files permissions as I've shown above > will be cause some troubles in future upgrade (recompilation, the > classic way, not the binary upgrade one) process. ?It will?It's possible installworld will break (fail/exit) when trying to overwrite some of these binaries. However... install(1) supports the -f flags to specify what the destination file should have its file flags (chflags) set to, and from looking at the code (src/usr.bin/xinstall/xinstall.c), there are some places which indicate before copying/installing a file the software may attempt to unset file flags first. I'm not 100% familiar with this code, but it appears as if use of the -S flag to install(1) would cause it to behave like described. It should be easy enough for you to test. Otherwise, my recommendation is to build a test system / virtual box of some sort (VMware, etc.) and try it. See what happens. Opinion below: 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). 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 binaries don't work or behave oddly because, say, /libexec/ld-elf.so was supposed to be updated yet wasn't due to their choosing to not follow the proper procedure. If your system doesn't have an out-of-band method of getting to it (ex. serial console), then I wouldn't bother trying any of the above. 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. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Jeremy Chadwick <freebsd@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