1

Contents
Abstract............................................................................................................................................................... 2
Index Terms ........................................................................................................................................................ 2
Introduction ........................................................................................................................................................ 2
Problem Statement.............................................................................................................................................. 3
a) Deprivilege root access of a user application ................................................................................................ 3
b) SELinux .................................................................................................................................................... 3
c) Root filesystem Encryption with Secure Boot............................................................................................... 3
Attacks: ............................................................................................................................................................ 4
a) Some of the Attacks caused without Deprivilege root access of user application ......................................... 4
b) Some of the Attacks caused without SELinux ........................................................................................... 5
c) Some of the Attacks caused without the Root filesystem Encryption .......................................................... 7
Proposed Solution and Implementation:.............................................................................................................. 8
a) Deprivilege Root Access of a user application: ......................................................................................... 8
b) SELinux................................................................................................................................................. 9
c) Root filesystem Encryption with Secure Boot......................................................................................... 11
CONCLUSION.................................................................................................................................................. 17
ACKNOWLEDGMENT.................................................................................................................................... 18
REFERENCES.................................................................................................................................................. 19
 2

Multi-Pronged Linux Security for Process Management and

Filesystem on an embedded device:
a) Deprivilege root access of a user application.
b) SELinux (Security-Enhanced Linux)
c) Root filesystem Encryption with Secure Boot.
M.Tech Project Phase I Report
Sneha Maganahalli Rajendranath, CS21M522, M.Tech, IIT Madras

Abstract
Embedded system security is a critical aspect of designing and deploying devices that are integrated with embedded systems,
such as IoT (Internet of Things) devices, industrial control systems, automotive systems, medical devices, and more. These
systems are often resource-constrained and perform dedicated functions, making them vulnerable to security threats. Therefore,
this project helps to maintain the security of any Linux based embedded system.

Index Terms
SELinux: Security-Enhanced Linux, MAC: Mandatory access control, DAC:
Discretionary Access Control. TZ: TrustZone, OTP: One Time Programmable

Introduction
In this modern world, there are lots of devices getting connected to the internet, which contain highly sensitive data. There is a necessity to
have Multi-pronged Linux Security for filesystem and Process management with principle of least privilege and encrypt the root file
system to prevent unauthorized parties from accessing the filesystem data and inspect offline.

The Multi-Pronged Linux Security for Filesystem and Process Management has the below topics covered under it.
a) Deprivilege root access of a user application:
b) SELinux (Security-Enhanced Linux):
c) Root filesystem Encryption with Secure Boot:
 3

Problem Statement

a) Deprivilege root access of a user application:

Running an application as the root user in an embedded system can introduce several security threats and risks due to the elevated privileges
associated with the root user such as privilege escalation attacks, unauthorized system modifications, malware execution.

b) SELinux:
Without SELinux, an embedded device will face various security threats due to their unique characteristics, limited resources, and
specialized functions. The common threats faced by an embedded device without SELinux are Denial of Service (DoS), insecure
communication, data leakage, unauthorized access etc.

c) Root filesystem Encryption with Secure Boot:

There are several components in Linux Kernel File System. Some file systems are Read-Only (squashfs). Here we mainly consider squashfs
for “rootfs-filesystem”. The current OpenWrt boot flow has secure boot support. Secure boot ensures that flash image data is not tampered
and executed, but it does not hide the image data from attackers. Since end user device Images are available in OEM’s cloud and is open to
all. These device image data is more vulnerable where device is remotely managed. In some cases where if device image update is for
external flash storage, external flash content is prone to theft by many ways. These root filesystem images from flash chip can be also
extracted (using flash reader HW). User can download the image data locally and these images can be inspected offline and find binary
exploits. These exploits can be tried on the end user device and can be hacked.

Boot loaders already support Unified Image Encryption. XBL to Linux Kernel can be encrypted.
But there is no Support for rootfs File Systems. So, we need a solution for this problem.

Therefore, Managing the responsibilities related to deprivileging root access and implementing SELinux and encrypting root filesystem
with secure boot on an embedded device is crucial for enhancing security.
 4

Attacks:

a) Some of the Attacks caused without Deprivilege root access of user application:

