Re: [tlug] Dealing with software with wide attack surface

[furkan@example.com]

On 2021-09-06 12:48, Stephen J. Turnbull wrote:
> Curt J. Sampson writes:
>
>  > > "don't advertise containers for security" or something along the
>  > > lines is just a generic theme I got from discussions with 
> colleagues.
>  >
>  > Well, I would say that's wrong.
>
> I agree.  Containers don't give as good isolation as a VM, which
> doesn't give as good isolation as dedicated hardware, which doesn't
> give as good isolation as an air gap with epoxy in every hole except
> the power socket, which doesn't give as good security as replacing
> your system with a cinderblock.  But containers give better isolation
> than processes, which give better isolation than threads, which give
> no isolation at all.  I think I got both extremes, there. :-)
>
> Isolation != security, but it helps.

These explanations are mostly in line with what we profesionally do
for a while now.

Containers are kind of meaning 2 things at the same time, and little
bit confusing. It's the image and execution engine/runtime.

* Container Image: tarball for the app, and simple metadata like which
  process to run inside that tarball.

* Container Runtime: the tool that prepares execution env with various
  isolations, sets up network, storage, etc. and spawns the process.

Both plays role in security measures to reduce attack surface to bare
minimum.

The tarball can be made quite secure, by not including shell, etc. to
prevent privilege escalation paths (within the container, or to the
host) as much as possible.

Most engines are also handling privilege escalation issues as first
class problems to deal with, so security is a feature of these tools.
Although not a silver bullet.

There are VM based runtimes, running your images as-is, but on a VM,
removing shared kernel from the calculation, potentially reducing the
attack surface even more. Although they are usually adding additional
stuff for VM-host communication, so those paths might increase the
attack surface. These are also tools made for extra security as the
main purpose.

https://github.com/gotoz/runq
https://katacontainers.io/

There is a runtime called gVisor, it's not VM, at least not in the
sense of that meaning. gVisor re-implements the whole syscall
interface, to filter every access of the process. There is an
expected performance penalty, but should be good enough trade-off.

https://gvisor.dev/

On top of these, stateless nature (hmm, not nature, but more like
convention) of containers are also a huge security win. Some folks
even mount the container rootfs as read-only, only mounting data
folders as read-write, which improves security even more.

Also, both with VMs, and usual containers, CPU pinning could be
beneficial to prevent spectre-like leaks between workloads.

Another practice we're doing is, continously rotating containers,
keeping per-container uptime to bare minimum. And we're preodically
rebuilding images. That gives us upstream distro security updates.

* Including a line in Dockerfiles, `RUN apt-get update && apt-get -y 
dist-upgrade`
* And re-building images, at least once a week with `--no-cache` option.

Aside from distro packages, there are also pypi, npm, etc. packages..
They also keep vuln dbs, and tools to scan your dependencies. But IMO
they are mostly lacking behind the actual vulnerabilities, especially
npm and pypi. Also most vuln dbs are only available as Saas :( That's
an area that needs improvement.

* Example: https://github.com/aquasecurity/trivy

Finally, (example) running wordpress all confined like this, could
still have security issues :D I cannot do anything about that.

Furkan Mustafa
https://rainlab.co.jp