Ignat Korchagin

Because the kernel code executes at the highest privilege level and a kernel bug usually crashes the whole system, many SREs, production engineers and system administrators try to avoid upgrading the kernel too often for the sake of stability. There is a tendency to create more obstacles to Linux kernel releases (requiring more approvals etc). But introducing all these obstacles and not treating kernel updates like any other software usually significantly increases the risk for the company and their service of being exploited.

One of the reasons SREs and engineers are too afraid of ANY kernel upgrade is that they dont actually know the details about Linux kernel release process and policy. This talk tries to demystify Linux Kernel releases and provides a guide on how to distinguish a kernel bugfix release from a feature release. We also describe how kernel releases are implemented in our company and propose possible approaches to deploy kernel upgrades regularly with minimal risk.

Linux seccomp is a simple, yet powerful tool to sandbox running processes and significantly decrease potential damage in case the application code gets exploited. It provides fine-grained controls for the process to declare what it can and cant do in advance and in most cases has zero performance overhead.

The only disadvantage: to utilise this framework, application developers have to explicitly add sandboxing code to their projects and developers usually either delay this or omit completely as their main focus is mostly on the functionality of the code rather than security. Moreover, the seccomp security model is based around system calls, but many developers, writing their code in high-level programming languages and frameworks, either have little knowledge to no experience with syscalls or just dont have easy-to-use seccomp abstractions or libraries for their frameworks.

All this makes seccomp not widely adoptedbut what if there was a way to easily sandbox any application in any programming language without writing a single line of code? This presentation discusses potential approaches with their pros and cons.

Did you know that Linux has a full-featured keystore ready to be used by any application or service it runs? Applications can securely store and share credentials, secrets and cryptographic keys, sign and encrypt data, negotiate a common encryption key - all this by never touching a single byte of the underlying cryptographic material.

This is especially useful in the post-heartbleed and cloud-native environments, where services authenticate and securely talk to each other using some kind of credentials. But if a network-facing service also has some secret in its process address space, it sets itself up for a security failure as any potential out-of-bounds memory access vulnerability may allow the secret to be leaked. Imagine a world where you dont have to run an SSH agent just to protect your SSH keys.

On top of keeping your secrets secret Linux keystore nicely integrates with specialized security hardware, like TPMs and HSMs and may provide a single entry point on the system for applications to obtain their secrets. Thus Linux keystore is a very useful building block for a corporate key management system.