Figure 1: Privilege Escalation Attack

Figure 2: Malware attack

 5

b) Some of the Attacks caused without SELinux:

Figure 1: Unauthorized Access Attack

Figure 2: Data Leakage Attack

 6

Figure 3: Denial of Service Attack

 7

c) Some of the Attacks caused without the Root filesystem Encryption:

Figure 1: Eavesdropping Attack/ Data interception attack

Figure 2: Data Leakage/Data tampering Attack

 8

Proposed Solution and Implementation:

a) Deprivilege Root Access of a user application:
Deprivileging root access for a user application on an embedded device is a critical step in enhancing security. Root privileges
provide unrestricted access to system resources and reducing those privileges for an application can help mitigate potential
security risks. Here's how to deprivilege root access for a user application on an embedded device:

1) Identify the Application:

Start by identifying the specific user application that you want to deprivilege. Understand its functionality and the privileges it
requires to operate effectively.

2) Create a Dedicated User:

If the embedded device's operating system supports user management, create a dedicated non-root user for the application. If the
system does not support user management, proceed to the next steps to restrict root access.

3) File System Permissions:

Review and configure file system permissions to limit the application's access to sensitive system files and directories. Ensure
that the non-root user doesn't have unnecessary read or write access to system files.

4) Capability Reduction:
Use capabilities to grant only specific privileges needed by the application. Drop capabilities that the application doesn't require.

5) Network Access Control:

Limit the network access of the application by configuring firewalls, iptables rules, or network-level rules that restrict which
ports and addresses the application can access.

Deprivileging root access for a user application on an embedded device is a fundamental security practice. It's essential to strike
a balance between providing the application with the privileges it needs to function correctly and limiting its access to sys tem
resources and capabilities for security purposes.

Figure 1: Deprivilege root access of a user application

 9

b) SELinux:
Implementing SELinux (Security-Enhanced Linux) on an embedded device can greatly enhance the security of the device,
helping to enforce access controls, reduce the attack surface, and mitigate the impact of security breaches.
Here's a high-level guide to implementing SELinux on an embedded device:

1) Enable support for SELinux:

Activate SELinux in the device's kernel and bootloader configurations. This may involve making changes to bootloader
configuration files or kernel command-line parameters.

2) Install SELinux Tools:

Install the SELinux-related tools and packages required for policy management and enforcement. These tools typically include
"policycoreutils," "selinux-policy," and "setools."

3) Define a Security Policy:

Develop or customize SELinux policies tailored to the specific requirements of the embedded device. SELinux policies define
the rules that govern process and file access.

4) Assign Security Contexts:

Assign security contexts to processes, users, files, and resources on the device. Each process and file will have a security context
that dictates its access permissions.

5) File Labeling:
Label files and directories with their respective security contexts using the "chcon" or "restorecon" commands. This ensures that
the policy is enforced.

6) Test SELinux Policies:

Thoroughly test the SELinux policies to ensure they do not hinder the operation of legitimate applications and services. Adjust
policies as necessary to accommodate the device's functionality.

7) Regularly Review and Update Policies:

Periodically review and update SELinux policies to address changes in the device's configuration and evolving security
requirements.

8) Use "semanage" and "setsebool":

Tools like "semanage" and "setsebool" allow you to configure and fine-tune SELinux settings, including boolean settings and
policy management.
 10

How does SELinux work?

Figure 2: SELinux Decision Process

When a subject, (for example, an application), attempts to access an object (for example, a file), the policy enforcement server in the
kernel checks an access vector cache (AVC), where subject and object permissions are cached. If a decision cannot be made based on
data in the AVC, the request continues to the security server, which looks up the security context of the application and the file in a
matrix. Permission is then granted or denied, with an avc: denied message detailed in /var/log/messages if permission is denied. The
security context of subjects and objects is applied from the installed policy, which also provides the information to populate the security
server's matrix.
 11

c) Root filesystem Encryption with Secure Boot:

