This thread raises some interesting point but I've seen a few
misconceptions in it too

first let me clear up the misconceptions.
1) busy box is meant to make the footprint on an appliance or live
"CD" type distro smaller it is not for security. Rootkits that replace
busy box have been seen in the wild on appliances in the past, so its
not necessarily a good answer to prevent rootkits.
2) you really don't need root to be writable in production on any
system as long as you've laid out your logical volume or partitions
correctly and just add a few simple operational procedures when you
update or modify configuration files. As far as updates go you can
still do it by remounting (mount -O remount) the filesystem as read
write first,run your updates, then remount again as read only. I've
been doing this on secure systems for over 20 years and its quite
effective in preventing about 40% of root kits from infecting a
system. In fact in the cloud you should make your instances as
stateless and read only as possible. you do this by only doing updates
on the VM you use to create your image and not the production VM's
instead you should just replace them when you are ready to update this
works well with thing like AWS autoscaling and other similar
solutions. in reality on most systems only /var, /tmp (preferably
tmpfs), and maybe /home need to be writable in production.
3) SELinux secures system processed but not user executed commands for
that you need apparmor which is not implemented in RHEL yet.

now some suggestions
A simple solution for file integrity checking is AIDE
https://sourceforge.net/projects/aide/ there has been an RPM included
in all versions of RHEL and Fedora since the first versions.
If you want a better more enhanced rootkit protection look at Samhain
http://la-samhna.de/samhain/ here is a SANS article from a couple of
years ago which can walk you through the install
https://www.sans.org/reading-room/whitepapers/detection/samhain-host-based-intrusion-detection-file-integrity-monitoring-34567
If you want to get really into it look at OSEC but be warned I've
found OSEC has issues with the cloud specifically when autoscaling is
involved because its very difficult to remove retired instances .

In the cloud I have found simpler solutions like using AIDE work well
because you don't need to register and unregister instances, also you
can precreate the database on the VM you use to create the image so no
post launch scripts need to be added to cloudinit.
That said I haven't tried it yet in the cloud yet but I think Samhain
may have some potential in the cloud but the implementation of it for
the cloud would need a lot more forethought then a standard install.

On a side note effecting the load order of libraries is not a new
method for rootkits, and many of them have been know to install
themselves in users home directories and modifying the users profile
and or bashrc.
Also i know it hasnt been updated in a long time but if you want to
know more about securing a Linux box I highly suggest you take a look
at what Bastille Linux does  http://bastille-linux.sourceforge.net/
even though its out of date (looking for config file in the wrong
place or expecting an old syntax) a lot of the base concepts of what
it did are correct and very good to do if you want to secure a system.

On Thu, Sep 8, 2016 at 6:44 AM, Vladimir Mosgalin
<[log in to unmask]> wrote:
> Hi Steven J. Yellin!
>
>  On 2016.09.07 at 19:03:32 -0700, Steven J. Yellin wrote next:
>
>>     Are rpm and the check sum tools statically linked?  If not, hiding
>> copies of them might not help if libraries have been compromised.  But
>> busybox is statically linked, and it looks like it can be easily used to
>> replace most commands used to check security without going to the trouble of
>> pulling files from it.  For example, 'ln -s busybox md5sum' allows use of
>> busybox's md5sum and 'ln -s busybox vi' allows use of its vi. See
>> https://busybox.net/FAQ.html#getting_started .
>
> Statically linked rpm won't help you at all. This malware in question
> doesn't modify any system files or libraries, it installs new (non
> system-managed) library and creates extra config file for linker, it has
> random name and is treated as non system-managed as well. This library
> preloads itself for any non-statically linked binary and replaces libc
> functions.
>
> rpm has absolutely nothing to do with non-system files, you can do as
> many verify passes as you want, using statically linked rpm binary if
> you prefer, and it won't show you that anything is wrong.
>
> --
>
> Vladimir