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 <mosga...@vm10124.spb.edu> 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