Agenda:
An in depth review of various security mechanisms in the kernel like those added by PAX and grsecurity.
Speaker:
Yehontan Biton, senior kernel developer and computer science researcher for Ben Gurion University of the Negev.
3. Who am I?
Yehonatan Bitton , Married +2
Security Researcher at BGU
4. Introduction
What are we protecting?
User apps?
Kernel modules?
The core kernel functionallity?
5. Linux security modules
Kernel hooks
Pluggable - kernel module style
It is not intended as a general "hook" or "upcall" mechanism
Examples: SElinux , AppArmor, Smack, Yama, …
Least privileges
6. SELinux
Mandatory access control
Very complicated
Learning mode
Just access control
Auditing
In mainline
7. GRsecurity
More than access control module
RBAC
Can be stacked with LSM (not an LSM module)
Policy learning and analysis
PaX (will be covered later)
Improved ASLR
Chroot hardening (using containers)
8. PaX
Least privileges protections for memory pages
Executable space protections
PAGEEXEC
SEGMEXEC
...
ASLR
9. PaX Executable space protections
Prevent shellcode/code injection attacks
NX-bit (none executable bit, hardware base or emulated where needed)
Restrict mprotect syscall
Don't work with java just in time compiler
There are exceptions
11. PaX - PAGEEXEC
Uses or emulates nx-bit on architectures without hardware support
On IA-32 - uses supervisor bit
Using two different TLB's (ITLB, DTLB) we can determine which one will cause
protection fault and inform the kernel, it the fault is from the ITLB than PaX will
kill the process otherwise everything will be fine
Pageexec patch overrides the fault handler and checks whether it's results
from instruction fetch
Each fault is checked for the user address and if it's with write permissions PaX
will terminate the process.
12. SEGMEXEC
Reduce process VM size to 1.5G
The process memory is mirrored
Mapping in the upper and lower parts is the same
Don't double RAM usage
Each execution is checked against the mirror if code is not paged there
PaX will terminate the process
13. Seccomp
Module for sandboxing in the kernel (no virtualization)
Restrict process system calls
All child processes inherit the parent restrictions
Initially used for cloud computing
A user upload a program and it cannot abuse the server
Seccomp v2 supports dynamic policies
Each process defines the syscalls which he can use and then enter
seccomp mode
On seccomp mode process can add more restrictions
14. Namespaces
Create multiple processes trees
Process from child tree cannot affect parent tree
Ptrace
Kill
Each process has multiple PID's one for each nested tree
15. Namespaces - network mounts
When using clone enter special network flag - CLONE_NEWNET
Each process have different set of network interfaces
18. Communication
Using ssh daemon
Create special uds device from the init process and pass it down to the
child trees
Using TCP
19. CGroups
Create separate groups for similar tasks
Each group has restrictions
Resource limitation - memory usage
Prioritization - cpu share
Control - stop, restart,… a group
Each control group is in different namespace
In 2007 “container”
Notes de l'éditeur
If things where to stay asIf things where to stay before we would have shared resources between processes in trees whitout knowing which one broke the system (why is port 80 unavailable???)