With the release of Twistlock 2.3, we have expanded on the visibility and protection for running containers. Earlier, our team discussed enhanced runtime detection capabilities by integrating research from Twistlock Labs. Let’s recap our runtime defense capabilities and why these capabilities make Twistlock, as my mum says about me, special.
First, development teams scan their images for vulnerabilities and compliance issues, preferably at CI/CD time in addition to scanning their registry. With these initial scans, developers know the state of the image, yet they still don’t know what happens at runtime.
Next, developers and devops teams start a container from that image and have something (nudge, nudge Twistlock) automatically learn about what that container does. Now they can see into the container and protect what processes run in it and what networking the container does, as well as the file system activity. All of that runtime knowledge is automatically done by Twistlock.
With Twistlock 2.3, we further enhance that process by providing deep, automatic integration to deploy focused seccomp (Secure Computing Mode) profiles tailored to the application.
Lots of words there. Let’s go into them.
Understanding system calls
What’s a system call?
In computing, a system call is the programmatic way in which a computer program requests a service from the kernel of the operating system it is executed on.
Coming from the land of system administration, I tried to have as little to do with the actual computers as possible!
“It’s probably the network” I would say. Or, “I hear that the solar flares are particularly bad today, it’s probably that.”
So, I tend to agree with Sir Winston Churchill when he said, referring to a computer [Sir Winston was actually referring to the Soviet Union in 1939 – Ed]
It is a riddle wrapped in a mystery inside an enigma.
Let’s unravel what a system call is and how it impact containers. Programs make system calls to get the operating system to do things. When programs run, they run as processes. Containers group processes, albeit in a rather fancy way, with various kernel controls around them. The kernel is the core of your operating system and abstracts access to the hardware.
Expanding on Sir Winston’s quote:
It is a system call (or two) wrapped in a program inside a container.
Maybe I won’t be the next Prime Minister of the United Kingdom.
System calls can be put into six groups:
- Process management
- Interprocess communication
- Memory management
- File system
Seccomp restricts the system calls that processes can make. However, you need to know what system calls will be made to be able to restrict them or else you just break your software.
Security vs. usability vs. convenience.
Why do we want to protect these system calls?
In the land of Unix, that frightening socks and sandals place from whence I hail, processes are active instances of a program.
These processes can run in one of user mode or kernel mode. User mode only has access to its stuff and kernel mode has god-like powers over the entire operating system.
Processes needing to do things with stuff that isn’t theirs, such as interprocess communication, write things to disk, or perform another of the system call groups above, do so by sending a signal to the kernel. The kernel then elevates the privileges of that process via a system call and so allow a process to perform a task that it would not normally have access to.
In summary, system calls let everyday processes do things above their pay grade.
Why is Twistlock unique?
From inception, our team has contributed to many of the security features throughout the cloud native ecosystem. Of particular interest, Twistlock wrote the authz plugin within Docker and have built on their use of seccomp security profiles.
While there are many security advantages of running your applications with Docker, our research team, Twistlock Labs, continues to uncover notable vulnerabilities and threat scenarios:
- CVE-2017-16544: A Busybox autocompletion vulnerability
- Hiding content from Git + more on escape sequences: Twistlock Labs Experiment
- CVE-2017-5123: Escaping Docker container using waitid()
Twistlock Labs examined the most used images to pinpoint exactly what system calls are needed (like Mongo for example). Then, they produced templates that can be assigned to these images when they run as a container. As soon as a developer runs one of these images, they automatically get visibility of the system calls as well as a secure policy profile attached to them.
For any other container, Twistlock will automatically add a default seccomp profile when they start, enhancing the existing security of your overall environment.
Here is an example for Mongo:
The screenshot only captures a small amount of the allowed system calls!
Of course, you need to have the power to add or remove system calls to those profiles. Twistlock provides, out of the box, excellent security features, templates and defaults, but you know your business and software best. That’s why Twistlock is so flexible.
Then you can explicitly allow or deny system calls and tailor that as fine-grained as any other rule we have.
An overview of how syscalls work with Twistlock
The diagram below provides an overview of Twistlock as it relates to syscalls.
- The operator starts a container.
- Defender intercepts the command.
- Defenders starts the container, injecting a seccomp profile into the container. The profile is constructed from:
- Either an app-specific profile or a generic profile, plus
- Any system calls required by any capabilities enabled for the container, plus
- Any system calls whitelisted in an applicable container runtime rule, minus
- Any system calls blacklisted in an applicable container runtime rule.
And that’s it in a nutshell…(a kernel pun, I’m sorry).
Ping me if you want to know more or chat or generally mock me. Alternatively for a professional low down on Twistlock and how incredibly cool it is (I should know, I was a customer many moons ago) then get a demo at https://www.twistlock.com/get-twistlock/.
• Protecting Containerized Applications with System Call Profiling and Whitelisting
• Cloud Native App Firewall (CNAF) Deep Dive
• Enhanced Visibility: Container Vulnerability Management from Build to Runtime
- Twistlock Platform
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Announcing Our Series C FundingRead the Blog
Real Time View of Your Cloud Native Applications: Radar v3Read the Blog
AWS Fargate Security: Runtime Defense with Twistlock 2.5Read the Blog
Cloud Native Forensics: Security Incident Response in Twistlock 2.5Read the Blog
Announcing Twistlock 2.5: GA Release NotesRead the Blog