Atul's blogs

  The Linux kernel is the core component of the Linux operating system, responsible for managing system resources and providing a secure environment for applications to run. As the heart of the operating system, it is crucial to ensure the security of the Linux kernel to protect against potential vulnerabilities and attacks. In this blog post, we will explore some of the key security features and mechanisms implemented in the Linux kernel. 1. Secure Boot Secure Boot is a feature that ensures only trusted software is loaded during the boot process. It uses cryptographic signatures to verify the integrity of the bootloader and kernel, preventing the execution of malicious code. The Linux kernel supports Secure Boot through technologies like UEFI (Unified Extensible Firmware Interface) and TPM (Trusted Platform Module), providing a secure foundation for the entire system. 2. Address Space Layout Randomization (ASLR) ASLR is a technique that randomizes the memory layout of processes, makin

  In this short post we will explore a Linux system call facilitating secure computing. In earlier parts of this series we saw how LSMs protect the kernel. However, LSMs occupy a much deeper position in the call hierarchy and do not offer protection at process level. Additional mechanism is required to provide protection at process level. Need for a system call In Linux, applications programs use a number of system calls, in fact a large number of system calls are available to applications programmer. These processes using system calls expose a large area of the kernel to malicious attacks. Linux offers a mechanism to limit this capability using seccomp system call, thereby reducing the attack surface. seccomp is enabled using prctl() system call with appropriate operation mode. seccomp Modes The seccomp system call works in two modes - strict mode (SECCOMP_SET_MODE_STRICT) and filter mode (SECCOMP_SET_MODE_FILTER). When seccomp is set to first mode, i.e. strict mode , process has acce

  In the previous part of this series, we saw role of LSMs in kernel security. As mentioned earlier, there are eight LSMs available today in the modern Linux kernel. In this part, let's have a look at different main stream LSMs. SMACK Simplified Mandatory Access Control Kernel ( SMACK ) is designed primarily for embedded linux systems with an intention to make it easier for administrators. This was the second LSM (after SELinux) to be accepted in the linux kernel. It appeared in the 2.6.25 kernel release. This is an attribute (label) based simple LSM, and is the default for Linux implementations tuned for Automotive industry. Yama Yama collects system-wide DAC security restrictions that are not handled by the core kernel itself. It offers control over scope of ptrace() system call to control ptrace attachment by processes. Build time configuration option CONFIG_SECURITY_YAMA and runtime option through sysctls can be used to enable this LSM. The ptrace restrictions can be controll

  User-land security in Linux is pretty robust and finely ingrained into the design philosophy of the OS and inherited from the UNIX legacy. Beating at the centre of this robust OS is the equally robust heart of the OS - the Kernel. Linux User has various tools and types of security at her disposal - such as enforcement of different roles and groups with varying levels of privileges, authorisations, access control using authentications, policy enforcement and logging, secure memory and process management techniques, secure protocols and of course, trust-worthy kernel. Roughly these techniques can also be described as DACs (Discretionary Access Controls) and MACs (Mandatory Access Controls). Example of DACs is the file and directory permissions in Linux (rwx for ugo) using which access to user data can be controlled. What is the need? But how does Linux Kernel ensures and enforces security in the Kernel-land? The Kernel relies on different MAC techniques like security modules, secure co

In the previous article, we discussed what TPM means and features of TPM. In this short article we'll see applications of TPM in creating and establishing chain of trust. Establishing a tamper proof chain of trust works at two levels. First, a device is booted in a trusted manner. This device interacts with other devices which are also booted in a secure way. The second level deals with establishing "chain of trust" amongst these secure devices. It is important to note that TPM only provides required mechanism to establish root of trust, but it is entirely up to the host machine and software (which includes OS as well as application software) to establish trusted execution environment and should be capable of doing so. Let's see how this mechanism works, with the help of a simple example. Consider a simplistic IoT setup as shown in following figure. The Server At the time of boot, BIOS uses Core Root of Trust i.e. BIOS boot block which is immutable, to

In the previous article, we discussed end device security and various factors affecting it. There was a fleeting mention about TPM - the Trusted Platform Module. In this installment we will discuss mode about the TPM. Generally, for any device, the safest way to ensure it's integrity is to make sure it always boots from a secured, verified and unalterable source. This forms the logical "root" of the entire boot process. Once the device boots from a trusted source, it further uses it to verify each and every software component it utilizes. Every module checks and verifies integrity of the next module to be loaded thus forming a "chain of trust" which if broken can be easily detected. This chain of trust then can be extended to encompass other devices across and upstream the network hierarchy. In this installment, let's have a deeper look at TPM. What is TPM? TPM is (generally) a chip designed to provide security related functions. It provides functiona