Inmutable bit in some binaries
Jeremy Chadwick
freebsd at jdc.parodius.com
Wed Feb 3 13:40:27 UTC 2010
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 at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-stable
mailing list