tencent cloud

TencentOS Server

Security Architecture and Feature Analysis

ダウンロード
フォーカスモード
フォントサイズ
最終更新日: 2026-10-19 17:22:49
AI翻訳
This document describes the security architecture design philosophy, core security features, and security protection framework of TencentOS Server, helping you understand the system's security capabilities and configure them properly. It applies to TencentOS Server 3 and TencentOS Server 4. Some security features (such as trusted measurement and TPCM/TCM hardware root of trust) depend on hardware and firmware support. In CVM virtualization environments, some features may be unavailable. The actual availability depends on your environment.

Security Architecture Design

Fundamental Elements of Information Security

The basic elements of information security include:
Confidentiality: ensures that data is not accessed by unauthorized entities. Corresponding mechanisms in the OS include the UGO (User/Group/Others) permission mechanism, ACLs (Access Control Lists), and SELinux mandatory access control.
Integrity: ensures that data is not damaged or tampered with. Corresponding OS security mechanisms include the IMA/EVM integrity measurement architecture.
Availability: ensures that corresponding services and resources are available while maintaining data confidentiality and integrity.
In addition, information security includes two extended elements: controllability and non-repudiation. For example, the security audit mechanism can be classified under non-repudiation. After a security incident occurs, relevant operation records can be traced through audit logs.

Security Framework Design Principles

The TencentOS Server security framework is designed based on the following principles:
Covers basic security features: including mandatory access control (SELinux), discretionary access control (ACL), and security auditing.
Meets security certification requirements: including security features such as the Biba integrity model and support for Chinese cryptographic algorithms.
Adapts to industry compliance requirements: including features such as dynamic measurement and secure boot.
The overall design principle of the security framework is security transparency: when security modules are running, the lower the performance impact, the less user involvement, and the looser the system coupling, the better. Security mechanisms or features have corresponding switches, and users can decide whether to enable them based on actual needs.

Security Features in Detail

The core security mechanisms of TencentOS Server include: discretionary access control based on ACLs, mandatory access control based on labels, integrity protection based on IMA/EVM, integrity protection based on the Trusted Computing Module (TPCM/TCM), and the trusted path mechanism based on the SAK (Secure Attention Key). The following sections describe the design and implementation of each security feature.

Kernel Security

TencentOS Server applies security hardening to kernel compilation parameters and boot parameters, providing a more secure kernel configuration. For example, security mechanisms such as KASAN (Kernel Address Sanitizer) are enabled to fundamentally improve OS security.

Identity authentication

TencentOS Server supports multiple identity authentication mechanisms:
Username and UID consistency: ensures that the mapping between usernames and UIDs is not tampered with.
Strengthens password management: configures password complexity and expiration policies through the PAM module.
Multiple authentication mechanisms: supports combinations of multiple authentication methods.
Session management: limits the number of concurrent sessions, disconnects sessions on timeout, and locks accounts after authentication failures.

Access Control Mechanisms

TencentOS Server provides multiple access control mechanisms to build a reasonable access control framework, manage users and various resources holistically, and deliver fine-grained access control.
All access by subjects to objects must pass through the access monitor, ensuring that the access control mechanism cannot be bypassed or circumvented.

Discretionary Access Control (DAC)

The user/group/others mechanism commonly used in the system is a form of discretionary access control, where permission assignment is determined by the resource owner. ACLs (Access Control Lists) extend UGO by providing finer-grained permission assignment. With ACLs, you can set access permissions for specific users or groups that differ from those defined by UGO.

Labels and Mandatory Access Control (MAC)

SELinux is the core implementation of mandatory access control in TencentOS Server. The SELinux subsystem consists of modules such as AVC (Access Vector Cache), Security Server, policy enforcement components, and selinuxfs. SELinux enabling/disabling and partial policy compilation are performed in user space.
SELinux implements the BLP (Bell-LaPadula) confidentiality model. In addition, the Biba integrity model module is mounted in the kernel security framework. The Biba model introduces integrity labels, including checkpoint design, decision logic design, policy design, related tool design, and corresponding user-space compilation tools and commands.

Audit and Automatic Response Mechanisms

TencentOS Server provides a complete system auditing mechanism, allowing you to perform log audits after security events occur and providing an important reference for timely detection of system security issues.
Audit log basic features: the audit system records security policy violation events in the system. Logs are stored in /var/log/audit/audit.log and can be queried and reported by using the ausearch and aureport tools.
Automatic audit response: Traditional audit logs only provide query capabilities. On this basis, TencentOS Server implements an automatic response mechanism for audit logs. When logs are continuously written to audit files, the system performs template matching against audit log rules. When a match is successful, an automatic response action is triggered, such as terminating the corresponding process (kill) or sending an alert email to a specified mailbox.

