When working with potentially dangerous, unverified, or simply raw software, developers often use sandboxes. These are special environments that isolate or restrict programs and code from accessing data outside the environment. Sandboxes limit the software’s network access, OS interactions, and information from IO devices.
Lately, people have been turning more and more towards containers for launching unverified and non-secure software.
Despite their similarities, containers are not the same as sandboxes, if only for the fact that sandboxes are often designed for a specific application and containerization is a more universal technology. It’s also worth mentioning that an application launched in a container could gain access to the kernel and compromise it. This is why today’s containerization tools use mechanisms for boosting security. In today’s article, we’d like to talk about one of these mechanisms: seccomp. Read more
Original publication date: September 22, 2015.
The audit subsystem is used to raise the level of security in Linux systems. Although it doesn’t offer additional security per se, it’s used to retrieve detailed information on system events. This provides detailed information on system violations, which can be used to implement additional targeted security measures. We’ll be taking a deeper look at the audit subsystem in this article. Read more
In May 2016, the developers of Sysdig released Falco, a tool for detecting anomalous system behavior.
Falco consists of two main components: the sysdig_probe kernel module (which Sysdig also runs on) and the daemon for writing the information it collects to the disk.
Falco tracks applications according to user-defined rules, and if any anomalies are detected, it writes the information to a standard output, syslog, or user-defined file. in their blog, the developers jokingly call Falco “…a hybrid of snort, ossec and strace,” and position it as a simple IDS that puts almost no additional load on the system.
Today we’ll be continuing our containerization blog series with a discussion about runC, a tool for launching containers according to Open Container Initiative (OCI) specifications. The initiative’s mission is to develop a single standard for containerization technology and is supported by such companies as Facebook, Google, Microsoft, Oracle, EMC, and Docker. The OCI Runtime Specifications were published in the summer of 2015.
Modern containerization tools already implement runC. The latest versions of Docker (starting with version 1.11) have been made according to OCI specifications and are built on runC. The libcontainer library, which is essentially a part of runC, has replaced LXC in Docker as of version 1.8.
In this article, we’ll show you how you can create and manage containers using runC.
We’ve already touched on the issue of processing events in real time. Today, we’re going to return to this topic and talk about a fairly new and interesting tool: the streaming DBMS PipelineDB.
PipelineDB is built on and fully compatible with the PostgreSQL 9.4 codebase. It was first released in June 2015 and the enterprise version came out in January 2016.
Below, we’ll compare PipelineDB with similar solutions, give brief installation and initial setup instructions, and also look at a use case.
In previous posts, we looked at various issues related to monitoring, collecting, and saving metrics and different methods and tools for getting around them. In today’s article, we’ll be discussing yet another tool that simplifies these processes: Netdata.
Unlike other analytical tools, Netdata is designed for gathering and visualizing metrics in real time (and when necessary, a backend can be incorporated for gathering and saving collected metrics).
Last year marked a milestone in the world of Internet technology: the confirmation and standardization of HTTP/2. Popular web servers like Apache and Nginx already support HTTP/2, as do the latest versions of most browsers.
Data shows that by the middle of 2015, very few web sites and services had switched to HTTP/2, only 0.4%. The latest statistics (September 2016) show a significant increase: from 0.4 to 10%. It wouldn’t be that wild a prediction to say more and more sites are going to be making the switch and at a faster rate.
Today we’d like to continue our blog series on containerization. As our first two articles (1 and 2) were dedicated to theory, this post will focus on one tool and its features: LXD.
LXD (short for Linux Container Daemon) was created by Stéphane Graber, who works for Canonical. His name is well known in the professional community as he is also one of the authors of another popular container solution: LXC. Naturally, LXD is built on LXC, which makes it easier to work with containers and adds a wide range of new abilities.
In our previous article, we explored problems tracing and profiling the Linux kernel.
Today, we’d like to revisit these issues and talk about an interesting kernel tracer, LTTng, which was developed by Canadian programmer and researcher Matthew Donahue. With this tool, we can receive information on events that occur in both the kernel and user spaces.
There are a number of tools for analyzing events at the kernel level: SystemTap, ktap, Sysdig, LTTNG, etc., and you can find plenty of detailed articles and materials about these on the web.
You’ll find much less information on Linux’s native mechanism for tracing system events and retrieving/analyzing troubleshooting information. That would be ftrace, the first tracing tool added to the kernel, and this is what we’ll be looking at today. Read more