Home  icon  Articles  icon  Security Tips for Embedded Linux Systems

bulat-icon  Articles  
 
 

[+]  Articles
 
     
   
 
 

Security Tips for Embedded Linux Systems
Security Tips for Embedded Linux Systems
 

Why we need to secure our embedded Linux devices ?
As we know Linux users are less prone to viruses compared to other operating Systems, still most of the Linux users and administrator face many security issues.
Rather than just saying we need to make a system secure you need to consider what is meant by secure, what risks are associated with any data that's available and what impact your security measures will have on your users. Without first considering any of these factors how else will you know if you've met your goal of making a system secure.
Main aspects of security are listed below
Main aspects of security are listed below
Source: www.sedonacyberlink.com/2011/12/why-you-need-a-robust-security-network/
  • Authenticity - Verifying they are who they say they are
  • Confidentiality - Ensuring personal information is not being compromised
  • Integrity - Ensuring that the data has not been tampered with
Is it possible to secure your kernel image , kernel modules , executables , user data ?
Yes , you can protect all your boot images and data with techniques as explained below
  • Verifying Boot in U-Boot.
  • Validating Kernel modules.
  • Executing signed binaries only.
  • Using LSM to protect both user data and configuration data

Verified Boot
 
Many embedded systems use u-boot to merely initialize hardware and boot the Linux OS. But they don't even verify whether the linux kernel image , device tree and ramfs image used to boot the device are built for that specific device.Often encryption and signing are seen as complicated or not necessary , but there is an increasing trend to secure device firmware for both security and integrity.
To achieve security , u-boot offers verified boot mechanism.U-boot verified boot relies on two familiar technologies cryptographic hashing ( e.g SHA1 ) and public key cryptography ( i.e RSA ).
Verified Boot makes sure that only the expected code can be used to boot the system by representing the below capabilities
  • Provide authorisation
  • Machine Safe - runs only signed software
To get better understanding of verified boot mechanism. Let us view the below image:
verified boot mechanism
Verified boot mechanism can also be applied to device tree file and ramfs image.

Validating Kernel Modules
 
As of now , we are booted with encrypted kernel image and device tree binary. The next question that you might ask is, Is there any way to secure our kernel modules ?
What happens if someone loads malicious module and crase your embedded system?
To avoid such situations, Linux kernel provides two options:
  • Module Signing
  • LoadPin

Module Signing
Module signing increases Linux kernel security by making it harder to load malicious module into the kernel.
The kernel module signing facility cryptographically signs modules during installation and then checks the signature upon loading the module.Module signing uses X.509 ITU-T standard certificates and RSA public key encryption standard.
This allows further hardening of the system by disallowing unsigned kernel modules or kernel modules signed with invalid key.

Configuring Module Signature Verification in Linux Kernel
Configuring Module Signature Verification in Linux Kernel
Source: wiki.gentoo.org/wiki/Signed_kernel_module_support
CONFIG_MODULE_SIG option will enable module signature verification in Linux kernel.
It also supports two approaches on signed modules :
  • Permissive approach : By default, the permissive approach is used, which means that the Linux kernel module either need to have a valid signature, or no signature.
  • Strict approach: A valid signature must be present. (recommended)
In the above example, the strict approach is used by selecting Require modules to be validly signed (CONFIG_MODULE_SIG_FORCE).

LoadPin
LoadPin is available as a LSM Module from Linux kernel version 4.7 onwards
LoadPin takes advantage of introducing new kernel file-loading mechanism to interrupt all attempts to load a file into the kernel; these include loading kernel module , reading device firmware , loading a security policy or loading an image for kexec().
For every boot, any file read through the kernel file reading interface can be pinned to the first filesystem used for loading. If you try to load any file that comes from other filesystem will be rejected.
We can configure LoadPin in Linux kernel 4.9 by enabling CONFIG_SECURITY_LOADPIN security option.
CONFIG_SECURITY_LOADPIN

Executing Signed Binaries Only
Our embedded systems are already seems to be secured by running verified boot binaries and signed kernel modules, but still we have a downside with verified boot mechanism.
With the existence of verified boot, sys_kexec() seems to be dangerous. Intruder can run their own kernel image by neglecting verified boot feature using sys_kexec() or he can run his own user space application to crash your device.
So, it is necessary to implement security in user space also and have to sign executables such as /sbin/kexec.

Signing a ELF executable
Signing utility can take a private key and an x509 certificate to sign an ELF executable.This is similar to module signing and verification technique.
There are two major differences:
  • Signature are put in a section instead of being appended to executable.
  • we calculate digest of PT_LOAD segments and not the whole executable file.

Verifying Signed ELF executable
In Linux kernel, set of patches are applied to verify the signed executables. Upon exec(), we check if executable is signed. If it is, then we lock down the pages in memory and verify the signature. If the signature does not match, then the respective process will be killed.

Use LSM to protect both user data and configuration data
Linux Kernel core security module is Discretionary Access Control (DAC) and it is directly inherited from Unix. DAC seems to be outdated for modern security threats and it does not protect against flawed or malicious code.
To overcome the flaws of DAC, Linux Kernel came up with Linux Security Modules (LSM) Framework that support different security models such as:
  • Smack
  • SELinux
  • AppArmor
  • TOMOYO
  • Yama
LSM Framework
Source: se7so.blogspot.in/2012/04/linux-security-modules-framework-lsm.html
The Linux Security Modules (LSM) subsystem has developed a lightweight, general purpose, access control framework for the Linux kernel that enables many different access control models to be implemented as loadable kernel modules.

Smack
The Smack LSM was designed to provide a simple form of MAC (Mandatory access control) security .
Smack includes three important components as follows:
  • A kernel module that is implemented as Linux security module.It works best with file systems that support extended attributes.
  • A startup script that ensures the device files have correct Smack attributes and load the smack configuration
  • User space tools like smackload, smackaccess and chsmack.
Implementing Smack includes below steps
  • Building Linux kernel image with Smack (i.e..CONFIG_SECURITY_SMACK) enabled.
  • Mounting the smackfs filesystem.
  • Assigning subject and object label for respective files.
  • Creating and updating the rule to Smackfs filesystem.
  • Switching to non-root user mode and test the rule.

Secured Images Running in eSOM's
We tested all the above techniques in e-con SOM's.
Let us show you an example

Module Signing
To confirm whether a module is signed, enter the command modinfo followed by module name
Module Unsigned
Module signing will restrict loading unsigned modules
invalid key
And it won't load modules signed with invalid key
modules signed with invalid key
It will allow loading only valid signed modules
valid signed modules

LoadPin
When loadpin is enabled in the kernel , it will mark the filesystem device that load the first module when kernel is booted.
loadpin
And if you try to load a module inside that specific filesystem (dev(179,34)) from any path , modules will be loaded successfully.
But if you try to load the module from some other filesystem , the LoadPin will not allow the module to load.
LoadPin will not allow the module to load

ELF Signing
If you execute the signed binary, then it will run successfully
 
root@esomimx6s:~# ./hello_world.sign
Hello World
Now again sign the hello_world application with duplicate private key and try to execute the binary, it will be killed by kernel ELF handler.
 
root@esomimx6s:~# openssl genrsa -out duplicate_priv_key 1024
root@esomimx6s:~# ./signelf -i hello_world -o hello_world.sign -p duplicate_priv_key -c signing_key.x509
root@esomimx6s:~# ./hello_world.sign
[ 15.104452] ELF Signed with invalid key
Killed

Smack
We validated Smack LSM Module on our eSOM devices.
 
Created a user named econ and an executable file "read" to read the contents of "myfile" text file.
 
Created subject label for "read" executable file and object label for "myfile" text file.Wriitten a ruleset for subject read on object myfile with write permission alone and updated the ruleset to Smackfs filesystem.
 
Switched to non-root user and then validated the rule.
 
root@esomimx6q:~# su - econ
esomimx6q:~$ ./read
File Not Opened

Conclusion
You can secure all your embedded Linux systems with software security approaches explained above.
 
Other way to enhance your system security to next level is by utilizing your processor hardware capabilities like CAAM and HAB present in iMX6.