The Secure Boot ensures that flash image data is not tampered and executed, but it does not hide the image data from
attackers. End User Device Images are available in OEM’s cloud and is open to all. Device Image data is more
vulnerable where device is remotely managed. If Device image update is for external flash storage, external flash
content is prone to theft by many ways. The Images from Flash chip can be also extracted (using flash reader HW)
These images can be downloaded locally. These images can be inspected offline and find binary exploits.
These exploits can be tried on the end user device and hack.

Will Secure Boot Fix this Problem?

Secure boot provides a foundation for the security architecture of the device. Technically, secure boot is defined as a
boot sequence in which each software image that is loaded and executed on a device is authorized using software
previously authorized by this system. This sequence is designed to prevent unauthorized or modified code from being
run by ensuring that all code is checked before it is executed. Hence, the user can have confidence that these images
have not been altered because, in every case, a piece of trusted software checks the new image before it can be
executed.
The first image in this “chain of trust/Root of Trust” is called the Primary Boot Loader (PBL). The Primary Boot
Loader is stored in immutable read-only memory which is part of the fabric of each chip, and it cannot be physically
altered.
In the multistage device bootup stage process, each image in the stage performs a specific function, and each image
verifies the next image. One example is:
Primary Boot Loader (PBL) > Secondary Boot Loader (SBL) > ARMTrustZone (ATF/TZ) > U-Boot > Linux Kernel
(HLOS) .

Figure - Secure Boot Flow

 12

Here Secure Boot verifies the signature of each image. First it computes the hash of the image. Then it decrypts the
signature of the image and gets the hash stored in image signature. Now it compared the computed hash with hash
stored in image signature. So Secure Boot will not fix the problem.
Secure Boot enforces only signature verification. Secure Boot helps to verify the image integrity only.
is the image corrupted or is the image really from trusted user?
The signed images can still be inspected offline. The Linux kernel (HLOS) images can have critical data/keys specific
to trusted users.
So, we need a solution for this.

Proposed Solution:
The proposed solution is to encrypt the rootfs images offline, decrypt the rootfs image in device and load it. This way
images downloaded from cloud or extracted from flash chip cannot be extracted by untrusted users. This way the
images are secured from being inspected for exploits. The encryption process ensures that even if an attacker gains
access to the encrypted image, they cannot retrieve the original content without the decryption key.
Boot loaders already support Unified Image Encryption. XBL

Linux Kernel can be encrypted.

There is no Support for rootfs File Systems. Hence solution is needed for this.

Figure 1: Images of kernel

The entire process of root filesystem image encryption using the offline generated key, decryption using OTP key,
including key generation, key storage, and key retrieval are discussed here.
We use a Logical partition one to one mapped to a Physical partition. The Logical partition is having decrypted
content and the physical partition is encrypted content.
 13

“Logical Partition” is mounted in the system for usage (eg rootfs, data partition etc) and the “Physical partition” is not
exposed as a file system to the system. Any write to “Logical Partition” needs to be encrypted and written into
“Physical partition”. Any read from “Logical Partition” will be read from “Physical partition”, Decrypt the content and
return.

How to generate keys offline

Key generation need two inputs, one from fuse (trusted known seed) and another from software context. So,
encryption key will get generated using trusted fixed seed & fixed software context.
Software Context: This can be passed to Linux using a custom attribute/property in FIT image header.

Figure 2: How to generate keys offline

 14

Store the Encryption key in OTP of the Device

User can store the offline generated key into the OTP memory of the device. This operation is typically a one-time
process, and it ensures the confidentiality and integrity of the key.
The key generation for rootfs file system encryption for any device depends on the user provided fixed seed. This
seed value is given in NIST KDF tool for generating offline key for rootfs image encryption. For device side, we
store the same seed value by blowing in the OTP onetime.
The devices having HW crypto engine, the key derived from the used provided seed is sent to the HW crypto engine
block in Hardware. So, it is completely done in secure execution environment.
The device which does not have HW crypto engine, the derived key is returned to the kernel driver for the rootfs
filesystem decryption.

How to encrypt the root filesystem image offline

For Read-Only root filesystem Image following features are supported
For offline encryption of Read-only file system, we need openssl tool or python tool.
Openssl tool/Python tool needs two inputs, one is input root filesystem image for read-only file system & another is
key (derived by NIST Tool). Encryption key generated by NIST KDF tool; same key can be generated by TZ + TME-
L at run time for decryption. Encrypted rootfs image will be flashed to device’s flash chip. One key for all devices.

