Bring your own filesystem (BYOF) attacks have become increasingly common. In a BYOF attack, an attacker delivers payloads to a target, as it minimizes their footprint and system-level interactions. From a practical perspective, how would (or could a system designer) defend against these attacks? Even more so, how can a system designer implement proper defenses to even prevent similar types of attacks in the future without just trying to plug all the possible holes retroactively.
Read MoreMost security mechanisms in Linux are focused on protecting users while the system is powered on. This makes sense, since most computing happens while the computer is powered on, but there is an entire class of attacks that can occur while the system is off. Imagine an attacker removes the hard drive, makes changes to it, and replaces it. How can we detect and defend the operating system’s code against such an attack? The answer is by using a of file system integrity scheme. (The more general problem of preventing an attacker from changing user data or extracting secrets is a discussion for another time.)
Read MoreLet’s begin with a simple question: How are files accessed, and what steps are involved?
We can all agree data access has become ingrained in daily life. However, we don’t give much thought to where that data lives or the process that occurs before we see it. This is an intentional abstraction meant to limit the basic knowledge necessary to perform most data-related tasks. The Linux variant of this is called the Virtual Filesystem, or VFS for short. The VFS acts as the interface between the user and the file’s backing filesystem, masking any implementation details behind generic calls such as `open()`, `read()`, `write()`, etc.
Read MoreThere is no silver bullet to security, and even more importantly, there is no single source of truth for what security options are available, what they do, and what impacts they have, or even how they all work together.
In this post, we will enumerate the many security mechanisms that can be operationally deployed in an embedded system running Linux in order to secure that system from common software attacks. While the traditional approach to security relies on the CIA triad of confidentiality, integrity, and availability, the majority of this post is primarily focused on the principles and enforcement of integrity.
Read MoreDon’t get upset.
We fully acknowledge that the hard-working people who make enterprise type Linux distributions want to help their customers achieve secure systems and they strive to improve the security posture of their distributions all the time.
However, there are two major areas where these developers run up against a nearly insurmountable wall.
First, they use a different threat model. An enterprise distribution of Linux is designed with a threat model suited to datacenter/cloud deployments, but embedded and cyber-physical systems face a wider array of threats including situations where the attacker may have physical access to the system.
Second…
Read MoreStar Lab has long believed that Secure by Design is the best strategy for approaching security problems. To understand why this principle guides our work, you first need to understand the difficult class of problems we hope to address.
Read MoreOne question we frequently get is “Why would I use something like Titanium Security Suite, instead of other Linux Security Modules (LSMs) like SELinux or AppArmor?”. In short, there’s no reason you can’t use both. SELinux and Titanium primarily differ in their threat model, concept of operations (CONOPS), and flexibility.
Read MoreAchieving memory safety is hard. Code is written by humans, and humans are bound to make mistakes. Tack on pointer arithmetic and strict aliasing and the situation only becomes more complex. ZDNet recently posted an article stating that 70 percent of all (Microsoft) security bugs are memory safety issues, and I would guess that this statistic is not specific to Microsoft. In LLVM 3.1 and in GCC 4.8, the compilers introduced the -fsanitize=address option and the asan libraries for user-space applications to be built with the Address Sanitizer.
There are many great tools that are useful for debugging the Linux kernel, including good old-fashioned printk, ftrace, and kgdb. In this post we’ll be exploring how to use the kernel debugger (kgdb) to debug a QEMU VM, although some of the techniques below may be applied to debugging via hardware interfaces like JTAG. Using gdb as a front-end for the kernel debugger allows us to debug the kernel in the familiar and powerful debugging interface of gdb.
