On 08/09/16 23:57, Paul Robert Marino wrote:
> 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.

Suggestion: Have a statically linked busybox binary stored on an offline
device which is only activated when absolutely needed.  And with
offline, I mean something which is disconnected physically from the
system when not being used.

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

Good points!  These hardening steps will definitely give results.

Another thing to consider is to configure Tripwire.  That is a tool
which creates a signature database of all configured files and tracks
them.  Log files can also be tracked, where it allows log files to be
appended but not modified since last "check-point" (should be run at
least once per day).  The downside of Tripwire is that it requires you
to update the signature database each time you do some yum
update/install operations.  And such updates requires an additional
password to unlock the signature database for write access.  Each time
the "check-point" run has completed, it will provide a list of all
unexpected modifications on the system.  Tripwire is found in Fedora EPEL.

> 3) SELinux secures system processed but not user executed commands for
> that you need apparmor which is not implemented in RHEL yet.

AppArmor will most likely never see the light in RHEL.  Because SELinux
can do similar things, with a far better fine grained control.  And if
you instead of choosing the targeted SELinux profile (which is the
default) and use the strict profile instead, all applications running on
a system must have a SELinux policy defined.  This does require some
additional efforts to configure, but once done it is much harder to do
things on the system not being approved in advance.


-- 
kind regards,

David Sommerseth