Figure 3: How to encrypt root filesystem image offline

 15

How to decrypt the root filesystem image in Device

The encryption key generated by NIST KDF tool was used for encrypting the rootfs filesystem image; same key can
be generated by ARM TrustZone at run time for decryption.
Run time decryption for Read-Only file system will be done by with help of “Linux kernel “
While bootup DUT u-boot will read all the parameter required for decryption form kernel fit image header and passed
into bootargs. “dm-init” modules will read all required the bootargs and passed to target driver for virtual mapping for
“root filesystem” partition. After that target driver will call required crypto module for decryption. It can either use
either HW crypto engine or ARM cryptographic instructions (ARM-ISA).

The device has HW Crypto Engine

The device which are having HW crypto engine present, they can use HW crypto engine to do
encryption/decryption on fly. The encryption key to HW crypto engine programmed by ARM Trust Zone which
will be used by HW crypto engine for decryption of the rootfs filesystem.
Below is the proposed block diagram for rootfs offline encryption and decryption design.

Figure 4: Hardware Crypto Engine

The device has ARM Cryptographic Instructions (ARM-ISA)

Some devices my not have HW crypto engine present. So, for this feature we are using Linux Software Crypto.
Linux Software.
For all the crypto operation for this feature we are using Key from kernel keyring. The key derived by TZ and
TME and passes to Linux kernel (via SMC call) and Linux kernel will configure this TZ derived key in kernel
keyring using “hw_key” module.
 16

Figure 1: Hardware Crypto Engine showing Encryption and decryption.

Encryption/Decryption for user data partition (RW)

There is no offline encryption support for user data partition. User data partition encryption/decryption done in
filed devices at run time.
For devices having hw crypto engine, user data partition encryption/decryption will be done by using HW
Crypto engine & “dm-crypt”
For other device user data partition encryption/decryption will be done by using ARM Cryptographic
Instructions (ARM-ISA).

Advantages
• Protection from physical attack.

• Protection against unauthorized access and data breaches.

• Scalability for future devices.

• The rootfs encryption adds a layer of trust and assurance to the system’s security.

Limitations
• Key is visible to Linux kernel if the device does not have HW crypto Engine.

• There is a latency which is created due to image decryption which is unavoidable, and device may take more boot time
 17

CONCLUSION
In conclusion, deprivileging root access for user applications, implementation of SELinux and Root filesystem encryption
with Secure Boot are essential components of a robust security strategy for embedded devices. These measures not only protect
against unauthorized access and potential vulnerabilities but also demonstrate a commitment to the security and integrity of the
device and its users.
 18

ACKNOWLEDGMENT
I would like to express our appreciation for the proactive measures taken to enhance the security of our embedded device by
deprivileging root access for user applications and implementing SELinux. These efforts are crucial for strengthening the
overall security posture of the device and mitigating potential risks.

By deprivileging root access, we have reduced the potential impact of security breaches and vulnerabilities within our user
applications.

In addition to deprivileging root access, the implementation of SELinux further fortifies our device's security. SELinux
enforces mandatory access controls, allowing us to define and enforce fine -grained security policies. This added layer of
security helps prevent unauthorized access, restricts the attack surface, and enhances our ability to control and monitor system
behavior.

The combination of root filesystem encryption with secure boot has significantly reduced the risk of various attacks,
providing a solid foundation for our overall security strategy.

This project is done by Ram Chandra Jangir (CS21M517) and Sneha Maganahalli Rajendranath (CS21M522) under the
guidance of Naresh Mehta (Manager and Sr. Staff Engineer) and Radha Krishna Simha Jiguru (Sr. Staff Engineer).
 19

REFERENCES
[1] SELinux https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/ch-selinux
[2] ARM Trusted Firmware - https://developer.arm.com/tools -and-software/open-source-software/firmware/trusted-firmware/trusted-firmware-a
[3] Trustzone - https://developer.arm.com/documentation/102418/0100/TrustZone-in-the-p