2021年12月28日SELinux Notebook：详解与资源指南 - CSDN文库

需积分: 5 49 浏览量更新于2024-07-07 收藏 2.42MB PDF 举报

《SELinux Notebook (2021-12-28 版本)》是一份全面的参考资料，涵盖了关于SELinux的众多关键知识点。该文档于2021年12月28日更新，由Richard Haines和Paul Moore共同维护，遵循GNU自由文档许可证 Version 1.3或后续版本。主要内容包括： 1. **SELinux简介**：文档首先解释了SELinux的基本概念，阐述其在Linux系统中的核心作用，即增强系统的安全性和隔离性，通过强制执行细粒度的访问控制策略。 2. **LSM/SELinux架构**：深入探讨了Linux Security Modules (LSM)架构，它是SELinux与内核集成的基础，以及在GNU/Linux环境中的实现细节，如SELinux服务的组件和功能。 3. **网络、虚拟机、X-Windows、PostgreSQL和Apache/SELinux**：介绍了如何在这些常用技术中应用SELinux，如网络安全策略、虚拟机上的安全设置、X-Windows图形界面的安全控制、PostgreSQL数据库管理和Apache web服务器的SElinux增强功能。 4. **核心SELinux政策语言**：讲解了构建基础政策模块的方法，这对于理解如何设计和实现安全策略至关重要，特别是对初学者进行教学时。 5. **新Common Intermediate Language (CIL)**：着重介绍CIL在SELinux中的新实现，这是一个用于编写和管理政策的高级工具，有助于简化复杂的策略编写过程。 6. **核心SELinux政策管理**：文档还涉及如何有效地管理和维护SELinux政策，包括策略的安装、修改、审计以及故障排查等实用技巧。此版本的《SELinux Notebook》为系统管理员、安全专家和对Linux安全感兴趣的用户提供了一个全面的学习和实践平台，无论是初次接触还是进阶学习，都能从中获取有价值的信息。随着SELinux技术的不断发展，这份文档将不断更新，保持与最新趋势同步。

Role-Based Access Control

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 4: Role Based Access Control.

The SELinux role name is the second component of a ‘security context’ and by convention SELinux roles end

in

_r

, however this is not enforced by any SELinux service (i.e. it is only used to identify the role

component), although CIL with namespaces does make identification of a role easier for example a ‘role’

could be declared as

unconfined.role

.

It is possible to add constraints and bounds on roles as discussed in the Type Enforcement section.

Some policies, for example Android, only make use of one role called

r

.

Figure 4: Role Based Access Control -

Showing how SELinux controls access via user, role and domain type

association.

The SELinux Notebook

Page 16

Type Enforcement

Constraints

Bounds

SELinux makes use of a specific style of type enforcement (TE) to enforce mandatory access control. For

SELinux it means that all subjects have a

type

identifier associated to them that can then be used to enforce

rules laid down by 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 policy via the object

managers.

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 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 (although CIL policies with namespaces do help in

that a domain process ‘type’ could be declared as

msg_filter.ext_gateway.process

with object types being

any others (such as

msg_filter.ext_gateway.exec

).

Basically if the type identifier is used to reference a subject it is referring to a Linux process or

collection of processes (a domain or 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 Kernel policy in the

notebook-examples

, 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 as all access is allowed by SELinux).

It is only when additional policy statements are added to the simple policy 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.

The SELinux type is the third component of a ‘security context’ and by convention SELinux types end in

_t

,

however this is not enforced by any SELinux service (i.e. it is only used to identify the type component),

although as explained above CIL with namespaces does make identification of types easier.

Constraints

It is possible to add constraints on users, roles, types and MLS ranges, for example within a TE environment,

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

allow

, for example:

allow unconfined_t ext_gateway_t : process transition;

This 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). Note that the constraint is based on

an object class (

process

in this case) and one or more of its permissions.

The kernel policy language constraints are defined in the Constraint Statements section.

•

•

The SELinux Notebook

Page 17

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.

Within SELinux, a security context is represented as variable-length strings that define the SELinux user

(this is not the Linux user id. The Linux user id is mapped to the SELinux user id by configuration files),

their role, a type identifier and an optional MCS / MLS security range or level as follows:

user:role:type[:range]

Where:

user

The SELinux user identity. This can be associated to one or more roles that the SELinux user is

allowed to use.

role

The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.

type

When a type is associated with a process, it defines what processes (or domains) the SELinux user (the

subject) can access. When a type is associated with an object, it defines what access permissions the

SELinux user has to that object.

range

This field can also be know as a

level

and is only present if the policy supports MCS or MLS. The

entry can consist of:

A single security level that contains a sensitivity level and zero or more categories (e.g.

s0

,

s1:c0

,

s7:c10.c15

).

A range that consists of two security levels (a low and high) separated by a hyphen (e.g.

s0 -

s15:c0.c1023

).

These components are discussed in the Security Levels section.

However note that:

Access decisions regarding a subject make use of all the components of the security context.

Access decisions regarding an object make use of the components as follows:

the user is either set to a special user called

system_u

2

or it is set to the SELinux user id of

the creating process. It is possible to add constraints on users within policy based on their

object class (an example of this is the Reference Policy UBAC (User Based Access Control)

option.

the role is generally set to a special SELinux internal role of

object_r

, although policy

version 26 with kernel 2.6.39 and above do support role transitions on any object class. It is

then possible to add constraints on the role within policy based on their object class.

The Computing Security Contexts section decribes how SELinux computes the security context components based

on a

source context

,

target context

and object

class

.

The examples below show security contexts for processes, directories and files (note that the policy did not

support MCS or MLS, therefore no

level

field):

Example Process Security Context:

# These are process security contexts taken from a ps -Z command

# (edited for clarity) that show four processes:

LABEL PID TTY CMD

unconfined_u:unconfined_r:unconfined_t 2539 pts/0 bash

•

•

•

•

◦

◦

•

1.

2.

1.

2.

The SELinux Notebook

Page 19

剩余368页未读，继续阅读

hnbc_hzl

粉丝: 2
资源: 35

最新资源