{"id":10943,"date":"2020-09-11T05:00:00","date_gmt":"2020-09-11T03:00:00","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=10943"},"modified":"2020-09-13T11:55:21","modified_gmt":"2020-09-13T09:55:21","slug":"behind-the-scenes-of-modern-operating-systems-security-through-isolation-part-1","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/09\/11\/behind-the-scenes-of-modern-operating-systems-security-through-isolation-part-1\/","title":{"rendered":"Behind the scenes of modern operating systems \u2014 Security through isolation (Part 1)"},"content":{"rendered":"

In recent years, since the Internet has become available to almost anyone, application and runtime security is important more than ever. Be it an (unknown) application you download and run from the Internet or some server application you expose to<\/em> the Internet, it’s almost certainly a bad idea to run apps without any security restrictions applied:
\n
\nUnknown (untrusted) applications from the Internet could well include some malware trying to steal data from you. Server applications can even be attacked remotely by triggering security vulnerabilities such as buffer overflows, file inclusion bugs and what not.
\nWhile most solutions such as using multiple devices (or using a dedicated device for each process you would normally run on your PC) are impractical and cumbersome to use, other techniques such as application sandboxing \u2014 which we will explore later on \u2014 exist.<\/p>\n

The problem here is that applications (by default) can access data and use operating system functionality they should better not be able to use; The trojan horse you just downloaded can easily access your photos and other kinds of sensitive data stored on your PC or inject itself to your browser and steal money while you’re performing some bank transactions over there. The server application you expose to the Internet can run arbitrary code<\/em> after a buffer overflow was triggered in it and pretty much cause the same harm as any other kind of malware.<\/p>\n

\"xkcd's
\n(Source: https:\/\/xkcd.com\/1957\/<\/a>)<\/p>\n

This is the first of two posts on the security of modern operating systems. This part lays and explains the groundwork of security in the Linux Kernel.<\/p>\n

Part two<\/a> shows how the security mechanisms introduced in this post can be combined to create containerization platforms such as Docker and OS-level application isolation techniques such as LXC; It as well introduces other kinds of isolation techniques such as virtualization.<\/p>\n

Sandboxing<\/h2>\n

The idea behind application sandboxing is simple: A sandboxed application (which in fact is a process) is isolated<\/em> from all other processes running on a PC. It can only cause harm to anything inside its sandbox and this sandbox should only include the bare-minimum data and functionality required to run the application.<\/p>\n

Probably the<\/em> sandbox in most common use (and even active on your PC right now) is inside your browser! Modern browsers such as Firefox isolate all tabs from one another and only allow communication between them through specially crafted communication interfaces.<\/p>\n

\"Sandboxing\"<\/p>\n

Sandboxing \u2014 if implemented correctly \u2014 is a great solution to the problem from our introduction in that it allows to use a single PC for running multiple processes without any security implications.
\nBut how is sandboxing actually achieved in modern operating systems? Let’s find out!<\/p>\n

Security in the Linux Kernel<\/h2>\n

Most servers on the Internet use Linux as their operating system kernel and modern containerization platforms such as Docker currently only run on Linux, Linux is open source<\/a> and has the most active development community and companies behind it (source 1<\/a>, source 2<\/a>). That’s why we want to take a deeper look into its inner workings and explore the security mechanisms provided by Linux.<\/p>\n

chroot \u2014 change root<\/h3>\n

One of the features to sandbox applications (which by the way is supported by almost all UNIX-descendants, including BSD and System V) has been in Linux since its inception \u2014 chroot<\/em>.
\nchroot<\/em> is a system call allowing the kernel to set the apparent root directory of a process; chroot<\/em>-jailed processes see a different file system view than other processes.<\/p>\n

Let’s take a look at the following file system view to better illustrate how a chroot<\/em> actually works. Suppose you have the following files on your drive:<\/p>\n

\/\n\u251c\u2500\u2500 bin\n\u2502   \u251c\u2500\u2500 sh\n\u2502   \u2514\u2500\u2500 \u2026\n\u251c\u2500\u2500 dev\n\u2502   \u251c\u2500\u2500 null\n\u2502   \u2514\u2500\u2500 random\n\u251c\u2500\u2500 home\n\u2502   \u251c\u2500\u2500 artur\n\u2502   \u2502   \u2514\u2500\u2500 arturs_file\n\u2502   \u2514\u2500\u2500 leon\n\u2502       \u2514\u2500\u2500 leons_file\n\u2514\u2500\u2500 root\n<\/code><\/pre>\n
In order to create a chroot<\/em> jail for a process with a different file system view, such a “view” must exist. This simply means all necessary files required to launch an operating system such as Debian must exist in some sub-folder on the file system. This might look as follows (see the chroot<\/code> folder):<\/p>\n
\/\n\u251c\u2500\u2500 bin\n\u2502   \u251c\u2500\u2500 sh\n\u2502   \u2514\u2500\u2500 \u2026\n\n\u251c\u2500\u2500 chroot # <-- This is where our chroot-ed process will "live"\n\u2502   \u251c\u2500\u2500 bin\n\u2502   \u2502   \u251c\u2500\u2500 sh\n\u2502   \u2502   \u2514\u2500\u2500 \u2026\n\u2502   \u251c\u2500\u2500 dev\n\u2502   \u251c\u2500\u2500 home\n\u2502   \u2502   \u2514\u2500\u2500 peter\n\u2502   \u2502     \u2514\u2500\u2500 peters_file\n\u2502   \u2514\u2500\u2500 root\n\n\u251c\u2500\u2500 home\n\u2502   \u251c\u2500\u2500 artur\n\u2502   \u2502   \u2514\u2500\u2500 arturs_file\n\u2502   \u2514\u2500\u2500 leon\n\u2502       \u2514\u2500\u2500 leons_file\n\u2514\u2500\u2500 root\n<\/code><\/pre>\n
Let’s spawn a new \/bin\/sh<\/code> shell and chroot<\/em> it to \/chroot<\/code>:<\/p>\n
# These three commands are required to mount all the\n# necessary virtual file systems to the chroot jail.\n$ sudo mount -o bind \/dev \/chroot\/dev\n$ sudo mount -o bind \/proc \/chroot\/proc\n$ sudo mount -o bind \/sys \/chroot\/sys\n\n# This command spawns a new \/bin\/sh shell and chroot's\n# it to \/chroot\n$ sudo chroot \/chroot \/bin\/sh\n\n# From now on we\u2019re using the new shell inside the chroot jail\n\n# Quick verification\u2026\n$ tree \/home\n.\n\u2514\u2500\u2500 peter\n\u2514\u2500\u2500 peters_file\n\n# Success! The shell we're using right now can't see\n# "artur"s and "leon"s home!\n<\/code><\/pre>\n
A chroot<\/em>-jailed process can create new files only in his jail:<\/p>\n
# From the chroot-jailed process\u2026\n$ touch \/testfile\n<\/code><\/pre>\n
Our file system now looks as follows:<\/p>\n
\/\n\u251c\u2500\u2500 bin\n\u2502   \u251c\u2500\u2500 sh\n\u2502   \u2514\u2500\u2500 \u2026\n\n\u251c\u2500\u2500 chroot\n\u2502   \u251c\u2500\u2500 bin\n\u2502   \u2502   \u251c\u2500\u2500 sh\n\u2502   \u2502   \u2514\u2500\u2500 \u2026\n\u2502   \u251c\u2500\u2500 dev\n\u2502   \u251c\u2500\u2500 home\n\u2502   \u2502   \u2514\u2500\u2500 peter\n\u2502   \u2502     \u2514\u2500\u2500 peters_file\n\u2502   \u251c\u2500\u2500 root\n\u2502   \u2514\u2500\u2500 testfile # <----- The new file\n\n\u251c\u2500\u2500 home\n\u2502   \u251c\u2500\u2500 artur\n\u2502   \u2502   \u2514\u2500\u2500 arturs_file\n\u2502   \u2514\u2500\u2500 leon\n\u2502       \u2514\u2500\u2500 leons_file\n\u2514\u2500\u2500 root\n<\/code><\/pre>\n
chroot<\/em>-capable directories can either created by hand or automatically by tools like debootstrap<\/code>. debootstrap<\/code> can be used to easily set up a Debian system:<\/p>\n
$ sudo debootstrap stable \/chroot https:\/\/deb.debian.org\/debian\/\nI: Target architecture can be executed\nI: Retrieving InRelease\nI: Checking Release signature\nI: Valid Release signature\nI: Retrieving Packages\nI: Validating Packages\nI: Resolving dependencies of required packages...\nI: Resolving dependencies of base packages...\nI: Checking component main on https:\/\/deb.debian.org\/debian...\nI: Retrieving libacl1 2.2.53-4\nI: Validating libacl1 2.2.53-4\nI: Retrieving adduser 3.118\nI: Validating adduser 3.118\nI: Retrieving libapparmor1 2.13.2-10\nI: Validating libapparmor1 2.13.2-10\nI: Retrieving apt 1.8.2\nI: Validating apt 1.8.2\n# \u2026\nI: Configuring systemd...\nI: Configuring ca-certificates...\nI: Base system installed successfully.\n\n$ ls -la \/chroot\/\ndrwxr-xr-x 17 root root 4096 Jun 21 08:31 .\ndrwxr-xr-x  1 root root 4096 Jun 21 08:30 ..\nlrwxrwxrwx  1 root root    7 Jun 21 08:30 bin -> usr\/bin\ndrwxr-xr-x  2 root root 4096 May  2 16:39 boot\ndrwxr-xr-x  4 root root 4096 Jun 21 08:30 dev\ndrwxr-xr-x 48 root root 4096 Jun 21 08:31 etc\ndrwxr-xr-x  2 root root 4096 May  2 16:39 home\nlrwxrwxrwx  1 root root    7 Jun 21 08:30 lib -> usr\/lib\nlrwxrwxrwx  1 root root    9 Jun 21 08:30 lib32 -> usr\/lib32\nlrwxrwxrwx  1 root root    9 Jun 21 08:30 lib64 -> usr\/lib64\nlrwxrwxrwx  1 root root   10 Jun 21 08:30 libx32 -> usr\/libx32\ndrwxr-xr-x  2 root root 4096 Jun 21 08:30 media\ndrwxr-xr-x  2 root root 4096 Jun 21 08:30 mnt\ndrwxr-xr-x  2 root root 4096 Jun 21 08:30 opt\ndrwxr-xr-x  2 root root 4096 May  2 16:39 proc\ndrwx------  2 root root 4096 Jun 21 08:30 root\ndrwxr-xr-x  3 root root 4096 Jun 21 08:30 run\nlrwxrwxrwx  1 root root    8 Jun 21 08:30 sbin -> usr\/sbin\ndrwxr-xr-x  2 root root 4096 Jun 21 08:30 srv\ndrwxr-xr-x  2 root root 4096 May  2 16:39 sys\ndrwxrwxrwt  2 root root 4096 Jun 21 08:31 tmp\ndrwxr-xr-x 13 root root 4096 Jun 21 08:30 usr\ndrwxr-xr-x 11 root root 4096 Jun 21 08:30 var\n<\/code><\/pre>\n
chroot<\/em> forms the basis of every application sandbox in that it enabled different processes to see different files. However, chroot<\/em>s by themselves do not<\/strong> provide any security against malicious attacks. This is due to the fact that the root<\/code> user inside<\/em> the jail has the same user id as the root<\/code> user outside<\/em> of it. Escaping<\/a> a chroot<\/em> jail without any additional restrictions is quite easy!<\/p>\n
If implemented correctly, a chroot<\/em>ed process can not see files outside of its chroot<\/em>, yet a malicious or misbehaving application can still harm the system by e.g. exhausting the system’s hardware resources or accessing network interfaces when they shouldn’t \u2014 additional security mechanisms are required to prevent that!<\/p>\n
namespaces<\/h3>\n
Support for namespaces<\/em> was added to the Linux Kernel back in 2002. namespaces<\/em> affects which system resources<\/strong> a process can see<\/em> and interact<\/em> with. As of the most recent Kernel v5.8, this includes the following 8 system resource types:<\/p>\n