Linux Security Concepts: Difference between revisions
| (27 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=External= | |||
* https://www.linux.com/training-tutorials/overview-linux-kernel-security-features/ | |||
=Internal= | =Internal= | ||
* [[Linux_Security#Concepts|Linux Security | * [[Linux_Security#Concepts|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|Linux capabilities]]. | |||
==Privileged Process== | |||
Traditional UNIX implementations distinguish two categories of processes for the purpose of performing permission checks: privileged processes and [[#Unprivileged_Process|unprivileged processes]]. A privileged process is a process with its [[#Effective_User_ID|effective user ID]] is 0, referred to as superuser or root. Privileged processes bypass all kernel permission checks. | |||
==Privileged Container== | |||
{{Internal|Docker_Security#Privileged_Container|Docker Security | Privileged Container}} | |||
==Unprivileged Process== | |||
An unprivileged process is a process with a non-zero its [[#Effective_User_ID|effective user ID]]. Unprivileged processes are subject to full permission checking based on the process' credentials: [[#Effective_User_ID|effective UID]], [[#Effective_Group_ID|effective GID]] and [[#Supplementary_Group_List|supplementary group list]]. | |||
==Unprivileged Container== | |||
==Privilege Escalation== | |||
{{External|https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt}} | |||
<span id='no_new_privs'></span>To prevent privilege escalation, <code>no_new_privs</code> flag is set on a process. | |||
=Discretionary Access Control= | |||
{{External|https://wiki.archlinux.org/index.php/users_and_groups}} | |||
==Effective User ID== | |||
==Primary Group== | |||
A user belongs to a [[#Primary_Group|primary group]] that is specified in the /etc/passwd file. Additional [[#Supplementary_Groups|supplementary groups]] can be specified. | |||
==Effective Group ID== | |||
==<span id='Supplementary_Group_List'></span>Supplementary Groups== | |||
A user belongs to a [[#Primary_Group|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= | ||
{{Internal|Linux_Capabilities#Overview|Linux Capabilities}} | |||
= | =<span id='seccomp'></span>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. | |||
Latest revision as of 00:10, 12 May 2022
External
Internal
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
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.
Unprivileged Container
Privilege Escalation
To prevent privilege escalation, no_new_privs flag is set on a process.
Discretionary Access Control
Effective User ID
Primary Group
A user belongs to a primary group that is specified in the /etc/passwd file. Additional supplementary groups can be specified.
Effective Group ID
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
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.