Cleaning up the mess in a container

Security is always a big deal with computers.  If you know how to do more than plug in a printer, you've probably had someone ask you to take a look at their computer.  It was probably riddled with malware that more than likely came from online games or some sketchy adult website.  A security conference that I went to many years ago kept bringing up how a browser got hijacked while logged in as a low privilege user, and it led to a full scale compromise of the system.

One of the resources used by security researchers as a guideline to secure their systems is the Secure Technical Implementation Guidelines (STIG).  There is plenty of chatter online about them being laid out in a ridiculous manner, or not going far enough.  That is why they are a resource, not the resource.  I agree with many of the arguments.  I'm not sure if it is still true, but one version had something like 12 checks for what was in the SSH configuration file.  The checks also spanned the category level, which means that instead of fixing all 12 checks in one shot,  if you sorted by category you ended up modifying the file 3 or 4 times to knock out all of the checks.

Aggregate 1
Where to get STIGs

If you work in security, you'll also know not to trust that link.  Look at what it leads you to and either validate it, or go through a trusted resource. 

One of the checks that always bothered me because I am lazy and crave some level of convenience is the removal of compilers.  If I get rid of gcc on my system, I can no longer install some patches or re/compile applications and the kernel.  While that is true, all you have to do is reinstall gcc when needed, and remove when you are finished.  It prevents everyone else that shouldn't be using it from readily having access to it.  The same is true of what we put in containers.  When I created my own Nginx container I had to add make, gcc, and other tools to build from source.  I recently noticed that the thin version of Photon OS does not include tar.  These types of tools are standard on most new systems, because the system is new and will need them for building the applications and applying the first round of patches.  This is not a new security practice either, just an often overlooked one.

Aggregate 2
Check out the date on this question

There should always be a fork of a container when it goes into production.  Keep your development container, with tools installed, tagged as a dev container locally.  Also, keep a list of what all you have added that can be pulled off of the container before it is tagged and pushed as a production ready container.  Never install SSH on a container unless you have some use case that absolutely requires it.  Installing SSH on a container is generally not a necessity even in dev environments, and causes a cascading amount of security issues.  Following those tips will earn you a serious amount of respect from anyone that pulls your container from a registry.  Nobody wants to search for tools that they have to remove from a container. 

There are plenty of resources aimed at containers coming out of the woodwork right now for that sweet security money.  They are not really aimed at home users.  The starting point for a home user/hobbyist should be Linux hardening knowledge, which has it's own resources (like the STIG).  If you want to geek out about security, find your favorite tools and procedures that fit your environment.  Some of the hardening guides go through some pretty intense security practices that are not worthwhile to a home user that is operating within their own firewalled network.  Practices that I would only consider at home if I were using them to learn how to implement higher levels of security in a production environment at work.  So, in essence, be realistic about what kind of threats there are in your environment.

Aggregate 3
Geek out about container security

That link will probably have a pop-up, trying to get that sweet security money.