SELinux入门指南：基础知识教程

需积分: 11 157 浏览量更新于2024-07-17 收藏 1.97MB PDF 举报

《SELinux笔记本：基础篇》（The SELinux Notebook - Volume 1, The Foundations, 第二版）是一本专为希望深入学习Linux Security Enhanced Linux (SELinux) 的读者设计的教材。这本书由Richard Haines编著，版权信息表明其遵循GNU自由文档许可证（GNU Free Documentation License, Version 1.3或后续版本），允许在指定条件下复制、分发和修改文档。该书的核心内容主要集中在SELinux的基础知识上，包括但不限于以下几个方面： 1. 笔记本信息： - 讲解了书籍的版权信息，强调用户可以根据GNU自由文档许可证进行使用，无需支付费用，但必须保留版权信息，并且不得添加任何不兼容的前言或后记文本。 2. 代码许可： - 书中包含的脚本和源代码采用GNU通用公共许可证（GNU General Public License, GPL）v3或更高版本。这意味着读者可以自由地复制、分发和修改这些代码，将其作为开源项目，只要遵守GPL的条款，即不允许商业发行时将它们作为闭源产品。 3. 适用范围： - 本书旨在提供研究SELinux的有用资源，但明确指出没有任何形式的保证，包括商品质量保证或特定用途的适用性。因此，用户需自行评估其适用性和风险。 4. 学习价值： - 虽然提到书中的内容可能相对枯燥，但对于理解Linux系统权限管理和安全策略的高级概念来说，学习后可能会有实质性的收获。它适合对Linux内核安全机制有一定了解，想要进一步深化实践和理论知识的读者。 5. 教材特点： - 作为第二版，本书可能包含了最新的研究成果和更新，有助于读者跟上SELinux的发展动态，以及如何处理实际系统中的安全问题。通过阅读《SELinux笔记本：基础篇》，学习者能够掌握SELinux的基本原理、政策类型、规则管理、以及如何在Linux系统中实施和调试安全策略。对于系统管理员、安全专业人员和开发者来说，这是一本不可多得的参考资料，能帮助他们在保障系统安全的同时，提升技能水平。

The SELinux Notebook - The Foundations
Figure 2.2 shows a more complex diagram of kernel and userspace with a number of 
supporting services which are used to manage the SELinux environment. This diagram 
will  be referenced  a  number of times to  explain areas  of  SELinux, therefore using 
Figure 2.2 as the reference and starting from the bottom:
a) In the current implementation of SELinux, the security server is embedded in 
the kernel
2
 with the policy being loaded from userspace via a series of functions 
contained in a library (libselinux).
However the object managers (OM) and access vector cache (AVC) can reside 
in:
kernel space  – These object manages are for the kernel services such as 
files, directory, socket, IPC etc. and are provided by hooks into the SELinux 
sub-system via  the  Linux   Security Module  (LSM) framework  (shown as 
LSM   Hooks   in  Figure   2.2)   that   is   discussed   in   the  LSM  section.   The 
SELinux kernel AVC service is used to cache their requests and the security 
servers response.
userspace  –   These   object   managers   are   provided with   the  application   / 
service that  requires support for MAC and are known as ‘SELinux-aware
3
’ 
applications   or   services.   Examples   of   these   are:   X-Windows,   D-bus 
messaging   (used   by   the   Gnome   desktop),   PostgreSQL   database,   Name 
Service Cache Daemon (nscd), and the GNU / Linux  passwd  command. 
Generally, these OMs use the AVC services built into the SELinux library 
(libselinux), however they could if required supply their own AVC or 
not use an AVC at all. 
b) The   loadable   policy   (right   hand   side   of  Figure   2.2)   and   its   supporting 
configuration   files   are   contained   in   the  /etc/selinux  directory.   This 
directory contains the main SELinux configuration file (config) that names 
the policy to be loaded and the initial status of SELinux at boot time (enforcing
4 
the policy or not). The area also holds all policies that can be activated in their 
respective   directories  /etc/selinux/<policy_name>  (e.g. 
/etc/selinux/targeted would hold the ‘targeted’ F-12 policy and all its 
configuration files). All know configuration files for F-12 SELinux are shown in 
the SELinux Configuration Files section. 
c) SELinux supports a ‘modular policy’, this means that a policy does not have to 
be one large policy, but can be built from modules. A modular policy consists of 
a base policy that contains the mandatory information (such as object classes, 
permissions etc.), and zero  or more policy  modules that  generally  support a 
particular application or service. These modules are compiled, linked, and held 
in a ‘policy store’ where they can be  built into  a binary format  that is then 
loaded into the security server. The types of policy and their construction are 
covered in the Types of SELinux Policy section.
2
There is   a  project  developing a  Policy  Management  Server (PMS) that   will  utilise a user-space 
security server, however it is beyond the scope of this Notebook.
3
Generally this means that they use the services provided by the libselinux library as a minimum.
4
When SELinux is enabled the policy can be running in ‘permissive mode’, where all accesses are 
allowed  and   logged   in  the  audit   log,  even  if   they   are   not   permitted  by   the  policy  (useful   for 
debugging policy). The policy can also be run in ‘enforcing mode’, where any access that is not 
defined in the policy is deigned and an entry placed in the audit log.
Page 16