Data integrity

Integrity protection in the OS includes:
Integrity models in mandatory access control: such as the Biba integrity model.
System integrity measurement and trusted boot: measures file integrity through the IMA/EVM mechanism to ensure a trusted boot chain.
Data integrity check: checks file system consistency through fsck, and performs file integrity checking and intrusion detection through AIDE (Advanced Intrusion Detection Environment).

Data confidentiality

Data encryption is implemented in the following ways:
File-level encryption: uses GPG (GNU Privacy Guard) to encrypt and sign files.
Block device encryption: uses LUKS (Linux Unified Key Setup) to perform full-disk encryption on disk partitions.

Object Reuse

Object reuse is an important feature of a secure OS. When a specified memory region is reallocated for other purposes, the system clears the structure data associated with that memory from its previous use, ensuring that the memory or structure to be allocated does not carry original data information and preventing information leakage.

Trusted Measurement

Trusted measurement is divided into static measurement and dynamic measurement:
Static measurement: After the system is powered on, CRTM (Core Root of Trust for Measurement) measures the integrity of the BIOS, the BIOS measures the integrity of the Bootloader, and the Bootloader measures the OS Kernel. Then, the Bootloader measures upper-layer applications to build a complete Trust Chain and extend the trusted boundary.
Dynamic measurement: performs periodic or event-triggered integrity measurement on critical components during system runtime, covering runtime tampering scenarios that static measurement cannot reach, such as code tampered in memory and modules or files replaced at runtime. Typical mechanisms include IMA-based runtime file measurement and periodic verification based on remote attestation, complementing static measurement to extend trust from "trusted boot" to "trusted runtime".
Trusted path and trusted channel: A trusted path is used to ensure the trustworthiness of the communication path between users and the system, and a trusted channel ensures the trustworthiness of end-to-end communication over the network. By combining trusted features, an overall trusted network is ultimately built, extending trust from a single point to end-to-end.

FAQ and Summary

Troubleshooting SELinux Permission Issues

When using SELinux in daily operations, you may often encounter permission denied errors. The troubleshooting steps are as follows (prerequisite: SELinux is enabled. If the getenforce output is Disabled, SELinux is not enabled, and the permission issue is unrelated to SELinux. TencentOS Server cloud images may be in the Disabled state by default. To enable SELinux, see the relevant configuration documentation):
Step 1: Confirm whether the issue is caused by an SELinux policy.
Perform the specific operation in permissive mode and enforcing mode respectively. If the operation succeeds in permissive mode but fails with a permission denied error in enforcing mode, the issue is generally caused by the SELinux policy.
# Switch to permissive mode
setenforce 0
# Perform operation tests...
# Switch back to enforcing mode
setenforce 1
Step 2: Extract audit logs.
# Clear the audit log, perform the operation again, and then extract the log.
ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent

# You can also extract logs using journalctl or dmesg.
journalctl -t setroubleshoot
dmesg | grep -i -e type=1300 -e type=1400
Step 3: Handle cases with no log output.
If no logs are extracted, the dontaudit rules may be preventing audit data from being recorded. Temporarily disable the dontaudit rules:
# Temporarily disable the dontaudit rules to allow all denial messages to be logged.
semodule -DB
# Perform the operation again and then check the audit log.
ausearch -m AVC,USER_AVC -ts recent
Step 4: Automatically generate and load the policy.
# Export audit logs of authentication failures and automatically generate a policy.
audit2allow -M mypolicy < /var/log/audit/audit.log

# Install the generated policy module.
semodule -i mypolicy.pp
Note:
The policy generated by audit2allow allows all denied operations and may include unauthorized actions. Before loading it, review the contents of the .te policy source file to ensure that only business-required permissions are allowed, avoiding security gaps.
Repeat this process 2-3 times to confirm that the policy takes effect. If you manually adjust the policy, audit2allow generates two files: .pp (the compiled policy) and .te (the policy source file). You can directly edit the .te file and then compile and load it.
Step 5: Restore the dontaudit rules.
# Re-enable the dontaudit rules.
semodule -B

Summary

The security framework of TencentOS Server is built on the Linux kernel to construct various foundational security tasks and mechanisms, complying with structured design requirements. All subject-to-object access in the OS undergoes access arbitration, achieving complete arbitration to ensure that it cannot be bypassed or circumvented.
From a security perspective, TencentOS Server defines the Trusted Computing Base (TCB), which includes foundational components in kernel space and user space as well as core security mechanisms. Integrity protection ensures that the loaded kernel and other critical parts of the TCB are not tampered with.
In the future, TencentOS Server will continue to verify the consistency between security model design and implementation, collaborate with the security community to validate security policy models, and continuously improve the security protection system.

ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック