{"id":10949,"date":"2020-09-11T05:59:42","date_gmt":"2020-09-11T03:59:42","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=10949"},"modified":"2023-08-06T21:44:08","modified_gmt":"2023-08-06T19:44:08","slug":"behind-the-scenes-of-modern-operating-systems-security-through-isolation-part-2","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-2\/","title":{"rendered":"Behind the scenes of modern operating systems \u2014 Security through isolation (Part 2)"},"content":{"rendered":"

If you have not read the first part<\/a>, we recommend that you read it first. It covers the topics sandboxing and isolation using Linux kernel features. In this part we go one step further and show more tools \u2014 based on part one<\/a> \u2014 that are used and find their way into a modern operating system.<\/p>\n

<\/p>\n

Containerization<\/h2>\n

Container technology in application development has long been established. Containers make applications less tied to the runtime environment in which they run. They also only have a small overhead and the performance is close to bare-metal. Another benefit of containers is fast provisioning and deployment, the reproducible image build and especially the reduction of hardware and energy costs. Basically, hardware still matters in any case. Containers do not have their own Kernel, all of them rely on the underlying host system on which those are installed. This is also called operating system virtualization with containers<\/em>.<\/p>\n

Containers are considered resource-efficient, easily scalable and quickly replaceable. Due to the fact that containers run on the underlying host system this means that every single one also shares the same host kernel through the container engine. In general, they have several isolated user spaces. They look like real computers, but they are not. Instead of virtualizing all the physical hardware, containers only virtualize the software stack sitting on the kernel \u2014 this increases performance. This also means that only the data and peripherals that have been assigned to a container can be seen by it \u2014 which can be considered as a sandbox method. Therefore, not every containerized application should have access to hardware components like the block device, CPU or LAN. In this context, container runtimes are generally based on the kernel features, such as namespaces (UTS, IPC, etc.) to isolate or virtualize system resources, cgroups for resource limitation and other virtual environment methods.[1]<\/p>\n

LXC<\/h3>\n

\"LXC
\nSource: https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/containers.png<\/p>\n

With this background, the focus is initially on container virtualization through LXC (Linux Container) a low-level container runtime using liblxc<\/em>.[2] LXC makes use of multiple security kernel features brought up in the first blogpost<\/a>. As mentioned before, the underlying approach of a shared host kernel also applies here.<\/p>\n

\"LXC<\/p>\n

LXC sits in the middle of an isolated chroot and a virtual machine. This allows system resources at the host operating system level to be divided in a process-oriented manner.[3] Security was not at all considered in the early development of LXC, so the following problems may occur: LXC supports all the security features of the Linux Kernel but uses bad default configuration options and some features like capabilities are not even turned on by default. When a container throws a fatal system error this also occurs on the host (as it\u2019s the exact same kernel) \u2014 which can lead to a kernel panic.[4]<\/p>\n

\"fatal
\nSource: https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/8C8g.gif<\/p>\n

From kernel version 3.12 and LXC version 1.0, it is possible to start an LXC container using a different user ID (UID) than the root<\/em> user (UID = 0). A few variables have to be set in the configuration file like this:<\/p>\n

## Config for all container\n# \/etc\/lxc\/default.conf\n## Config for existing container\n# \/var\/lib\/lxc\/your_containername\/config\n\n## Container\nlxc.uts.name = your_containername\nlxc.idmap = u 0 100000 10000\nlxc.idmap = g 0 100000 10000\nlxc.rootfs = \/var\/lib\/lxc\/your_containername\/rootfs\nlxc.tty = 2\nlxc.pts = 1024\nlxc.console = \/var\/log\/lxc\/your_containername.console\n\n## Capabilities\n# Drop all capabilities for a more security focused container\nlxc.cap.drop = mac_admin mac_override sys_admin sys_module\n\n## CGroups\n# Deny all devices\nlxc.cgroup.devices.deny = a\n# ... and allow only specific devices\nlxc.cgroup.devices.allow = c 1:3 rwm # \/dev\/null\nlxc.cgroup.devices.allow = c 1:5 rwm # \/dev\/zero\nlxc.cgroup.devices.allow = c 1:8 rwm # \/dev\/random\nlxc.cgroup.devices.allow = c 1:9 rwm # \/dev\/urandom\nlxc.cgroup.devices.allow = c 5:0 rwm # \/dev\/tty\nlxc.cgroup.devices.allow = c 5:1 rwm # \/dev\/console\n...\n\n## Limits\nlxc.cgroup.cpuset.cpus = 0,1\nlxc.cgroup.cpu.shares = 2048\nlxc.cgroup.cpuset.cpus = 2\nlxc.cgroup.memory.limit_in_bytes = 1024M\n...\n\n## Filesystem\nlxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0\nlxc.mount.entry = sysfs sys sysfs defaults,ro 0 0\n...\n\n## Network\n# lxc.network.type = empty\nlxc.net.0.type = veth\nlxc.net.0.flags = up\nlxc.net.0.link = br0\nlxc.net.0.hwaddr = FF:00:00:FF:00:00\nlxc.net.0.ipv4 = 10.2.3.4\n\u2026\n<\/code><\/pre>\n
Docker<\/h3>\n
In addition to LXC, Docker containerization is used for a closer look. LXC focuses on containers for complete operating systems, Docker has its focus on modular containers for individual and rather lightweight applications.<\/p>\n
\"Docker
\nSource: https:\/\/www.docker.com\/company\/newsroom\/media-resources<\/p>\n
In the early stages of Docker, it was based on LXC. Nowadays it uses the runC<\/em> and containerd<\/em> runtime. Furthermore, in contrast to LXC, Docker has a container engine sitting in between the host operating system and its containers. The Docker Engine provides a simple tooling and feature approach with distribution, orchestration, networking and much more for building and containerizing applications.[5]<\/p>\n
\"Docker<\/p>\n
Thus, Docker still shares the same weaknesses as LXC. It uses a root-owned daemon by default. Binaries in Docker containers by default run in a root-privileged mode and the containers are executed with all<\/em> capabilities. Therefore, only authorized users should have access to it and for additional security, the capabilities should also be restricted to a bare-minimum. A Dockerfile contains commands to build a Docker image. In the Dockerfile<\/code> first a new group<\/em> and a new user<\/em> with an ID equal or greater<\/em> than 1000 are created.<\/p>\n
FROM alpine:latest\nWORKDIR \/app\nRUN addgroup -g 1000 -S app && adduser -u 1000 -S app -G app\nCOPY --from=builder \/app\/bin\/server .\nUSER app\nCMD [ "\/app\/server" ]\n<\/code><\/pre>\n
In addition to the Dockerfile<\/code>, the docker-compose.yml<\/code> exists. This contains services to manage the Docker image. In order to restrict the container capabilities, all capabilities are first dropped and only those that are actually required are granted (allow list-approach).<\/p>\n
version: "3"\nservices:\n  demoapp:\n    build:\n      context: ${DEMOAPP:-.}\n      dockerfile: Dockerfile\n    restart: unless-stopped\n    ports:\n      - "80:80\/tcp"\n\ncap_drop:\n  - ALL\n\ncap_add:\n  - NET_BIND_SERVICE\n  - CHOWN\n  - SETUID\n  - SETGID\n<\/code><\/pre>\n
Virtualization<\/h2>\n
Containers make applications more independent of the environment in which they are run. While all containers share the kernel of their host, VMs contain their own kernel. This means with a kernel panic, the underlying host kernel does not crash. The concept of virtualization has existed for a very long time \u2014 longer than containers \u2014 and those techniques were used primarily in mainframes before they found their way to the personal computer.<\/p>\n
Unlike containers, in VMs, hardware must be virtualized. This of course has a negative impact on performance. The main advantages of virtualization, which differ from containers, last that they are fully isolated which makes them more secure. For workloads that require a non-Linux operating system or a specialized Linux kernel, virtualization remains the only option. Virtualization thus offers the possibility of testing different operating systems using different kernels with little effort.[1]<\/p>\n
Hypervisor<\/h3>\n
The hypervisor \u2014 also known as the Virtual Machine Monitor (VMM) \u2014 creates and manages virtual machines within a system. Typically, a hypervisor provides all<\/em> interfaces within the virtual machines. It\u2019s a software layer between the native hardware or the host operating system and the virtual machine that interacts with this resource. At the same time, it provides an abstraction layer that prevents drivers from directly accessing the hardware. This ensures that different operating systems do not interfere with each other. A distinction is made between two different types of hypervisors: type 1<\/em> and type 2<\/em>. In the previous sections we looked at architectures with an underlying host operating system. So let’s start with the type 2 hypervisor.[1]<\/p>\n
Type 2<\/h4>\n
A type 2 hypervisor is based on a native operating system and uses all resources that are available to it. The host OS provides the virtual environment for the hypervisor that also includes the virtualized driver for network, storage and other controllers. This is for example provided through libvirt<\/em>, a virtualization API. Two of the main players in the VM-business are VirtualBox and VMware.[1]<\/p>\n
\"Hypervisor<\/p>\n
Type 1<\/h4>\n
A type 1 hypervisor acts directly on the native hardware. Without the overhead of an operating system on top of it, the overall system hence consumes fewer resources than a type 2 hypervisor. The main difference to type 2 is that a type 1 hypervisor needs its own drivers for the hardware. Main players using type 1 are Hyper-V, KVM and Xen.[1]<\/p>\n
\"Hypervisor<\/p>\n
We have now illuminated mechanisms for more security through isolation using various kernel features on containers and virtual machines. Now it’s time to get to know the first of two operating systems that consists almost entirely of virtual machines.<\/p>\n
Qubes OS<\/h2>\n
\"Qubes
\nSource: https:\/\/www.qubes-os.org\/<\/p>\n
Qubes OS appeared with its first release on the wider distribution market back in 2012.[6] The idea behind Qubes OS differs from classic operating systems: It\u2019s a free and open source security-oriented desktop operating system that promises to provide security through isolation. In Qubes OS, isolation is achieved through virtualization and various system-specific security concepts. The isolation starts with individual processes so that the underlying system is not directly affected by a security vulnerability. Qubes OS aims to prevents vulnerabilities from causing malicious software to take control of the whole machine.[7]<\/p>\n
Instead of using a monolithic kernel as a basis, Qubes OS is based on the Xen hypervisor (type 1). On top of the hypervisor sits the AdminVM<\/em> aka. the dom0<\/em> interface. In Xen is dom0 a privileged domain which controls the domU<\/em> domains. These domains are virtual machines and called qubes<\/em> in Qubes OS. Those qubes could consist of Fedora, Whonix, Debian or Windows. These VMs are completely separated from each other which Qubes OS calls \u201cseparation through isolation\u201d.[7]<\/p>\n
\"Qubes
\nSource: https:\/\/www.qubes-os.org\/news\/2017\/10\/03\/core3\/<\/p>\n
So all qubes are separated from each other. The AdminVM controls an X server with a window manager (xfce) based on the GUI VM<\/em>. Here the individual qubes can be started. They bind all the qubes, with different levels of trust divided into colors.[8] If a new qube needs to be created, e.g. for online banking, the Qubes VM Manager<\/em> can be used for an overview and to create, edit or delete it.<\/p>\n
\"Qubes
\nSource: https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/qubes_manag_large.png<\/p>\n
The following screenshot shows how to start a specific application of a certain qube by a few mouse clicks from the taskbar.<\/p>\n
\"Qubes
\nSource: https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/qubes_menu-1.png<\/p>\n
While working, a file should be opened via e-mail or via the file manager. However, this file is not trustworthy, but it can still be opened in a DisposableVM<\/em> without any major concern. A DisposableVM is a qube in which questionable data can be viewed in more detail. If the file contains a virus and the qube is compromised, it is not so destructive for the whole system or the qube where we are working. Closing the disposable qube will completely delete this temporary created VM.<\/p>\n
\"Qubes
\nSource: https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/qubes_pdf1.png<\/p>\n
On the whole, Qubes OS makes use of the Xen hypervisor and its own tools, which makes it easier to handle various isolated VMs. The encapsulation and separation of the individual qubes make you feel a little more secure.<\/p>\n
\u201cOf course, consolidating servers like this is like putting all of your eggs in one basket. […] The reason virtualization works however, is that most service outages are not due to faulty hardware, but due to bloated, unreliable, buggy software, especially operating systems.\u201d<\/em> [1]<\/p><\/blockquote>\n
Fuchsia<\/h2>\n
\"Fuchsia
\nSource: https:\/\/github.com\/fuchsia-mirror<\/p>\n
While Qubes OS is based on Xen hypervisor with isolation through virtualization, Fuchsia relies with the Zircon microkernel on a capability-oriented distribution. The Zircon kernel is primarily designed to run on \u201c32-bit or 64-bit ARM cores to 64-bit X86 processors\u201d<\/em>. [9]<\/p>\n
\"Fuchsia
\nSource: https:\/\/www.googlewatchblog.de\/2018\/03\/zircon-topaz-fuchsia-google\/<\/p>\n
The lowest layer starts with the Zircon<\/em> kernel, which is the interface between hard- and software. Fundamentally, this is detached from the entire Fuchsia OS. The next layer is Garnet<\/em>, which manages the drivers and communications between the above layer and Zircon. Peridot<\/em> is the first application layer, where application management, provision and the synchronization of the data happens. At the top of that sits Topaz<\/em>, which is the GUI layer. [10]<\/p>\n
\"Fuchsia
\nSource: https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/fuchsia-google-account-permissions.png<\/p>\n
With the focus on security and isolation they note that on \u201cFuchsia, a newly created process has nothing. A newly created process cannot access any kernel objects, cannot allocate memory, and cannot even execute code. Of course, such a process isn’t very useful, which is why we typically create processes with some initial resources and capabilities.\u201d<\/em> [11] Most of the capabilities must be exposed or offered in a component manifest<\/code>.[12] The main capabilities components are:<\/p>\n
    \n
  • Event capabilities<\/li>\n
  • Directory capabilities<\/li>\n
  • Protocol capabilities<\/li>\n
  • Service capabilities<\/li>\n
  • Storage capabilities [13]<\/li>\n<\/ul>\n
    To offer a service to a child component, an entry in the component manifest<\/code> could look like:<\/p>\n
    {\n  "offer": [{\n    "service": "\/svc\/fuchsia.example.ExampleService",\n    "from": "self",\n    "to": [{\n      { "dest": "#child-a" },\n      { "dest": "#child-b" },\n    }],\n  }],\n}\n<\/code><\/pre>\n
    Source: https:\/\/fuchsia.dev\/fuchsia-src\/concepts\/components\/v2\/capabilities\/service<\/p>\n
    Conclusion<\/h2>\n
    Through security vulnerabilities in hardware and software, malware can get onto the operating system. We have learned about various kernel features to make an operating system more secure. These include security mechanisms such as the isolation of software components for the secure execution of computer applications in an encapsulated system environment. This sandbox model is originally used to run untrusted code, unreliable software, or to open questionable documents. The basic idea is that no program (process) can access data outside its sandbox. One approach is to create an operating system based on security through isolation with virtual machines (which is far from lightweight). Another approach is a capability-based operating system using a microkernel called Zircon, which is still under heavy development. Beyond that, Theo de Raad states that \u201cYou are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can’t write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.\u201d<\/em> [14] At least these techniques make us feel more secure.<\/p>\n
    Sources<\/h2>\n
    All links were last accessed on 2020-09-08.<\/p>\n
      \n
    1. Andrew S. Tanenbaum. 2009. Modern Operating Systems (3rd. ed.). Pearson Education<\/li>\n
    2. https:\/\/github.com\/lxc\/lxc<\/li>\n
    3. https:\/\/linuxcontainers.org\/lxc\/introduction<\/li>\n
    4. https:\/\/linuxcontainers.org\/lxc\/security<\/li>\n
    5. https:\/\/docs.docker.com\/get-started\/overview\/<\/li>\n
    6. https:\/\/www.qubes-os.org\/doc\/supported-versions\/<\/li>\n
    7. https:\/\/www.qubes-os.org\/faq\/<\/li>\n
    8. https:\/\/www.qubes-os.org\/doc\/<\/li>\n
    9. https:\/\/lwn.net\/Articles\/792465<\/li>\n
    10. http:\/\/www.googlewatchblog.de\/2018\/03\/zircon-topaz-fuchsia-google\/<\/li>\n
    11. https:\/\/fuchsia.googlesource.com\/fuchsia\/+\/refs\/heads\/master\/docs\/concepts\/framework\/sandboxing.md<\/li>\n
    12. https:\/\/fuchsia.dev\/fuchsia-src\/concepts\/components\/v2\/component_manifests.md#expose<\/li>\n
    13. https:\/\/fuchsia.dev\/fuchsia-src\/concepts\/components\/capabilities<\/li>\n
    14. https:\/\/marc.info\/?l=openbsd-misc&m=119318909016582<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
      If you have not read the first part, we recommend that you read it first. It covers the topics sandboxing and isolation using Linux kernel features. In this part we go one step further and show more tools \u2014 based on part one \u2014 that are used and find their way into a modern operating […]<\/p>\n","protected":false},"author":1001,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1,26],"tags":[376,61,375,4,377,378],"ppma_author":[818],"class_list":["post-10949","post","type-post","status-publish","format-standard","hentry","category-allgemein","category-secure-systems","tag-capabilities","tag-containers","tag-kernel-functions","tag-linux","tag-operating-system","tag-virtualization"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":27,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2015\/12\/17\/27\/","url_meta":{"origin":10949,"position":0},"title":"Docker- dive into its foundations","author":"Benjamin Binder","date":"17. December 2015","format":false,"excerpt":"Docker has gained a lot of attention over the past several years.\u00a0But not only because of its cool logo or it being\u00a0the top buzzword of managers, but also because of its useful features.\u00a0We talked about Docker quite a bit without really\u00a0understanding why it's so\u00a0great to use. So we decided to\u2026","rel":"","context":"In "Databases"","block_context":{"text":"Databases","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/databases\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":10943,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/09\/11\/behind-the-scenes-of-modern-operating-systems-security-through-isolation-part-1\/","url_meta":{"origin":10949,"position":1},"title":"Behind the scenes of modern operating systems \u2014 Security through isolation (Part 1)","author":"Leon Klingele","date":"11. September 2020","format":false,"excerpt":"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 the Internet, it's almost certainly a bad idea to run\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":25110,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2023\/07\/30\/fuchsia-rethinking-os-security-design-after-50-years\/","url_meta":{"origin":10949,"position":2},"title":"Fuchsia: Rethinking OS security design after 50 years","author":"Nikolai Thees","date":"30. July 2023","format":false,"excerpt":"Ever since the inception of Unix in the 1960s, the core design of most general purpose operating systems we use today has remained largely unchanged. However, over time, many of the security principles established during that era have since been deemed outdated. In this article, we will look into Google's\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/fuchsia_cover-1.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/fuchsia_cover-1.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/fuchsia_cover-1.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/fuchsia_cover-1.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/07\/fuchsia_cover-1.jpg?resize=1050%2C600&ssl=1 3x"},"classes":[]},{"id":27760,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2025\/07\/23\/what-distinguishes-an-enterprise-operating-system-from-your-desktop\/","url_meta":{"origin":10949,"position":3},"title":"What distinguishes an enterprise operating system from your desktop?","author":"Dominik M\u00fcller","date":"23. July 2025","format":false,"excerpt":"Note: This article was written for the module Enterprise IT (113601a) during the summer semester of 2025. Introduction An operating system (OS) manages hardware resources, enables application execution, and provides interfaces for users and developers alike. But the context in which an OS is deployed determines its form and function.\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/07\/virtual-machine-virtual-private-server-vmware-vsphere-computer-servers-virtualization-png-favpng-UZyJvXCPwqpQ9UKLEaNXgWG0m-1116791087.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/07\/virtual-machine-virtual-private-server-vmware-vsphere-computer-servers-virtualization-png-favpng-UZyJvXCPwqpQ9UKLEaNXgWG0m-1116791087.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/07\/virtual-machine-virtual-private-server-vmware-vsphere-computer-servers-virtualization-png-favpng-UZyJvXCPwqpQ9UKLEaNXgWG0m-1116791087.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/07\/virtual-machine-virtual-private-server-vmware-vsphere-computer-servers-virtualization-png-favpng-UZyJvXCPwqpQ9UKLEaNXgWG0m-1116791087.jpg?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":902,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2016\/07\/22\/defense-in-depth-a-present-time-example\/","url_meta":{"origin":10949,"position":4},"title":"Defense in Depth: a present time example","author":"Benjamin Binder","date":"22. July 2016","format":false,"excerpt":"In this post, we want to take a look on the concept of defense in depth. Therefore we are going to examine Chrome OS, the niche operation system for web users.","rel":"","context":"In "Secure Systems"","block_context":{"text":"Secure Systems","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/secure-systems\/"},"img":{"alt_text":"Dark castle walls reaching in the sky","src":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/3\/32\/Caernarfon_Castle_Walls.jpg","width":350,"height":200,"srcset":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/3\/32\/Caernarfon_Castle_Walls.jpg 1x, https:\/\/upload.wikimedia.org\/wikipedia\/commons\/3\/32\/Caernarfon_Castle_Walls.jpg 1.5x, https:\/\/upload.wikimedia.org\/wikipedia\/commons\/3\/32\/Caernarfon_Castle_Walls.jpg 2x, https:\/\/upload.wikimedia.org\/wikipedia\/commons\/3\/32\/Caernarfon_Castle_Walls.jpg 3x, https:\/\/upload.wikimedia.org\/wikipedia\/commons\/3\/32\/Caernarfon_Castle_Walls.jpg 4x"},"classes":[]},{"id":23333,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2022\/04\/01\/improve-your-storage-i-o-performance-today\/","url_meta":{"origin":10949,"position":5},"title":"Improve your storage I\/O performance today","author":"Jannik Smidt","date":"1. April 2022","format":false,"excerpt":"an article by Lucas Cr\u00e4mer and Jannik Smidt DISCLAIMER This post tries to keep the complexity manageable while making a point clear. We are not systems engineers\/kernel developers, so feel free to point out any mistakes\/misunderstandings. This post probably does not present anything new for people who are working in\u2026","rel":"","context":"In "System Architecture"","block_context":{"text":"System Architecture","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/system-architecture\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/04\/queues-e1619992851556.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/04\/queues-e1619992851556.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/04\/queues-e1619992851556.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/04\/queues-e1619992851556.png?resize=700%2C400&ssl=1 2x"},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":818,"user_id":1001,"is_guest":0,"slug":"ab278","display_name":"Artur Bergen","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/97178db99ff9b30a480245638c770332705fd48d2cfbb924a94a1840e1cf10cb?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/10949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/1001"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=10949"}],"version-history":[{"count":79,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/10949\/revisions"}],"predecessor-version":[{"id":25412,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/10949\/revisions\/25412"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=10949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=10949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=10949"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=10949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}