wonder
70e368e235
Deploy Examination / deploy (push) Successful in 7s
New topic group: 网络安全专题 (cybersecurity) Subtopics: - web-security: Web 安全基础 (34 questions) - crypto-basics: 密码学基础 (34 questions) - buffer-overflow: 缓冲区溢出与漏洞利用 (34 questions) - os-security: 操作系统安全 (34 questions) - network-attack: 网络攻防 (34 questions) - secure-coding: 安全编程实践 (34 questions) Question types per subtopic: - single_choice × 20 - true_false × 10 - short_answer × 3 - code_reading × 1 Difficulty range: 1-3 (基础)
414 lines
20 KiB
JSON
414 lines
20 KiB
JSON
{
|
||
"topic": "os-security",
|
||
"type": "single_choice",
|
||
"schema_version": "1.0.0",
|
||
"generated": "2026-09-17T00:00:00+08:00",
|
||
"questions": [
|
||
{
|
||
"id": "sc-001",
|
||
"type": "single_choice",
|
||
"difficulty": 1,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"权限模型"
|
||
],
|
||
"question": "在 UNIX/Linux 权限模型中，文件权限 rwxr-xr-- 对应的八进制数值是：",
|
||
"options": {
|
||
"A": "744",
|
||
"B": "754",
|
||
"C": "644",
|
||
"D": "755"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "权限分为三组：所有者(rwx=4+2+1=7)、同组(r-x=4+0+1=5)、其他(r--=4+0+0=4)，因此八进制为 754。A 选项 744 表示 rwxr-----，C 选项 644 表示 rw-r--r--，D 选项 755 表示 rwxr-xr-x，均不符合题意。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-002",
|
||
"type": "single_choice",
|
||
"difficulty": 1,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"权限模型"
|
||
],
|
||
"question": "以下哪个 Linux 命令可以将文件 /etc/passwd 的所有者修改为用户 alice？",
|
||
"options": {
|
||
"A": "chmod alice /etc/passwd",
|
||
"B": "chown alice /etc/passwd",
|
||
"C": "chgrp alice /etc/passwd",
|
||
"D": "passwd alice /etc/passwd"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "chown (change owner) 命令用于修改文件所有者。chmod 用于修改文件权限位，chgrp 用于修改文件所属组，passwd 用于修改用户密码。注意修改文件所有者通常需要 root 权限。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-003",
|
||
"type": "single_choice",
|
||
"difficulty": 1,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"权限模型"
|
||
],
|
||
"question": "Linux 中 SUID 位的作用是：",
|
||
"options": {
|
||
"A": "使文件只能被 root 用户读取",
|
||
"B": "使程序在执行时以文件所有者的身份运行",
|
||
"C": "使文件不可被删除",
|
||
"D": "使目录下的文件自动继承目录的组"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "SUID (Set User ID) 位使得任何用户执行该程序时，进程的有效用户 ID 变为文件所有者的 UID，而不是执行者的 UID。典型例子是 /usr/bin/passwd，它需要以 root 身份运行来修改 /etc/shadow。A 描述的是文件读权限限制，C 描述的是 sticky bit 在某些场景下的效果（实际 sticky bit 防止非所有者删除目录中的文件），D 描述的是 SGID 对目录的效果。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-004",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"权限模型"
|
||
],
|
||
"question": "在访问控制模型中，DAC（自主访问控制）与 MAC（强制访问控制）的核心区别是：",
|
||
"options": {
|
||
"A": "DAC 由系统管理员统一管理，MAC 由资源所有者决定",
|
||
"B": "DAC 允许资源所有者自行设定访问权限，MAC 由系统安全策略统一强制执行",
|
||
"C": "DAC 只用于文件系统，MAC 只用于网络",
|
||
"D": "DAC 比 MAC 安全性更高"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "DAC（Discretionary Access Control）允许资源的所有者自行决定谁可以访问该资源，灵活性高但可能因配置不当导致安全问题。MAC（Mandatory Access Control）由系统管理员预定义的安全策略强制执行，普通用户无法覆盖，安全性更高。Linux 的 SELinux 和 AppArmor 就是 MAC 实现。A 恰好说反了；C 不正确，两者都可用于多种资源；D 不正确，MAC 通常比 DAC 更安全。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-005",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"权限模型"
|
||
],
|
||
"question": "Linux 的 Capabilities 机制相比传统的 root/普通用户二分模型，其主要优势是：",
|
||
"options": {
|
||
"A": "完全取代了传统的 UID/GID 机制",
|
||
"B": "可以将 root 的超级权限细分为多个独立的特权能力，按需授予",
|
||
"C": "使普通用户自动获得所有系统特权",
|
||
"D": "只适用于容器环境，不能用于普通进程"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "Linux Capabilities 将传统的 root 全能权限拆分为多个独立的细粒度能力，如 CAP_NET_BIND_SERVICE（绑定低端口）、CAP_SYS_PTRACE（跟踪进程）等。这样非 root 进程也可以获得所需的特定特权，而无需拥有全部 root 权限，符合最小特权原则。A 错误，Capabilities 补充但未取代 UID/GID；C 错误，Capabilities 需显式授予；D 错误，Capabilities 普遍适用于 Linux 进程。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-006",
|
||
"type": "single_choice",
|
||
"difficulty": 1,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"沙箱"
|
||
],
|
||
"question": "沙箱（Sandbox）在操作系统安全中的主要作用是：",
|
||
"options": {
|
||
"A": "加速程序的运行速度",
|
||
"B": "隔离程序的运行环境，限制其对系统资源的访问",
|
||
"C": "为程序提供更大的内存空间",
|
||
"D": "自动修复程序中的安全漏洞"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "沙箱是一种安全机制，通过创建受限的隔离环境来运行不可信的程序，限制其对文件系统、网络、系统调用等资源的访问，从而保护宿主系统。典型应用包括浏览器沙箱、移动端应用沙箱、容器化等。A、C 均不是沙箱的功能，D 也不正确，沙箱不负责修复漏洞。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-007",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"沙箱"
|
||
],
|
||
"question": "seccomp（Secure Computing Mode）是 Linux 内核提供的一种安全机制，其工作原理是：",
|
||
"options": {
|
||
"A": "加密进程的内存空间",
|
||
"B": "限制进程可以使用的系统调用，禁止不在白名单中的调用",
|
||
"C": "将进程迁移到独立的网络命名空间",
|
||
"D": "对进程的所有文件操作进行审计日志记录"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "seccomp 是 Linux 内核提供的系统调用过滤机制。在 seccomp 模式下，进程只能使用有限的系统调用（如 read、write、exit、sigreturn）。seccomp-bpf 扩展允许通过 BPF 程序定义更灵活的过滤规则（白名单/黑名单）。Docker、Chrome 等都使用了 seccomp 来限制容器或子进程的系统调用。A 是加密概念，C 是 namespace 功能，D 是 auditd 的功能。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-008",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"沙箱"
|
||
],
|
||
"question": "Linux Namespace 技术可以隔离以下哪些系统资源？",
|
||
"options": {
|
||
"A": "仅进程 ID（PID）",
|
||
"B": "进程 ID、网络、挂载点、用户 ID、主机名等多种资源",
|
||
"C": "仅文件系统",
|
||
"D": "仅网络和内存"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "Linux Namespace 是容器技术的基础之一，提供了多种资源隔离类型：PID（进程号）、NET（网络栈）、MNT（挂载点）、UTS（主机名）、IPC（进程间通信）、USER（用户和组 ID）、Cgroup（cgroup 根目录）等。每种 namespace 负责隔离特定的系统资源，组合使用可以实现完整的环境隔离。因此 A、C、D 的描述都过于局限。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-009",
|
||
"type": "single_choice",
|
||
"difficulty": 1,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"沙箱"
|
||
],
|
||
"question": "以下哪种技术不属于操作系统级沙箱机制？",
|
||
"options": {
|
||
"A": "Linux seccomp",
|
||
"B": "Windows AppContainer",
|
||
"C": "Java 虚拟机（JVM）的字节码验证",
|
||
"D": "FreeBSD Capsicum"
|
||
},
|
||
"answer": "C",
|
||
"explanation": "JVM 的字节码验证属于应用程序层面的安全机制（语言运行时沙箱），而非操作系统内核级沙箱。seccomp 是 Linux 内核的系统调用过滤，AppContainer 是 Windows 8+ 的应用隔离容器，Capsicum 是 FreeBSD 的能力（capability）和沙箱框架，三者都是操作系统内核提供的沙箱机制。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-010",
|
||
"type": "single_choice",
|
||
"difficulty": 1,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"windows安全"
|
||
],
|
||
"question": "Windows 操作系统中，用于标识安全主体（用户、组、计算机）的唯一标识符是：",
|
||
"options": {
|
||
"A": "PID（进程 ID）",
|
||
"B": "SID（安全标识符）",
|
||
"C": "GUID（全局唯一标识符）",
|
||
"D": "MAC 地址"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "SID (Security Identifier) 是 Windows 中用于唯一标识安全主体的字符串，格式如 S-1-5-21-xxx。每个用户、组和计算机都有一个唯一的 SID，它被广泛用于访问控制列表（ACL）中的权限判定。PID 是进程标识符，GUID 是通用唯一标识符，MAC 地址是网络硬件地址，均非 Windows 安全主体的标识。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-011",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"windows安全",
|
||
"win32api"
|
||
],
|
||
"question": "在 Windows 安全模型中，Access Token（访问令牌）包含以下哪些信息？",
|
||
"options": {
|
||
"A": "仅用户的密码哈希",
|
||
"B": "用户的 SID、所属组的 SID 列表、特权列表和默认 DACL",
|
||
"C": "仅用户的登录时间和 IP 地址",
|
||
"D": "用户的浏览器 Cookie 和浏览历史"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "Access Token 是 Windows 安全子系统的核心数据结构，当用户登录时由系统创建。它包含：用户 SID、所属组 SID 列表、分配的特权（如 SeShutdownPrivilege）、默认所有者 SID、默认 DACL（自主访问控制列表）等。系统在每次访问安全对象时都会检查进程的 Access Token 来决定是否允许。A、C、D 的内容均不是 Access Token 的组成部分。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-012",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"windows安全",
|
||
"win32api"
|
||
],
|
||
"question": "以下 Win32 API 函数中，哪个用于创建一个受限的令牌（Restricted Token）以实现最小特权运行？",
|
||
"options": {
|
||
"A": "OpenProcessToken()",
|
||
"B": "CreateRestrictedToken()",
|
||
"C": "AdjustTokenPrivileges()",
|
||
"D": "DuplicateTokenEx()"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "CreateRestrictedToken() 可以基于现有令牌创建一个新的受限令牌，能删除特权、将 SID 标记为仅拒绝（deny-only）、添加受限 SID 等，常用于实现最低权限运行。OpenProcessToken() 用于打开进程的令牌句柄，AdjustTokenPrivileges() 用于启用/禁用令牌中的特权，DuplicateTokenEx() 用于复制令牌（可改变模拟级别），但只有 CreateRestrictedToken() 专门用于创建受限令牌。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-013",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"windows安全",
|
||
"win32api"
|
||
],
|
||
"question": "Windows 中的 UAC（User Account Control）机制的主要目的是：",
|
||
"options": {
|
||
"A": "加密用户的文件",
|
||
"B": "即使用户是管理员组成员，默认也以标准用户权限运行程序，需显式提升才能获得管理员权限",
|
||
"C": "自动更新操作系统补丁",
|
||
"D": "防止用户安装任何软件"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "UAC 是 Windows Vista 引入的安全特性。在 UAC 开启时，即使用户属于 Administrators 组，其进程默认也只获得标准用户令牌（filtered token），当操作需要管理员权限时，系统会弹出确认对话框（consent prompt）或要求输入管理员凭据（credential prompt）。这有效限制了恶意软件自动获取完全管理权限。A 是加密功能，C 是 Windows Update 功能，D 说法过于绝对。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-014",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"windows安全",
|
||
"win32api"
|
||
],
|
||
"question": "在 Win32 API 中，使用以下哪个函数可以检查当前进程是否有权限访问一个安全对象？",
|
||
"options": {
|
||
"A": "CreateFile()",
|
||
"B": "AccessCheck()",
|
||
"C": "VirtualAlloc()",
|
||
"D": "GetCurrentProcess()"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "AccessCheck() 函数用于检查指定的访问令牌是否拥有对安全对象的特定访问权限。它接受安全描述符（SECURITY_DESCRIPTOR）、客户端令牌、请求的访问掩码等参数，返回是否允许访问以及授予的访问权限。CreateFile() 虽然在打开文件时会进行访问检查，但它不是专门的权限检查函数；VirtualAlloc() 用于内存分配；GetCurrentProcess() 获取当前进程句柄。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-015",
|
||
"type": "single_choice",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"windows安全",
|
||
"win32api"
|
||
],
|
||
"question": "Windows 中安全描述符（SECURITY_DESCRIPTOR）的四个主要组成部分是：",
|
||
"options": {
|
||
"A": "SID、Token、Handle、Session",
|
||
"B": "Owner SID、Group SID、DACL、SACL",
|
||
"C": "用户名、密码、域、权限等级",
|
||
"D": "进程 ID、线程 ID、句柄表、访问掩码"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "SECURITY_DESCRIPTOR 是 Windows 中描述安全对象访问控制信息的结构体，包含四个核心组件：Owner SID（所有者安全标识符）、Group SID（主组安全标识符，主要用于 POSIX 子系统）、DACL（Discretionary ACL，自主访问控制列表，决定谁可以访问）、SACL（System ACL，系统访问控制列表，用于审计）。A、C、D 均不是安全描述符的组成部分。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-016",
|
||
"type": "single_choice",
|
||
"difficulty": 1,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"权限模型"
|
||
],
|
||
"question": "Linux 中 umask 的作用是：",
|
||
"options": {
|
||
"A": "设置用户的登录密码",
|
||
"B": "设置新创建文件和目录的默认权限掩码，屏蔽不需要的权限位",
|
||
"C": "查看当前系统的安全补丁状态",
|
||
"D": "加密文件系统"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "umask 是一个权限屏蔽码，用于确定新创建文件和目录的默认权限。例如 umask 为 022 时，新建文件权限为 644（rw-r--r--），新建目录权限为 755（rwxr-xr-x）。umask 屏蔽掉的权限位不会被赋予新文件。它不涉及密码设置、补丁查看或文件系统加密。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-017",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"沙箱"
|
||
],
|
||
"question": "Docker 容器在安全隔离方面与传统虚拟机的主要区别是：",
|
||
"options": {
|
||
"A": "Docker 容器比虚拟机隔离性更强",
|
||
"B": "Docker 容器共享宿主机内核，通过 Namespace 和 Cgroup 实现隔离；虚拟机有独立的内核",
|
||
"C": "虚拟机不支持网络隔离，Docker 支持",
|
||
"D": "Docker 容器不需要任何安全配置"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "Docker 容器与虚拟机的核心区别在于：容器直接运行在宿主机内核上，利用 Namespace 隔离系统资源、Cgroup 限制资源使用，因此共享内核；而虚拟机通过 Hypervisor 运行完整的操作系统，拥有独立的内核。由于共享内核，容器的隔离性理论上弱于虚拟机，容器逃逸可能直接影响宿主机。A 说反了；C 错误，虚拟机也支持网络隔离；D 错误，容器仍需安全配置（如 seccomp、AppArmor 等）。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-018",
|
||
"type": "single_choice",
|
||
"difficulty": 1,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"windows安全"
|
||
],
|
||
"question": "Windows 的 NTFS 文件系统支持的安全特性是：",
|
||
"options": {
|
||
"A": "文件级权限控制（ACL）",
|
||
"B": "仅支持文件加密，不支持权限控制",
|
||
"C": "仅支持目录级别的权限控制",
|
||
"D": "与 FAT32 的安全特性完全相同"
|
||
},
|
||
"answer": "A",
|
||
"explanation": "NTFS（New Technology File System）支持为每个文件和目录设置独立的 ACL（Access Control List），可以精确控制不同用户和组对该文件/目录的访问权限（读、写、执行等）。NTFS 还支持 EFS（Encrypting File System）加密和审计。FAT32 不支持文件级权限控制，因此 D 错误。B 和 C 的描述不准确。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-019",
|
||
"type": "single_choice",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"windows安全",
|
||
"win32api"
|
||
],
|
||
"question": "调用 Win32 API CreateProcessAsUser() 时，第一个参数 hToken 必须具有哪些访问权限才能成功创建进程？",
|
||
"options": {
|
||
"A": "TOKEN_QUERY",
|
||
"B": "TOKEN_QUERY | TOKEN_DUPLICATE | TOKEN_ASSIGN_PRIMARY",
|
||
"C": "TOKEN_ALL_ACCESS",
|
||
"D": "TOKEN_IMPERSONATE"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "CreateProcessAsUser() 要求传入的令牌句柄至少具有 TOKEN_QUERY（查询令牌信息）、TOKEN_DUPLICATE（复制令牌）和 TOKEN_ASSIGN_PRIMARY（将令牌分配给主令牌）三种访问权限。其中 TOKEN_ASSIGN_PRIMARY 是关键权限，允许将令牌用作新进程的主令牌。仅 TOKEN_QUERY（A）不够，TOKEN_ALL_ACCESS（C）包含所需权限但不是最低要求，TOKEN_IMPERSONATE（D）用于模拟而非进程创建。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sc-020",
|
||
"type": "single_choice",
|
||
"difficulty": 2,
|
||
"tags": [
|
||
"操作系统安全",
|
||
"权限模型"
|
||
],
|
||
"question": "RBAC（基于角色的访问控制）相比直接为用户分配权限的主要优势是：",
|
||
"options": {
|
||
"A": "完全消除了安全漏洞",
|
||
"B": "通过角色将用户和权限解耦，简化权限管理并支持职责分离",
|
||
"C": "使每个用户都成为管理员",
|
||
"D": "只适用于小型系统"
|
||
},
|
||
"answer": "B",
|
||
"explanation": "RBAC（Role-Based Access Control）引入角色作为用户和权限之间的中间层：管理员将权限分配给角色，再将角色分配给用户。这带来多个优势：1）用户变动时只需调整角色关联，无需逐一修改权限；2）支持职责分离（SoD），可约束某些角色不能同时被同一用户拥有；3）便于审计和合规。A 过于绝对，RBAC 不消除漏洞；C 与 RBAC 相悖；D 错误，RBAC 广泛用于大型企业系统。",
|
||
"source": null,
|
||
"related": []
|
||
}
|
||
]
|
||
} |