Linux Security Concepts

External

• https://www.linux.com/training-tutorials/overview-linux-kernel-security-features/

Internal

• Linux Security

Privileged Mode

A process that runs in privileged mode has full access to the kernel. A container that runs in privileged mode has full access to the container runtime host's kernel and all devices on the host. Newer kernels allow assigning finer-grained privileges instead of giving the process all possible permissions by running it in privileged mode. Finer-grained privileges are called Linux capabilities.

Privileged Process

Traditional UNIX implementations distinguish two categories of processes for the purpose of performing permission checks: privileged processes and unprivileged processes. A privileged process is a process with its effective user ID is 0, referred to as superuser or root. Privileged processes bypass all kernel permission checks.

Privileged Container

Docker Security | Privileged Container

Unprivileged Process

An unprivileged process is a process with a non-zero its effective user ID. Unprivileged processes are subject to full permission checking based on the process' credentials: effective UID, effective GID and supplementary group list.

Privilege Escalation

https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt

To prevent privilege escalation, no_new_privs flag is set on a process.

Discretionary Access Control

https://wiki.archlinux.org/index.php/users_and_groups

Primary Group

A user belongs to a primary group that is specified in the /etc/passwd file. Additional supplementary groups can be specified.

Supplementary Groups

A user belongs to a primary group, which is specified in the /etc/passwd file, and can be assigned to multiple supplementary groups, which are specific in the /etc/group file. The usermod command can be used after creating to user to assign them to additional groups(s).

Linux Capabilities

Linux Capabilities

Secure Computing Mode (seccomp)

Secure computing mode (seccomp) is a mechanism which restricts access to system call by process. The idea is to reduce the attack surface of the kernel by preventing applications from entering system calls they don’t need. The system call API is a wide gateway to the kernel, and as with all code, there have and are likely to be bugs present somewhere. Given the privileged nature of the kernel, bugs in system calls are potential avenues of attack. If an application only needs to use a limited number of system calls, then restricting it to only being able to invoke those calls reduces the overall risk of a successful attack.