Part1: Kernel protection preventive mechanisms in Linux systems and methods for monitoring them

The Linux kernel implements several protection mechanisms, including:

• Lockdown mode (Kernel, kernel security feature)
• SLUB/SLAB hardening (Kernel, kernel security feature)
• Kernel Address Space Layout Randomization (KASLR) (Kernel, kernel security feature)
• SELinux (built on top of the kernel)
• AppArmor (built on top of the kernel)

The implementation of these features is part of the broader Kernel Self Protection Project (KSPP), an initiative aimed at developing a secure design architecture to protect Linux environments. In this series of articles, we will explore each of these features from the perspective of Incident Response (IR) and the overall Blue Team approach.

SELINUX:

SELinux (Security-Enhanced Linux) tightly controls what users and programs can do on a Linux system by enforcing strict security policies, making it much harder for attackers or malicious code to access or modify sensitive resources. To work with SELINUX need to install this solution into the machine where needs to have strict controls . Noted solution has 3 modes Enforcing, Permissive, Disabled .

• Enforcing - Prevent access to file, process
• Permissive - Monitoring the policies , but not restricting access
• Disabled - Do not applying any policies

To monitor interactions with the kernel, we can set SELinux to Permissive mode, which will log actions that would have been denied by our policy without actually blocking them. This allows you to review potential violations and refine your rules. For example, you can leverage this capability to write custom rules that restrict write access to the kernel.

First of all need to create .te file with such rule

policy_module(myapp_deny_kernel_write, 0.0.1)
neverallow myapp_t kmem_device_t:chr_file { write append };
neverallow myapp_t kcore_device_t:chr_file { write append };
neverallow myapp_t mem_device_t:chr_file { write append };

Next, we should compile our .te file into a .mod file, and then convert it into a .pp file, which is the format understood by SELinux.

checkmodule -M -m -o kernel_integrity_protect.mod kernel_integrity_protect.te
semodule_package -o kernel_integrity_protect.pp -m kernel_integrity_protect.mod

Final step require to install recently compiled .pp file into our selinux policies

sudo semodule -i kernel_integrity_protect.pp

In this example, myapp_t represents a service or script that should not be able to write anything to kcore, kmem, or mem. For instance, if an attacker compromises an application running as myapp_t and attempts to install a kernel rootkit on our protected system, this policy can help mitigate such threats by preventing write access to these critical kernel memory device files.

When everything is ready on our side, we can observe that any policy violations will be visible in our syslog. These syslog entries can be sent directly to SIEM systems, or at least, we can change our SELinux mode to enforcing to prevent the execution of such activities.

Conclusion: This method can be applied to medium-risk assets. However, please always keep in mind that you are working with the kernel, so it should be thoroughly tested on systems before being deployed to production.