#stack smashing

Today, I´d like to talk about some security features that either come standard with the Linux kernel, or can be compiled in as desired.

First on the list is the use of discretionary access controls. In Linux, this is handled through the use of users, groups, and permission bits. With some exceptions (notably NTFS and FAT), Linux-supported filesystems allow meta-information to be prepended to file entries that denote who can do what with a given file or directory, and this is represented by the aforementioned permission bits; any file can be specified as readable, writable, or executable (or any combination of the three) to three groups - the owner of the file, members of the single group mentioned in the file’s permissions, and any user of the system at all. This model of access control enables a file to enforce (through kernel-defined policy and the filesystem driver itself) exactly how visible and ‘touchable’ it is to anyone sharing a system. The notable exception to file access controls is the superuser; while ordinarily the owner of a file has powers over the permission bits of a file they own, the superuser in most standard Linux control models is empowered with unfettered access to the system and can ignore, at discretion, permission requirements. The superuser can modify any file, including that file’s permissions, regardless of user or group ownership, which is more-or-less necessary to maintain a system.

The second thing I’d like to mention is the netfilter framework, or more specifically the iptables system. Iptables’ game is packet filtering and manipulation at specific points in their routing, enabling a software firewall of sorts (although iptables can do more than just function as a firewall, but that’s outside of the scope of this post). Iptables compiles into the Linux kernel, and most package-managed distributions provide some variation on arno-iptables-firewall, which is a script that enables an indirect, fairly simple method of leveraging iptables’ firewalling capabilities; traffic is allowed or denied on the basis of predefined allowed ports.

Second-to-last, we have the Linux Unified Key system. LUKS uses a prepended header that contains meta-information about an encrypted volume or block device, and works with the dm-crypt module to provide transparent access to encrypted volumes. LUKS fulfils goals of portability and usability through its use of standardization, backup-able headers, and keyslots. Standardization allows a LUKS device to be used anywhere LUKS is supported, header backups enable volumes what would otherwise be lost to be restored without writing or reading more than a few megabytes of data (likely closer to a few KB), and the use of keyslots allow multiple passhprases and easy passphrase assignment/revocation while isolating the master passphrase of a volume. Using a LUKS device is as easy as decrypting it with your passphrase, which creates a usable virtual block device that manages writing to and reading from the volume, and ‘destroying’ a LUKS device is as easy as writing over the first few megabytes of the physical volume or partition with random values, eradicating the header and rendering it functionally unreadable save to those who would waste too much time on it.

Lastly, I’d like to mention two options that can be specified before compiling a kernel (not necessarily just Linux, on this one), namely strong stack protection (a ‘canary’, if you will) and address space layout randomization. GCC’s stack protection uses a randomly-selected machine word on top of a stack for the purpose of detecting overflow; operations on the stack trigger a comparison between the value of the canary on the stack and the known value of that canary (or in other implementations, the entropy used to generate the canary). If they differ, that is an indication that something has gone wrong. Address space layout randomization accomplishes exactly what it sounds like, with the IEEE stating that “ASLR works by randomizing the offset of key program segments in virtual memory, making it difficult for an attacker to derive the addresses of specific code objects and consequently redirect the control flow to this code.” If you deign to read through the sources, you will see that this is not without its flaws (although unfortunately, the IEEE chooses to paywall).

Sources and Extra Reading:

https://www.linux.com/learn/overview-linux-kernel-security-features

https://www.booleanworld.com/depth-guide-iptables-linux-firewall/

https://gitlab.com/cryptsetup/cryptsetup

https://wiki.osdev.org/Stack_Smashing_Protector