The SELinux Notebook - The Foundations
d) To be able to build the policy in the first place, policy source is required (top left 
hand side of Figure 2.2). This can be supplied in two basic ways: 
i) as source code written using the SELinux Policy Language. This is how 
the simple policies have been written to support the examples in this 
Notebook,   however   it   is   not   recommended   for   real-world   policy 
development. 
ii) using the Reference Policy that uses high level macros to define policy 
rules as well as the policy language. This is the standard way policies are 
now built for SELinux distributions such as F-12 and is discussed in the 
Reference Policy section.
e) To be able to compile and link the source code and load it into the security 
server requires a number of tools (top of Figure 2.2). These are used to build the 
sample policy modules where their use is described.
f) To   enable   system   administrators   to   manage   the   policy,   the   SELinux 
environment and  label  file systems   also requires  tools  and  modified  GNU / 
Linux commands. These are mentioned throughout the Notebook as needed and 
summarised in  Appendix B – SELinux Commands. Note that there are many 
other applications to manage policy, however this Notebook only concentrates 
on the core services.
g) To ensure security events are logged, GNU / Linux has an audit service that 
captures policy violations. The Audit Logs section describes the format of these 
AVC security events.
h)   SELinux   supports   network   services   that   are   described   in   the  SELinux 
Networking Support section, and the message filter (described in volume 2) is 
built using some of these features.
The Linux Security Module and SELinux section goes into greater detail of the LSM / 
SELinux modules with a walk through of a fork and exec process.
2.3 Mandatory Access Control (MAC)
Mandatory Access Control  (MAC) is a type of access control in which the operating 
system is used to constrain a user or process (the subject) from accessing or performing 
an operation on an object (such as a file, disk, memory etc.). 
Each of the subjects and objects have a set of security attributes that can be interrogated 
by the operating system to check if the requested operation can be performed or not. For 
SELinux the:
• subjects    are processes.
• objects    are system resources such as files, sockets, etc.
• security attributes are the security context.
• Security Server within the Linux kernel authorizes access (or not) using the:
• security policy (or policy) that describes rules that must be obeyed.
Note that the subject (and therefore the user) cannot decide to bypass the policy rules 
being enforced by the MAC policy with SELinux enabled. Contrast this to standard 
Page 17

The SELinux Notebook - The Foundations

Linux Discretionary Access Control (DAC), which also governs the ability of subjects

to access objects, however it allows users to make policy decisions.

Figure 2.3: Processing a System Call – The DAC checks are carried out first, if they

pass then the Security Server is consulted for a decision.

SELinux supports two forms of MAC:

Type Enforcement – Where processes run in domains and the actions on objects

are controlled by the policy. This is the implementation used for general purpose

MAC within SELinux. The Type Enforcement section covers this in more detail.

Multi-Level Security – This is an implementation based on the Bell-La Padula

(BLP) model, and used by organizations where different levels of access are

required so that (for example in some defence / Government systems) restricted

information is separated from classified information (i.e. maintaining

confidentiality). This allows enforcement rules such as ‘no write down’ and ‘no

read up’ to be implemented in a policy by extending the security context to include

security levels. The MLS section covers this in more detail along with a variant of

MLS called Multi-Category Security (MCS).

2.4 Type Enforcement (TE)

SELinux makes use of a specific style of type enforcement

(TE) to enforce mandatory

access control. For SELinux it means that all subjects and objects have a type identifier

associated to them that can then be used to enforce rules laid down in a policy.

The SELinux type identifier is a simple variable-length string that is defined in the

policy and then associated to a security context. It is also used in the majority of

SELinux language statements and rules used to build a policy that will, when loaded

into the security server, enforce the policy.

There are various ‘type enforcement’ technologies.

Page 18

User-space Process makes a System Call

Service System Call

Linux

Security

Module

Check for Errors

DAC Checks

LSM Hook

Return from System

Call

SELinux Security

Server, AVC and

Policy

Allow or Deny

Access

AllowedDenied

Failed

Kernel Space

User Space

The SELinux Notebook - The Foundations

Because the type identifier (or just ‘type’) is associated to all subjects and objects, it can

sometimes be difficult to distinguish what the type is actually associated with (it’s not

helped by the fact that by convention, type identifiers all end in ‘_t’). In the end it

