计算机系统安全的重要性和评测标准
安全的重要性
计算机安全问题的出发点
- 法律法规要求
- 人身安全性要求
- 信息/资产保护要求
计算机系统主要面临的威胁
- 软件漏洞
- 恶意用户
- 未授权的访问
- 人员误操作
- 硬件错误
计算机系统面临的攻击行为
- 恶意代码
- 系统渗透
- 中间人攻击
- 拒绝服务攻击
- 网络嗅探
- 信息泄漏(主要指无线网络被窃听)
- 社会工程(非技术角度)
计算机系统安全问题的分类
- 计算机安全
- 通信安全
操作系统安全的重要性
现代计算机软件开发的基本假设“硬件和操作系统是安全的”并不成立
安全系统的定义:它是从一个授权状态开始的,且不会进入一个非授权的状态 典型的操作系统安全漏洞
- Windows NT 漏洞,NFTS 文件系统将文件读取权限,同时赋予了可执行权限。导致了只读操作的用户可以越权执行文件,带来隐患
- Unix 系统 Ping 指令漏洞,Ping 功能是 setuid 为 root 的程序,在功能执行完成后应该丢弃 root 特权。但有一些版本的 Linux 中未能正确丢弃 root 权限
“安全”和“可信”名词解释 安全:定性描述 发布者角度而言 是绝对定义 可信:定量描述(可信等级) 接受者角度而言 是相对定义
安全操作系统研究史
- Multics OS:1965年,由贝尔实验室和 MIT 发起项目,目标是实现并发访问信息存储系统时的高安全性。BLP 机密安全模型,迈出了安全操作系统研究的重要一步
- J.P.Anderson 研究报告:1972年,提出了 引用监控器、引用验证机制、安全内核、安全建模
- XENIX OS:1986年,IBM公司基于 SCO XENIX 开发一款安全操作系统,命名为 Secure XENIX;1989年,转让给 TIS(Tusted Information System) 公司,更名为 Trusted XENIX,1992年,通过 TCSEC 评估等级 B2,1994年,达到 B2+
- Mach/TMach/DTMach/DTOS:分布式微内核安全系统
- TUNIS:用了 Turing Plus 语言对 UNIX 内核重新实现(他们认为采用非安全的编程语言-C,无法编写安全的操作系统;另一方面,UNIX 的模块化程度不够)
- SELinux:目前已经是 Linux 内核的一个模块,装载系统中。包括 Android
评测标准
主流评测标准对比 标准|发布组织|发布时间|特点 :—:|:—:|:—:|:—: TCSEC|美国标准|1985 ITSEC|欧盟标准||可以由商业机构进行评估 FC|美国联邦|| CC|国际标准||| GB17859|中国标准|1990|
各标准评估等级对比 名称|CC|TCSEC|ITSEC :—:|:—:|:—:|:—: 1|EAL0|D|E0 2|EAL1|\|\ 自主级|EAL2|C1|E1 受控访问级|EAL3|C2|E2 标记安全保护级|EAL4|B1|E3 结构化保护级|EAL5|B2|E4 3|EAL6|B3|E5 4|EAL7|A1|E6
TCSEC 对照功能:
- D级:安全性最低的级别,意味着没有通过安全认证的
- C类:自主保护类
- C1:自主安全保护级,实现了 DAC
- C2:受控制的访问控制级,支持以用户为单位的 DAC 机制,且引入审计机制
- B类:强制保护类
- B1:标记安全保护级,引入了 MAC 机制
- B2:结构保护级,要求具有形式化的安全模型、描述式顶层设计说明(DTDS)、更完善的MAC机制、可信通路机制、系统结构化设计、最小特权管理、隐蔽通道分析和处理等安全特征
- B3:安全域级,要求具有全面的存取控制(访问监控)机制、严格的系统结构化设计及TCB最小复杂性设计、审计实时报告机制、更好地分析和解决隐蔽通道问题等安全特征
- A类:验证设计类
- A1:要求具有系统形式化顶层设计说明(FTDS),并形式化验证FTDS与形式化模型的一致性,以及用形式化技术解决隐蔽通道问题等
CC 标准术语
- TOE:指作为评估主体的IT产品或系统,以及相关的指导性文档
- PP:指满足特定用户需求的、一类TOE的、一组与实现无关的安全要求
- ST:是作为一个既定TOE的评估基础使用的一组安全要求和规范
- TSP
- TSF
计算机系统基本安全概念和设计思想
访问控制思想
1969年,B.W.Lampson提出主体、客体和访问控制矩阵思想
对访问控制问题进行了抽象,在一个操作系统中,每一个实体组件都必须或者是主体、或者是客体、或者既是主体又是客体。
访问控制三要素:主体、客体、权限
- 客体(objects)是一个被动的实体,被调用、被访问、被读取
- 主体(subjects)是引起信息在客体之间流动的实体
- 权限
通用安全需求
- 机密性 指不要泄漏信息或资源,以及保护资源的存在性。加密及访问控制机制支持机密性
- 完整性 指对数据或资源的可信赖程度,防止不当或未授权的修改。包括了:数据的完整性 和 来源的完整性。访问控制支持完整性
- 可追究性 系统必须保证对数据的访问和系统能力的使用的个人行为可追究性。涉及标识、鉴别和审计等
- 可用性 指使用所期望的信息或资源的能力,合法用户的正常请求能够及时、正确、安全地得到服务或回应。(很难采用一个措施达到,需要全面的方法)
安全三要素
安全策略
关注做什么
分类:
- 机密性策略
- 完整性策略
策略描述方式:
- 高级策略语音 使用抽象的方法来表达对实体的策略约束,通常采用数学的或程序化的策略表示形式。如 DTEL 语言
- 低级策略语言 根据系统中程序的输入或调用选项来表达约束。通常有固定的表达模版
安全机制
关注如何做
计算机系统中安全机制的分类:
- 预防 prevention
- 检测 detection
- 恢复 recovery
经典安全机制概念:
- 引用监控器
- 引用验证机制 RVM
- 隔离性:必须防篡改
- 完整性:必须总被调用
- 可验证性:必须足够小
- 安全内核:在一个大型操作系统中,由相对小的软件部分负责安全性,且必须满足 RVM 的三原则,安全内核的设计与实现应符合:
- 完整性原则:主体引用客体时,必须通过安全内核
- 隔离性原则:安全内核具有防篡改能力
- 可验证性原则:安全功能可以被验证
安全保证
关注效果如何
安全建模思想
系统存在不安全性的原因主要有两个:
- 安全控制存在漏洞(安全机制不完善)
- 安全的定义有缺陷(安全策略不明确)
一个安全模型是对安全策略的清晰表述,其具有特点:
- 是精确、无歧义的
- 是简单和抽象的,易于理解
- 只涉及安全性质,不限制系统的功能及其实现
安全模型的作用
- 明确安全性的定义
- 指导设计和实现
- 为安全测试提供上下文
- 提供论证保障
安全周界和可信计算基
系统边界和安全周界 可信计算基 Trust Computing Base/TCB 一旦可信计算机基的某个构件出现程序错误或者安全隐患,就对整个系统的安全造成危害
- 引用验证机制的软硬件
- 标识鉴别机制
- 审计机制
- 可信软件
访问控制机制
访问控制机制的任务
- 授权:确定哪些主体有权访问哪些客体
- 决策:确定访问权限
- 实施访问权限
理论基础:引用监视器
自主访问控制(DAC)
定义
自主访问控制是 基于客体所属用户/组身份,以及 需知原则来约束对客体的访问 的一种手段。这种控制是自主的意义在于:具有特定访问权限的一个主体能够将该权限(直接或间接的)传递给另一个主体。
自主的体现:
- 一个用户可以自主地说明他所拥有的资源允许系统中哪些用户以何种权限进行共享。
- 其他具有授权某种访问权利的用户能够自主地将访问权或访问权的某个子集授予另外的用户
分类
- 基于行的访问控制矩阵信息:连接可访问客体到指定用户。
- 基于列的访问控制矩阵信息:连接用户列表到指定的客体。
基于行的自主访问控制机制
在每个主体上都附加一个该主体可访问客体的明细表,根据表中信息的不同可分成三种形式:
- 能力表:对于每个用户,系统有一个能力表,采用硬件、软件或加密技术对系统的能力表进行保护,防止篡改。
- 前缀表:对每个主体赋予前缀表,包括受 保护客体名 和 主体对其的访问权限,当主体要访问客体时,自主存取控制机制将检查主体的前缀是否具有权限。
- 口令:主体保存每个客体权限的口令,访问前先向操作系统提供该口令。
基于列的自主存取控制机制
在客体上都附加一个主体明细表,表示存取控制矩阵。 Linux 实现方法:
- “拥有者/同组用户/其他用户”模式(9bit 模式):在文件头添加9bit(rwxrwxrwx)来表征
- ACL + 9bit 相结合:ACL 会给文件附加一个结构体
(type定义是用户or组,prem是具体内容),可以和 9bit 模式兼容
关于ACL 用户可以对一个客体对应的ACL进行“授权”、“取消”、“查阅”等操作 比如:Linux 2.6 以上的 setfacl, getfacl, chacl 等命令 命令格式 setfacl -m u:testu1:rwx, g:textg1:r file1
自主访问控制无法防止木马等攻击行为
强制访问控制(MAC)
主体和客体会由管理员强制赋予相关的管理标签
不可上读、不可下写
可追究机制
标识与鉴别机制
操作系统采用唯一的、不可伪造UID,对用户标识
鉴别是将用户标识符与用户联系的过程
鉴别机制的特点:
- 在进行任何需要 TCB 仲裁的操作前,TCB都要求用户标识他们自己
- TCB 必须维护认证数据
- TCB 必须保护认证数据,防止被非法使用
- TCB 应能维护、保护和显示所有账户的状态信息
鉴别-口令保护机制:
- 用户设置口令时,TCB 不应进行查重机制
- TCB 应以单向加密方式存储口令
- 在口令输入或显示设备上,TCB 应自动隐藏口令明文
- 在普通操作中,TCB 应禁止使用空口令。只有系统管理员可以在某些特殊操作中,在受控方式下使用
- TCB 应提供一种保护机制允许用户更换自己的口令,TCB 还必须保证只有系统管理员才能设置或初始化用户口令。
- 对每一个用户或每一组用户,TCB 必须加强口令失效管理:“口令的使用期超过系统的指定值后,系统应要求用户修改口令。” 系统管理员的口令有效期通常比普通用户短,过期口令将失效。只有系统管理员才能进行口令时效控制。
实现的技术要点:
- 对口令内部存储的访问控制和加密处理
- 口令从终端到认证机传输过程的保护
- 登录尝试次数的限制
- 用户安全属性的检查,比如用户进程的安全级、计算特权集、审计屏蔽码等
- 审计处理,对口令的使用和更改进行审计;及时通知系统管理员、通知用户等