comes down to understanding how they are allocated in the policy itself and how they

are used by SELinux services.

Basically if the type identifier is used to reference a subject it is referring to a GNU /

Linux process or domain (i.e. domain type). If the type identifier is used to reference an

object then it is specifying its object type (i.e. file type).

While SELinux refers to a subject as being an active process that is associated to a

domain type, the scope of an SELinux type enforcement domain can vary widely. For

example in the simple policy built in the Building a Basic Policy section of volume 2,

all the processes on the system run in the unconfined_t domain, therefore every

process is ‘of type unconfined_t’ (that means it can do whatever it likes within the

limits of the standard Linux DAC policy).

It is only when additional policies are implemented in the simple policy (via loadable

modules), that areas start to be confined, for example an external gateway is run in its

own isolated domain (ext_gateway_t) that cannot be ‘interfered’ with by any of the

unconfined_t processes (except to run or transition the gateway process into its

own domain). This scenario is similar to the ‘targeted’ policy delivered as standard in

Red Hat Fedora where the majority of user space processes run under the

unconfined_t domain (although don’t think they are equivalent as the policies

supplied with the Reference Policy have areas isolated by various domains and has

evolved over years of work).

2.4.1 Constraints

Within a TE environment the way that subjects are allowed to access an object is via an

allow rule , for example:

allow unconfined_t ext_gateway_t : process transition;

This is explained in more detail later, however it states that a process running in the

unconfined_t domain has permission to transition a process to the

ext_gateway_t domain. However it could be that the policy writer wants to

constrain this further and state that this can only happen if the role of the source domain

is the same as the role of the target domain. To achieve this a constraint can be imposed

using a constrain statement:

constrain process transition ( r1 == r2 );

This states that a process transition can only occur if the source role is the same as the

target role, therefore a constraint is a condition that must be satisfied in order for one or

more permissions to be granted (i.e. a constraint imposes additional restrictions on TE

rules). An example of this can be found in the Implementing a Constraint section of the

Sample Policy Source volume.

There are a number of different constraint statements within the policy language to

support areas such as MLS (see the Constraint Statements and MLS Statements

sections).

Page 19

The SELinux Notebook - The Foundations

2.5 Role-Based Access Control (RBAC)

To further control access to TE domains SELinux makes use of role-based access

control (RBAC). This feature allows SELinux users to be associated to one or more

roles, where each role is then associated to one or more domain types as shown in

Figure 2.4. Note that GNU / Linux users are not a direct part of the RBAC feature, they

are associated to SELinux users via SELinux specific commands

such as:

semanage login - That manages the association of GNU / Linux users (or

groups of users) to SELinux users.

semanage user - That manages the association of SELinux users to roles.

Figure 2.4 shows how the SELinux user and roles are associated within the basic

loadable modules that form the simple message filter exercise described in Volume 2.

Figure 2.4: Role Based Access Control – Showing how SELinux controls access via

user, role and domain type association.

SELinux users can be equated to groups or classes of user, for example in the Reference

Policy there is user_u for general users with staff_u and sysadm_u for more

specialised users. There is also a system_u defined that must never be associated to a

GNU / Linux user as it a special identity for system processes and objects.

2.6 Security Context

SELinux requires a security context to be associated with every process (or subject) and

object that are used by the security server to decide whether access is allowed or not as

defined by the policy.

The security context is also known as a ‘security label’ or just label that can cause

confusion as there are many types of label depending on the context (another context!!).

There are other SELinux utilities that can manage users etc., however this Notebook will only use the

core utilities.

Page 20

SELinux User

user_u

TE Domain

unconfined_t

This domain includes all

processes started at boot

time and when loading from

the command line prompt.

Role

unconfined_r

TE Domain

ext_gateway_t

TE Domain

int_gateway_t

TE Domain

move_file_t

Role

message_filter_r

These domains are entered from the unconfined_t domain by

performing domain transitions using SELinux facilities. This can be done

because user_u is associated to roles unconfined_r and

message_filter_r within the policy.

In the basic policy, the SELinux

user user_u is associated to all

GNU / Linux users by default.

剩余313页未读，继续阅读

qq_33689226

粉丝: 5
资源: 9

SELinux入门指南：基础知识教程

selinux-notebook:SELinux笔记本

SELinux Notebook 是一本关于 SELinux 的开源书籍，最初由 Richard Haines创建并捐赠给 SE

selinux notebook2

ansible使用selinux模块关闭selinux

虚拟机关闭selinux命令

cenos7关闭selinux并禁止selinux开机启动

centos7.6 关闭selinux

shell脚本配置selinux

Linux selinux 怎么安装

关闭Ubuntu的selinux

最新资源