跳转到内容

强制访问控制:修订间差异

维基百科,自由的百科全书
删除的内容 添加的内容
Cewbot留言 | 贡献
bot: 清理跨語言連結RBAC成為內部連結:標題經繁簡轉換 編輯摘要的red link條目存在
Cewbot留言 | 贡献
bot: 清理跨語言連結Astra Linux成為內部連結:編輯摘要的red link經繁簡轉換後存在
 
(未显示10个用户的19个中间版本)
第1行: 第1行:
{{Translating||40|time=2017-02-12T22:09:07+00:00}}
{{Translating||50|time=2017-02-12T22:09:07+00:00}}
{{NoteTA
{{NoteTA
|G1=IT
|G1=IT
}}
}}
'''强制访问控制'''({{lang-en|'''mandatory access control'''}},缩写'''MAC''')在[[计算机安全]]领域指一种由[[操作系统]]约束的[[存取控制]],目标是限制主体或发起者访问或对对象或目标执行某种操作的能力。在实践中,主体通常是一个[[进程]]或[[线程]],对象可能是[[電腦檔案|文件]]、[[目录 (文件系统)|目录]]、[[传输控制协议|TCP]]/[[用户数据报协议|UDP]]端口、[[共享内存]]段、I/O设备等。主体和对象各自具有一组安全属性。每当主体尝试访问对象时,都会由操作系统[[内核]]强制施行授权规则——检查安全属性并决定是否可进行访问。任何对象对任何对象的任何操作都将根据一组授权规则(也称策略)进行测试,决定操作是否允许。在[[数据库]]管理系统中也存在访问控制机制,因而也可以应用强制访问控制;在此环境下,对象为表、视图、过程等。
'''强制访问控制'''({{lang-en|'''mandatory access control'''}},缩写'''MAC''')在[[计算机安全]]领域指一种由[[操作系统]]约束的[[存取控制]],目标是限制主体或发起者访问或对对象或目标执行某种操作的能力。在实践中,主体通常是一个[[进程]]或[[线程]],对象可能是[[電腦檔案|文件]]、[[目录 (文件系统)|目录]]、[[传输控制协议|TCP]]/[[用户数据报协议|UDP]]端口、[[共享内存]]段、I/O设备等。主体和对象各自具有一组安全属性。每当主体尝试访问对象时,都会由操作系统[[内核]]强制施行授权规则——检查安全属性并决定是否可进行访问。任何主體对任何物件的任何操作都将根据一组授权规则(也称策略)进行测试,决定操作是否允许。在[[数据库]]管理系统中也存在访问控制机制,因而也可以应用强制访问控制;在此环境下,对象为表、视图、过程等。


通过强制访问控制,安全策略由安全策略管理员集中控制;用户无权覆盖策略,例如不能给被否决而受到限制的文件授予访问权限。相比而言,[[自主访问控制]](DAC)也控制受试者访问对象的能力,但允许用户进行策略决策和/或分配安全属性。(传统[[UNIX|Unix]]系统的用户、组和读-写-执行就是一种DAC。)启用MAC的系统允许策略管理员实现组织范围的安全策略。在MAC(不同于DAC)下,用户不能覆盖或修改策略,无论为意外或故意。这使安全管理员定义的中央策略得以在原则上保证向所有用户强制实施。
通过强制访问控制,安全策略由安全策略管理员集中控制;用户无权覆盖策略,例如不能给被否决而受到限制的文件授予访问权限。相比而言,[[自主访问控制]](DAC)也控制主体访问对象的能力,但允许用户进行策略决策和/或分配安全属性。(传统[[UNIX|Unix]]系统的用户、组和读-写-执行就是一种DAC。)启用MAC的系统允许策略管理员实现组织范围的安全策略。在MAC(不同于DAC)下,用户不能覆盖或修改策略,无论为意外或故意。这使安全管理员定义的中央策略得以在原则上保证向所有用户强制实施。


在历史上和传统上,MAC与{{tsl|en|Multi-level security|多层安全}}(MLS)和专业的军用系统密切相关。在此环境中,MAC意味着高度严格以满足MLS系统的约束。但在最近,MAC已从MLS本身中发展出来,并变得更加主流。最近的MAC实现有诸如面向Linux的[[安全增强式Linux|SELinux]]和{{tsl|en|AppArmor}},以及面向Windows的[[强制完整性控制]],它们使管理员得以关注没有严格或MLS约束时遇到的如网络攻击或恶意软件等问题。
在历史上和传统上,MAC与{{tsl|en|Multi-level security|多层安全}}(MLS)和专业的军用系统密切相关。在此环境中,MAC意味着高度严格以满足MLS系统的约束。但在最近,MAC已从MLS本身中发展出来,并变得更加主流。最近的MAC实现有诸如面向Linux的[[安全增强式Linux|SELinux]]和[[AppArmor]],以及面向Windows的[[强制完整性控制]],它们使管理员得以关注没有严格或MLS约束时遇到的如网络攻击或恶意软件等问题。


== 历史背景和对多层安全的影响 ==
== 历史背景和对多层安全的影响 ==
历史上,MAC与作为保护美国等级信息的{{tsl|en|Multi-Level Security|多层安全}}(MLS)手段密切相关。{{tsl|en|Trusted Computer System Evaluation Criteria|可信计算机系统评估标准}}(TCSEC)就是就这一主题的开创性工作,其中将MAC定义为“基于对象中包含信息的敏感性(由标签表示)来显示对对象的访问途径以及对象访问这种敏感信息的授权”。MAC的早期实现有Honeywell的SCOMP、USAF SACDIN、NSA Blacker,以及的[[波音]]MLS LAN。
历史上,MAC与作为保护美国機密信息的{{tsl|en|Multi-Level Security|多层安全}}(MLS)手段密切相关。{{tsl|en|Trusted Computer System Evaluation Criteria|可信计算机系统评估标准}}(TCSEC)就是就这一主题的开创性工作,其中将MAC定义为“基于对象中包含信息的敏感性(由标签表示)来显示对对象的访问途径以及对象访问这种敏感信息的授权”。MAC的早期实现有Honeywell的SCOMP、USAF SACDIN、NSA Blacker,以及的[[波音]]MLS LAN。


术语MAC中的“强制性”已经因其在军事系统中的使用而获得了特殊含义。在这方面,MAC意味着非常高的健壮性,确保控制机制能够抵抗任何类型的破坏,从而使他们能够执行由政府命令授权的访问控制,诸如面向美国等级信息的[[第12958號行政命令]] 。强制施行的保证性要求要高于商业应用,因此这不允许采用“尽力而为”的机制。MAC只接受能够绝对或者几乎绝对地保证任务执行的机制。这点对于不熟悉高保证策略的人来说可能很困难或者被假定为不切实际。
术语MAC中的“强制性”已经因其在军事系统中的使用而获得了特殊含义。在这方面,MAC意味着非常高的抵抗性,确保控制机制能够抵抗任何类型的破坏,从而使他们能够执行由政府命令授权的访问控制,诸如面向美国等级信息的[[第12958號行政命令]] 。强制施行的保证性要求要高于商业应用,因此这不允许采用“尽力而为”的机制。MAC只接受能够绝对或者几乎绝对地保证任务执行的机制。这点对于不熟悉高保证策略的人来说可能很困难或者被假定为不切实际。


== MAC系统强度 ==
== 系统强度 ==
=== 强度等级 ===
在某些系统中,用户有权决定是否向其他任何用户授予访问权限。为允许这点,所有用户都必须有所有数据的审查许可。这不是MLS系统所需必要条件。如果个人或进程可能被拒绝访问系统环境中的任何数据,则系统必须可信以强制执行MAC。由于可能存在各种级别的数据等级和用户许可,这也显示了健壮性的量化指标。{{TransH}}例如,more robustness is indicated for system environments 包含划分等级[[国家机密|最高机密]]信息 and uncleared users than for one with Secret information and users cleared to at least Confidential. To promote consistency and eliminate subjectivity in degrees of robustness, an extensive scientific analysis and risk assessment of the topic produced a landmark benchmark standardization quantifying security robustness capabilities of systems and mapping them to the degrees of trust warranted for various security environments. 该结果记录于CSC-STD-004-85。<ref name="Ref_1985">{{Cite web|url=http://csrc.nist.gov/secpubs/rainbow/std004.txt|title=Technical Rational Behind CSC-STD-003-85: Computer Security Requirements|accessdate=2008-03-15|date=1985-06-25|archiveurl=https://web.archive.org/web/20070715134110/http://csrc.nist.gov/secpubs/rainbow/std004.txt|archivedate=July 15, 2007}}</ref> Two relatively independent components of robustness were defined: Assurance Level and Functionality. Both were specified with a degree of precision that warranted significant confidence in certifications based on these criteria.{{TransF}}
在某些系统中,用户有权决定是否向其他任何用户授予访问权限。为允许这点,所有用户都必须有所有数据的审查许可。这不是MLS系统所需必要条件。如果个人或进程可能被拒绝访问系统环境中的任何数据,则系统必须可信以强制执行MAC。由于可能存在各种级别的数据等级和用户许可,这也显示了健壮性的量化指标。例如,一个包含等级[[国家机密|最高机密]]信息和等级为未批准的用户的系统相较于一个包含等级为绝密的信息和等级为秘密的用户的系统具有更高的健壮性。为了维持健壮性量化指标的一致性以及尽可能地消除主观人为因素,一项针对该问题的大规模科学分析和风险评估提出了标志性的测试标准,用以量化系统的安全健壮性,并根据其能够保证的安全等级为其分级。该结果记录于CSC-STD-004-85。<ref name="Ref_1985">{{Cite web|url=http://csrc.nist.gov/secpubs/rainbow/std004.txt|title=Technical Rational Behind CSC-STD-003-85: Computer Security Requirements|accessdate=2008-03-15|date=1985-06-25|archiveurl=https://web.archive.org/web/20070715134110/http://csrc.nist.gov/secpubs/rainbow/std004.txt|archivedate=July 15, 2007}}</ref>健壮性的两个相对独立的组成部分可以被定义为保障等级和功能性,两者都可以被阐述为一个系统在特定标准下能够保证的其审查的精确性。


== MAC系统强度评估 ==
=== 强度评估 ===
{{TransH}}
{{TransH}}
The {{tsl|en|Common Criteria}}<ref name="Ref_a">{{cite web | url = http://www.commoncriteriaportal.org/ | title = The Common Criteria Portal | accessdate = 2008-03-15}}</ref> is based on this science and it intended to preserve the Assurance Level as {{tsl|en|Evaluation Assurance Level|EAL levels}} and the functionality specifications as {{tsl|en|Protection Profile}}s. Of these two essential components of objective robustness benchmarks, only EAL levels were faithfully preserved. In one case, {{tsl|en|TCSEC}} level C2<ref name="Department1985">{{cite web | url = https://fas.org/irp/nsa/rainbow/std001.htm | title = DoD 5200.28-STD: Trusted Computer System Evaluation Criteria | author = US Department of Defense | date = December 1985 | accessdate = 2008-03-15}}</ref> (not a MAC capable category) was fairly faithfully preserved in the Common Criteria, as the {{tsl|en|Controlled Access Protection Profile}} (CAPP).<ref name="Ref_1999">{{cite web | url = http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/PP_OS_CA_V1.d/ | title = Controlled Access Protection Profile, Version 1.d | date = 1999-10-08 | publisher = National Security Agency | accessdate = 2008-03-15}}</ref> {{tsl|en|Multilevel security}} (MLS) Protection Profiles (such as MLSOSPP similar to B2)<ref name="Ref_2001">{{cite web | title = Protection Profile for Multi-Level Operating Systems in Environments Requiring Medium Robustness, Version 1.22 | url = http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/pp_os_ml_mr_v1.22/ | publisher = National Security Agency | date = 2001-05-23 | accessdate = 2008-03-15}}</ref> is more general than B2. They are pursuant to MLS, but lack the detailed implementation requirements of their {{tsl|en|Trusted Computer System Evaluation Criteria|Orange Book}} predecessors, focusing more on objectives. This gives certifiers more subjective flexibility in deciding whether the evaluated product’s technical features adequately achieve the objective, potentially eroding consistency of evaluated products and making it easier to attain certification for less trustworthy products. For these reasons, the importance of the technical details of the Protection Profile is critical to determining the suitability of a product.
The [[Common Criteria]]<ref name="Ref_a">{{cite web | url = http://www.commoncriteriaportal.org/ | title = The Common Criteria Portal | accessdate = 2008-03-15 | archive-date = 2006-07-18 | archive-url = https://web.archive.org/web/20060718074701/http://www.commoncriteriaportal.org/ | dead-url = yes }}</ref> is based on this science and it intended to preserve the Assurance Level as {{tsl|en|Evaluation Assurance Level|EAL levels}} and the functionality specifications as {{tsl|en|Protection Profile}}s. Of these two essential components of objective robustness benchmarks, only EAL levels were faithfully preserved. In one case, {{tsl|en|TCSEC}} level C2<ref name="Department1985">{{cite web | url = https://fas.org/irp/nsa/rainbow/std001.htm | title = DoD 5200.28-STD: Trusted Computer System Evaluation Criteria | author = US Department of Defense | date = December 1985 | accessdate = 2008-03-15 | archive-date = 2008-03-17 | archive-url = https://web.archive.org/web/20080317034210/http://www.fas.org/irp/nsa/rainbow/std001.htm | dead-url = no }}</ref> (not a MAC capable category) was fairly faithfully preserved in the Common Criteria, as the {{tsl|en|Controlled Access Protection Profile}} (CAPP).<ref name="Ref_1999">{{cite web | url = http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/PP_OS_CA_V1.d/ | title = Controlled Access Protection Profile, Version 1.d | date = 1999-10-08 | publisher = National Security Agency | accessdate = 2008-03-15 | archive-date = 2012-02-07 | archive-url = https://web.archive.org/web/20120207001837/http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/PP_OS_CA_V1.d/ | dead-url = yes }}</ref> {{tsl|en|Multilevel security}} (MLS) Protection Profiles (such as MLSOSPP similar to B2)<ref name="Ref_2001">{{cite web | title = Protection Profile for Multi-Level Operating Systems in Environments Requiring Medium Robustness, Version 1.22 | url = http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/pp_os_ml_mr_v1.22/ | publisher = National Security Agency | date = 2001-05-23 | accessdate = 2008-03-15 | archive-date = 2009-03-30 | archive-url = https://web.archive.org/web/20090330203501/http://www.niap-ccevs.org/cc-scheme/pp/pp.cfm/id/pp_os_ml_mr_v1.22/ | dead-url = yes }}</ref> is more general than B2. They are pursuant to MLS, but lack the detailed implementation requirements of their {{tsl|en|Trusted Computer System Evaluation Criteria|Orange Book}} predecessors, focusing more on objectives. This gives certifiers more subjective flexibility in deciding whether the evaluated product’s technical features adequately achieve the objective, potentially eroding consistency of evaluated products and making it easier to attain certification for less trustworthy products. For these reasons, the importance of the technical details of the Protection Profile is critical to determining the suitability of a product.


Such an architecture prevents an authenticated user or process at a specific classification or trust-level from accessing information, processes, or devices in a different level. This provides a containment mechanism of users and processes, both known and unknown (an unknown program (for example) might comprise an untrusted application where the system should monitor and/or control accesses to devices and files).{{TransF}}
Such an architecture prevents an authenticated user or process at a specific classification or trust-level from accessing information, processes, or devices in a different level. This provides a containment mechanism of users and processes, both known and unknown (an unknown program (for example) might comprise an untrusted application where the system should monitor and/or control accesses to devices and files).{{TransF}}
第28行: 第29行:


* Amon Ott's RSBAC (Rule Set Based Access Control) provides a framework for Linux kernels that allows several different security policy / decision modules. One of the models implemented is Mandatory Access Control model. A general goal of RSBAC design was to try to reach (obsolete) Orange Book (TCSEC) B1 level. The model of mandatory access control used in RSBAC is mostly the same as in Unix System V/MLS, Version 1.2.1 (developed in 1989 by the National Computer Security Center of the USA with classification B1/TCSEC). RSBAC requires a set of patches to the stock kernel, which are maintained quite well by the project owner.
* Amon Ott's RSBAC (Rule Set Based Access Control) provides a framework for Linux kernels that allows several different security policy / decision modules. One of the models implemented is Mandatory Access Control model. A general goal of RSBAC design was to try to reach (obsolete) Orange Book (TCSEC) B1 level. The model of mandatory access control used in RSBAC is mostly the same as in Unix System V/MLS, Version 1.2.1 (developed in 1989 by the National Computer Security Center of the USA with classification B1/TCSEC). RSBAC requires a set of patches to the stock kernel, which are maintained quite well by the project owner.
* An [[美国国家安全局]] research project called [[安全增强式Linux|SELinux]] added a Mandatory Access Control architecture to the [[Linux内核]], which was merged into the mainline version of Linux in August 2003. It utilizes a Linux 2.6 kernel feature called [[Linux安全模組|LSM]] (Linux Security Modules interface). [[Red Hat Enterprise Linux]] version 4 (and later versions) come with an SELinux-enabled kernel. Although SELinux is capable of restricting all processes in the system, the default ''targeted'' policy in [[Red Hat Enterprise Linux|RHEL]] confines the most vulnerable programs from the ''unconfined domain'' in which all other programs run. RHEL 5 ships 2 other binary policy types: ''strict'', which attempts to implement [[最小权限原则]], and ''MLS'', which is based on ''strict'' and adds {{tsl|en|Multilevel security|MLS}} labels. RHEL 5 contains additional MLS enhancements and received 2 {{tsl|en|Labeled Security Protection Profile|LSPP}}/RBACPP/CAPP/EAL4+ certifications in June 2007.<ref name="National">{{cite web | author = National Information Assurance Partnership | url = http://www.niap-ccevs.org/cc%2Dscheme/vpl/ | title =The Common Criteria Evaluation and Validation Scheme Validated Products List | accessdate = 2008-03-15 |archiveurl = https://web.archive.org/web/20080314060625/http://www.niap-ccevs.org/cc-scheme/vpl/ <!-- Bot retrieved archive --> |archivedate = 2008-03-14}}</ref>
* An [[美国国家安全局]] research project called [[安全增强式Linux|SELinux]] added a Mandatory Access Control architecture to the [[Linux内核]], which was merged into the mainline version of Linux in August 2003. It utilizes a Linux 2.6 kernel feature called [[Linux安全模組|LSM]] (Linux Security Modules interface). [[Red Hat Enterprise Linux]] version 4 (and later versions) come with an SELinux-enabled kernel. Although SELinux is capable of restricting all processes in the system, the default ''targeted'' policy in [[Red Hat Enterprise Linux|RHEL]] confines the most vulnerable programs from the ''unconfined domain'' in which all other programs run. RHEL 5 ships 2 other binary policy types: ''strict'', which attempts to implement [[最小权限原则]], and ''MLS'', which is based on ''strict'' and adds MLS labels. RHEL 5 contains additional MLS enhancements and received 2 {{tsl|en|Labeled Security Protection Profile|LSPP}}/RBACPP/CAPP/EAL4+ certifications in June 2007.<ref name="National">{{cite web | author = National Information Assurance Partnership | url = http://www.niap-ccevs.org/cc%2Dscheme/vpl/ | title =The Common Criteria Evaluation and Validation Scheme Validated Products List | accessdate = 2008-03-15 |archiveurl = https://web.archive.org/web/20080314060625/http://www.niap-ccevs.org/cc-scheme/vpl/ <!-- Bot retrieved archive --> |archivedate = 2008-03-14}}</ref>
* {{tsl|en|TOMOYO Linux}} is a lightweight MAC implementation for [[Linux]] and [[嵌入式Linux]], developed by {{tsl|en|NTT Data Corporation}}. It has been merged in Linux Kernel mainline version 2.6.30 in June 2009.<ref name="Ref_b">{{cite web | title=TOMOYO Linux, an alternative Mandatory Access Control | publisher=Linux Kernel Newbies | work=Linux 2 6 30 | url=http://kernelnewbies.org/Linux_2_6_30#head-eeb259e0ba81d96d59015b8f79456d9a5283c650}}</ref> Differently from the ''label-based'' approach used by [[安全增强式Linux]], TOMOYO Linux performs a ''pathname-based'' {{tsl|en|Mandatory Access Control}}, separating security domains according to process invocation history, which describes the system behavior. Policy are described in terms of pathnames. A security domain is simply defined by a process call chain, and represented as a string. There are 4 modes: disabled, ''learning'', permissive, enforcing. Administrators can assign different modes for different domains. TOMOYO Linux introduced the "learning" mode, in which the accesses occurred in the kernel are automatically analyzed and stored to generate MAC policy: this mode can be used as first step of policy writing, making it easy to customize later.
* {{tsl|en|TOMOYO Linux}} is a lightweight MAC implementation for [[Linux]] and [[嵌入式Linux]], developed by {{tsl|en|NTT Data Corporation}}. It has been merged in Linux Kernel mainline version 2.6.30 in June 2009.<ref name="Ref_b">{{cite web | title=TOMOYO Linux, an alternative Mandatory Access Control | publisher=Linux Kernel Newbies | work=Linux 2 6 30 | url=http://kernelnewbies.org/Linux_2_6_30#head-eeb259e0ba81d96d59015b8f79456d9a5283c650 | accessdate=2017-02-12 | archive-date=2012-04-05 | archive-url=https://www.webcitation.org/66hmvofuI?url=http://kernelnewbies.org/Linux_2_6_30#head-eeb259e0ba81d96d59015b8f79456d9a5283c650 | dead-url=no }}</ref> Differently from the ''label-based'' approach used by [[安全增强式Linux]], TOMOYO Linux performs a ''pathname-based'' [[Mandatory Access Control]], separating security domains according to process invocation history, which describes the system behavior. Policy are described in terms of pathnames. A security domain is simply defined by a process call chain, and represented as a string. There are 4 modes: disabled, ''learning'', permissive, enforcing. Administrators can assign different modes for different domains. TOMOYO Linux introduced the "learning" mode, in which the accesses occurred in the kernel are automatically analyzed and stored to generate MAC policy: this mode can be used as first step of policy writing, making it easy to customize later.
* [[SUSE]] ({{As of|2006|alt=now}} supported by [[Novell]]) and [[Ubuntu|Ubuntu]] 7.10 have added a MAC implementation called {{tsl|en|AppArmor}}. AppArmor utilizes a Linux 2.6 kernel feature called [[Linux安全模組|LSM]] (Linux Security Modules interface). LSM provides a kernel [[应用程序接口|API]] that allows modules of kernel code to govern ACL (DAC ACL, access control lists). AppArmor is not capable of restricting all programs and is optionally in the Linux kernel as of version 2.6.36.<ref name="Ref_c">{{cite web | title=Linux 2.6.36 released 20 October 2010 | publisher=Linux Kernel Newbies | work=Linux 2.6.36 | url=http://kernelnewbies.org/Linux_2_6_36}}</ref>
* [[SUSE]] ({{As of|2006|alt=now}} supported by [[Novell]]) and [[Ubuntu]] 7.10 have added a MAC implementation called [[AppArmor]]. AppArmor utilizes a Linux 2.6 kernel feature called [[Linux安全模組|LSM]] (Linux Security Modules interface). LSM provides a kernel [[应用程序接口|API]] that allows modules of kernel code to govern ACL (DAC ACL, access control lists). AppArmor is not capable of restricting all programs and is optionally in the Linux kernel as of version 2.6.36.<ref name="Ref_c">{{cite web | title=Linux 2.6.36 released 20 October 2010 | publisher=Linux Kernel Newbies | work=Linux 2.6.36 | url=http://kernelnewbies.org/Linux_2_6_36 | accessdate=2017-02-12 | archive-date=2018-06-10 | archive-url=https://web.archive.org/web/20180610181138/https://kernelnewbies.org/Linux_2_6_36 | dead-url=no }}</ref>
* [[Linux]] and many other Unix distributions have MAC for CPU (multi-ring), disk, and memory; while OS software may not manage privileges well, Linux became famous during the 1990s as being more secure and far more stable than non-Unix alternatives. Linux distributors disable MAC to being at best DAC for some devices - although this is true for any consumer electronics available today.
* [[Linux]] and many other Unix distributions have MAC for CPU (multi-ring), disk, and memory; while OS software may not manage privileges well, Linux became famous during the 1990s as being more secure and far more stable than non-Unix alternatives. Linux distributors disable MAC to being at best DAC for some devices - although this is true for any consumer electronics available today.
* {{tsl|en|grsecurity}} is a patch for the Linux kernel providing a MAC implementation (precisely, it is a [[RBAC]] implementation). {{tsl|en|Hardened Gentoo}} offers a pre-patched kernel with grsecurity. grsecurity is not implemented via the [[Linux安全模組|LSM]] API.<ref name="Ref_d">{{cite web | title=Why doesn't grsecurity use LSM? | url=http://grsecurity.net/lsm.php}}</ref>
* {{tsl|en|grsecurity}} is a patch for the Linux kernel providing a MAC implementation (precisely, it is a [[RBAC]] implementation). {{tsl|en|Hardened Gentoo}} offers a pre-patched kernel with grsecurity. grsecurity is not implemented via the [[Linux安全模組|LSM]] API.<ref name="Ref_d">{{cite web | title=Why doesn't grsecurity use LSM? | url=http://grsecurity.net/lsm.php | accessdate=2017-02-12 | archive-date=2016-07-22 | archive-url=https://web.archive.org/web/20160722095122/http://grsecurity.net/lsm.php | dead-url=yes }}</ref>
* [[微软]] Starting with [[Windows Vista]] and [[Windows Server 2008|Server 2008]] Windows incorporates [[强制完整性控制]], which adds ''Integrity Levels'' (IL) to processes running in a login session. MIC restricts the access permissions of applications that are running under the same user account and which may be less trustworthy. Five integrity levels are defined: Low, Medium, High, System, and Trusted Installer.<ref name="symantec">{{cite web | url = http://www.symantec.com/enterprise/security_response/weblog/2006/08/windows_vista_windows_security.html | title = Analysis of the Windows Vista Security Model | author = Matthew Conover | publisher = [[赛门铁克]] | accessdate = 2007-10-08}}</ref> Processes started by a regular user gain a Medium IL; [[使用者帳戶控制|elevated]] processes have High IL.<ref name="steve">{{cite web | url = http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx | title = Mandatory Integrity Control in Windows Vista | author = Steve Riley | accessdate = 2007-10-08}}</ref> While processes inherit the integrity level of the process that spawned it, the integrity level can be customized on a per-process basis: e.g. [[Internet Explorer 7|IE7]] and downloaded executables run with Low IL. Windows controls access to [[Windows对象管理|objects]] based on ILs, as well as for defining the boundary for window messages via [[用户界面特权隔离]]. Named [[Windows对象管理|objects]], including [[電腦檔案|files]], [[注册表|registry]] keys or other [[行程|processes]] and [[线程|threads]], have an entry in the [[存取控制串列|ACL]] governing access to them that defines the minimum IL of the process that can use the object. MIC enforces that a process can write to or delete an object only when its IL is equal to or higher than the object’s IL. Furthermore, to prevent access to sensitive data in memory, processes can’t open processes with a higher IL for read access.<ref name="mark">{{cite web | url = http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx | title = PsExec, User Account Control and Security Boundaries | accessdate = 2007-10-08 | author = {{tsl|en|Mark Russinovich}}}}</ref>
* [[微软]] Starting with [[Windows Vista]] and [[Windows Server 2008|Server 2008]] Windows incorporates [[强制完整性控制]], which adds ''Integrity Levels'' (IL) to processes running in a login session. MIC restricts the access permissions of applications that are running under the same user account and which may be less trustworthy. Five integrity levels are defined: Low, Medium, High, System, and Trusted Installer.<ref name="symantec">{{cite web | url = http://www.symantec.com/enterprise/security_response/weblog/2006/08/windows_vista_windows_security.html | title = Analysis of the Windows Vista Security Model | author = Matthew Conover | publisher = [[赛门铁克]] | accessdate = 2007-10-08 | deadurl = yes | archiveurl = https://web.archive.org/web/20080325024250/http://www.symantec.com/enterprise/security_response/weblog/2006/08/windows_vista_windows_security.html | archivedate = 2008-03-25 }}</ref> Processes started by a regular user gain a Medium IL; [[使用者帳戶控制|elevated]] processes have High IL.<ref name="steve">{{cite web | url = http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx | title = Mandatory Integrity Control in Windows Vista | author = Steve Riley | accessdate = 2007-10-08 | archive-url = https://web.archive.org/web/20070929084227/http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx | archive-date = 2007-09-29 | dead-url = yes }}</ref> While processes inherit the integrity level of the process that spawned it, the integrity level can be customized on a per-process basis: e.g. [[Internet Explorer 7|IE7]] and downloaded executables run with Low IL. Windows controls access to [[Windows对象管理|objects]] based on ILs, as well as for defining the boundary for window messages via [[用户界面特权隔离]]. Named [[Windows对象管理|objects]], including [[電腦檔案|files]], [[注册表|registry]] keys or other [[行程|processes]] and [[线程|threads]], have an entry in the [[存取控制串列|ACL]] governing access to them that defines the minimum IL of the process that can use the object. MIC enforces that a process can write to or delete an object only when its IL is equal to or higher than the object’s IL. Furthermore, to prevent access to sensitive data in memory, processes can’t open processes with a higher IL for read access.<ref name="mark">{{cite web | url = http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx | title = PsExec, User Account Control and Security Boundaries | accessdate = 2007-10-08 | author = {{tsl|en|Mark Russinovich}} | archive-url = https://web.archive.org/web/20100415164810/http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx | archive-date = 2010-04-15 | dead-url = yes }}</ref>
* [[FreeBSD]] supports ''Mandatory Access Control'', implemented as part of the TrustedBSD project. It was introduced in FreeBSD 5.0. Since FreeBSD 7.2, MAC support is enabled by default. The framework is extensible; various MAC modules implement policies such as {{tsl|en|Biba Integrity Model|Biba}} and {{tsl|en|Multi-Level Security}}.
* [[FreeBSD]] supports ''Mandatory Access Control'', implemented as part of the TrustedBSD project. It was introduced in FreeBSD 5.0. Since FreeBSD 7.2, MAC support is enabled by default. The framework is extensible; various MAC modules implement policies such as {{tsl|en|Biba Integrity Model|Biba}} and {{tsl|en|Multi-Level Security}}.
* Sun's {{tsl|en|Trusted Solaris}} uses a mandatory and system-enforced access control mechanism (MAC), where clearances and labels are used to enforce a security policy. However note that the capability to manage labels does not imply the kernel strength to operate in {{tsl|en|Multi-Level Security}} mode{{Citation needed|date=November 2009}}. Access to the labels and control mechanisms are not{{Citation needed|date=November 2009}} robustly protected from corruption in protected domain maintained by a kernel. The applications a user runs are combined with the security label at which the user works in the session. Access to information, programs and devices are only weakly controlled{{Citation needed|date=November 2009}}.
* Sun's {{tsl|en|Trusted Solaris}} uses a mandatory and system-enforced access control mechanism (MAC), where clearances and labels are used to enforce a security policy. However note that the capability to manage labels does not imply the kernel strength to operate in {{tsl|en|Multi-Level Security}} mode{{Citation needed|date=November 2009}}. Access to the labels and control mechanisms are not{{Citation needed|date=November 2009}} robustly protected from corruption in protected domain maintained by a kernel. The applications a user runs are combined with the security label at which the user works in the session. Access to information, programs and devices are only weakly controlled{{Citation needed|date=November 2009}}.
* Apple's Mac OS X MAC framework is an implementation of the [[FreeBSD]] MAC framework.<ref name="TrustedBSD">{{cite web | url = http://www.trustedbsd.org/mac.html | title = TrustedBSD Mandatory Access Control (MAC) Framework | author = TrustedBSD Project | accessdate = 2008-03-15}}</ref> A limited high-level sandboxing interface is provided by the command-line function sandbox_init. See the sandbox_init manual page for documentation.<ref name="Ref_2007">{{cite web | url = http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man3/sandbox_init.3.html | accessdate = 2008-03-15 | date = 2007-07-07 | title = sandbox_init(3) man page}}</ref>
* Apple's Mac OS X MAC framework is an implementation of the [[FreeBSD]] MAC framework.<ref name="TrustedBSD">{{cite web | url = http://www.trustedbsd.org/mac.html | title = TrustedBSD Mandatory Access Control (MAC) Framework | author = TrustedBSD Project | accessdate = 2008-03-15 | archive-date = 2010-01-23 | archive-url = https://web.archive.org/web/20100123225944/http://www.trustedbsd.org/mac.html | dead-url = yes }}</ref> A limited high-level sandboxing interface is provided by the command-line function sandbox_init. See the sandbox_init manual page for documentation.<ref name="Ref_2007">{{cite web | url = http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man3/sandbox_init.3.html | accessdate = 2008-03-15 | date = 2007-07-07 | title = sandbox_init(3) man page | archive-date = 2008-07-25 | archive-url = https://web.archive.org/web/20080725072208/http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/sandbox_init.3.html | dead-url = no }}</ref>
* {{tsl|en|Oracle Label Security}} is an implementation of mandatory access control in the [[Oracle数据库]].
* {{tsl|en|Oracle Label Security}} is an implementation of mandatory access control in the [[Oracle数据库]].
* {{tsl|en|SE-PostgreSQL}} is a work in progress as of 2008-01-27,<ref name = "SE Postgres wiki">{{cite web | url = http://wiki.postgresql.org/wiki/SEPostgreSQL-patch | title = SEPostgreSQL-patch}}</ref><ref name = "SE Postgres">{{cite web | url = http://code.google.com/p/sepgsql/ | title = Security Enhanced PostgreSQL}}</ref> providing integration into SE-Linux. It aims for integration into version 8.4, together with row-level restrictions.
* {{tsl|en|SE-PostgreSQL}} is a work in progress as of 2008-01-27,<ref name = "SE Postgres wiki">{{cite web | url = http://wiki.postgresql.org/wiki/SEPostgreSQL-patch | title = SEPostgreSQL-patch | accessdate = 2017-02-12 | archive-date = 2017-02-13 | archive-url = https://web.archive.org/web/20170213164209/http://wiki.postgresql.org/wiki/SEPostgreSQL-patch | dead-url = yes }}</ref><ref name = "SE Postgres">{{cite web | url = http://code.google.com/p/sepgsql/ | title = Security Enhanced PostgreSQL | accessdate = 2017-02-12 | archive-date = 2009-02-07 | archive-url = https://web.archive.org/web/20090207194223/http://code.google.com/p/sepgsql/ | dead-url = no }}</ref> providing integration into SE-Linux. It aims for integration into version 8.4, together with row-level restrictions.
* {{tsl|en|Trusted RUBIX}} is a mandatory access control enforcing DBMS that fully integrates with SE-Linux to restrict access to all database objects.<ref name = "Trusted RUBIX">{{cite web | url = http://www.rubix.com | title = Trusted RUBIX}}</ref>
* {{tsl|en|Trusted RUBIX}} is a mandatory access control enforcing DBMS that fully integrates with SE-Linux to restrict access to all database objects.<ref name="Trusted RUBIX">{{cite web | url = http://www.rubix.com | title = Trusted RUBIX | deadurl = yes | archiveurl = https://web.archive.org/web/20081121215622/http://www.rubix.com/ | archivedate = 2008年11月21日 | df = }}</ref>
* {{tsl|en|Astra Linux}} OS developed for [[俄罗斯陆军]] has its own mandatory access control.<ref>{{ru icon}} [http://astra-linux.com/klyuchevye-osobennosti.html Ключевые особенности Astra Linux Special Edition по реализации требований безопасности информации]</ref>
* [[Astra Linux]] OS developed for [[俄罗斯陆军]] has its own mandatory access control.<ref>{{ru icon}} [http://astra-linux.com/klyuchevye-osobennosti.html Ключевые особенности Astra Linux Special Edition по реализации требований безопасности информации] {{Wayback|url=http://astra-linux.com/klyuchevye-osobennosti.html |date=20140716115137 }}</ref>
* {{tsl|en|Smack (software)|Smack}} (''Simplified Mandatory Access Control Kernel'') is a [[Linux内核]] [[Linux安全模組|security module]] that protects data and process interaction from malicious manipulation using a set of custom mandatory access control rules, with simplicity as its main design goal.<ref name="Major">{{cite web| url=http://schaufler-ca.com/description_from_the_linux_source_tree| title=Official SMACK documentation from the Linux source tree| archiveurl = http://www.webcitation.org/6AqzohCXq| archivedate = 2012-09-13}}</ref> It has been officially merged since the Linux 2.6.25 release.<ref name="Merge">{{cite web| url=https://lwn.net/Articles/267849/| title=More stuff for 2.6.25| author=Jonathan Corbet| archiveurl = http://www.webcitation.org/6AqxbHgv3| archivedate = 2012-09-12}}</ref>
* {{tsl|en|Smack (software)|Smack}} (''Simplified Mandatory Access Control Kernel'') is a [[Linux内核]] [[Linux安全模組|security module]] that protects data and process interaction from malicious manipulation using a set of custom mandatory access control rules, with simplicity as its main design goal.<ref name="Major">{{cite web |url=http://schaufler-ca.com/description_from_the_linux_source_tree |title=Official SMACK documentation from the Linux source tree |archiveurl=https://www.webcitation.org/6AqzohCXq?url=http://schaufler-ca.com/description_from_the_linux_source_tree |archivedate=2012-09-21 |deadurl=yes }}</ref> It has been officially merged since the Linux 2.6.25 release.<ref name="Merge">{{cite web |url=https://lwn.net/Articles/267849/ |title=More stuff for 2.6.25 |author=Jonathan Corbet |archiveurl=https://www.webcitation.org/6AqxbHgv3?url=http://lwn.net/Articles/267849/ |archivedate=2012-09-21 |deadurl=yes }}</ref>
{{TransF}}
{{TransF}}


第74行: 第75行:


== 参考资料 ==
== 参考资料 ==
* P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. ''[http://www.jya.com/paperF1.htm The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments]''. In Proceedings of the 21st National Information Systems Security Conference, pages 303–314, Oct. 1998.
* P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. ''[https://web.archive.org/web/20070621155813/http://jya.com/paperF1.htm The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments]''. In Proceedings of the 21st National Information Systems Security Conference, pages 303–314, Oct. 1998.
* P. A. Loscocco, S. D. Smalley, ''[http://www.nsa.gov/selinux/papers/ottawa01-abs.cfm Meeting Critical Security Objectives with Security-Enhanced Linux]'' Proceedings of the 2001 Ottawa Linux Symposium.
* P. A. Loscocco, S. D. Smalley, ''[http://www.nsa.gov/selinux/papers/ottawa01-abs.cfm Meeting Critical Security Objectives with Security-Enhanced Linux] {{Wayback|url=http://www.nsa.gov/selinux/papers/ottawa01-abs.cfm |date=20170708094222 }}'' Proceedings of the 2001 Ottawa Linux Symposium.
* ISO/IEC DIS 10181-3, Information Technology, OSI Security Model, Security FrameWorks, Part 3: Access Control, 1993
* ISO/IEC DIS 10181-3, Information Technology, OSI Security Model, Security FrameWorks, Part 3: Access Control, 1993
* Robert N. M. Watson. "[http://dl.acm.org/citation.cfm?id=2428616.2430732 A decade of OS access-control extensibility]". Commun. ACM 56, 2 (February 2013), 52-63.
* Robert N. M. Watson. "[http://dl.acm.org/citation.cfm?id=2428616.2430732 A decade of OS access-control extensibility] {{Wayback|url=http://dl.acm.org/citation.cfm?id=2428616.2430732 |date=20170630021604 }}". Commun. ACM 56, 2 (February 2013), 52-63.


== 外部链接 ==
== 外部链接 ==
* [http://rentzsch.com/notes/virtualizationAsAnAntivirus 网络博客]{{en}}:有关如何使用[[虚拟化]]实现强制访问控制。
* [https://web.archive.org/web/20060504192215/http://rentzsch.com/notes/virtualizationAsAnAntivirus 网络博客]{{en}}:有关如何使用[[虚拟化]]实现强制访问控制。
* [http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx 网络博客]{{en}}:[[微软]]员工详细描述强制完整性控制以及它如何与其他MAC实现的差异。
* [https://web.archive.org/web/20070929084227/http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx 网络博客]{{en}}:[[微软]]员工详细描述强制完整性控制以及它如何与其他MAC实现的差异。
* [http://hokiepokie.org/docs/acl22003/security-policy.pdf GWV Formal Security Policy Model] A Separation Kernel Formal Security Policy, David Greve, Matthew Wilding, and W. Mark Vanfleet.
* [http://hokiepokie.org/docs/acl22003/security-policy.pdf GWV Formal Security Policy Model] {{Wayback|url=http://hokiepokie.org/docs/acl22003/security-policy.pdf |date=20170706030307 }} A Separation Kernel Formal Security Policy, David Greve, Matthew Wilding, and W. Mark Vanfleet.


[[Category:存取控制]]
[[Category:存取控制]]

2022年3月12日 (六) 17:48的最新版本

强制访问控制(英語:mandatory access control,缩写MAC)在计算机安全领域指一种由操作系统约束的存取控制,目标是限制主体或发起者访问或对对象或目标执行某种操作的能力。在实践中,主体通常是一个进程线程,对象可能是文件目录TCP/UDP端口、共享内存段、I/O设备等。主体和对象各自具有一组安全属性。每当主体尝试访问对象时,都会由操作系统内核强制施行授权规则——检查安全属性并决定是否可进行访问。任何主體对任何物件的任何操作都将根据一组授权规则(也称策略)进行测试,决定操作是否允许。在数据库管理系统中也存在访问控制机制,因而也可以应用强制访问控制;在此环境下,对象为表、视图、过程等。

通过强制访问控制,安全策略由安全策略管理员集中控制;用户无权覆盖策略,例如不能给被否决而受到限制的文件授予访问权限。相比而言,自主访问控制(DAC)也控制主体访问对象的能力,但允许用户进行策略决策和/或分配安全属性。(传统Unix系统的用户、组和读-写-执行就是一种DAC。)启用MAC的系统允许策略管理员实现组织范围的安全策略。在MAC(不同于DAC)下,用户不能覆盖或修改策略,无论为意外或故意。这使安全管理员定义的中央策略得以在原则上保证向所有用户强制实施。

在历史上和传统上,MAC与多层安全英语Multi-level security(MLS)和专业的军用系统密切相关。在此环境中,MAC意味着高度严格以满足MLS系统的约束。但在最近,MAC已从MLS本身中发展出来,并变得更加主流。最近的MAC实现有诸如面向Linux的SELinuxAppArmor,以及面向Windows的强制完整性控制,它们使管理员得以关注没有严格或MLS约束时遇到的如网络攻击或恶意软件等问题。

历史背景和对多层安全的影响

[编辑]

历史上,MAC与作为保护美国機密信息的多层安全英语Multi-Level Security(MLS)手段密切相关。可信计算机系统评估标准英语Trusted Computer System Evaluation Criteria(TCSEC)就是就这一主题的开创性工作,其中将MAC定义为“基于对象中包含信息的敏感性(由标签表示)来显示对对象的访问途径以及对象访问这种敏感信息的授权”。MAC的早期实现有Honeywell的SCOMP、USAF SACDIN、NSA Blacker,以及的波音MLS LAN。

术语MAC中的“强制性”已经因其在军事系统中的使用而获得了特殊含义。在这方面,MAC意味着非常高的抵抗性,确保控制机制能够抵抗任何类型的破坏,从而使他们能够执行由政府命令授权的访问控制,诸如面向美国等级信息的第12958號行政命令 。强制施行的保证性要求要高于商业应用,因此这不允许采用“尽力而为”的机制。MAC只接受能够绝对或者几乎绝对地保证任务执行的机制。这点对于不熟悉高保证策略的人来说可能很困难或者被假定为不切实际。

系统强度

[编辑]

强度等级

[编辑]

在某些系统中,用户有权决定是否向其他任何用户授予访问权限。为允许这点,所有用户都必须有所有数据的审查许可。这不是MLS系统所需必要条件。如果个人或进程可能被拒绝访问系统环境中的任何数据,则系统必须可信以强制执行MAC。由于可能存在各种级别的数据等级和用户许可,这也显示了健壮性的量化指标。例如,一个包含等级为最高机密的信息和等级为未批准的用户的系统相较于一个包含等级为绝密的信息和等级为秘密的用户的系统具有更高的健壮性。为了维持健壮性量化指标的一致性以及尽可能地消除主观人为因素,一项针对该问题的大规模科学分析和风险评估提出了标志性的测试标准,用以量化系统的安全健壮性,并根据其能够保证的安全等级为其分级。该结果记录于CSC-STD-004-85。[1]健壮性的两个相对独立的组成部分可以被定义为保障等级和功能性,两者都可以被阐述为一个系统在特定标准下能够保证的其审查的精确性。

强度评估

[编辑]
已隱藏部分未翻譯内容,歡迎參與翻譯

The Common Criteria[2] is based on this science and it intended to preserve the Assurance Level as EAL levels英语Evaluation Assurance Level and the functionality specifications as Protection Profile英语Protection Profiles. Of these two essential components of objective robustness benchmarks, only EAL levels were faithfully preserved. In one case, TCSEC英语TCSEC level C2[3] (not a MAC capable category) was fairly faithfully preserved in the Common Criteria, as the Controlled Access Protection Profile英语Controlled Access Protection Profile (CAPP).[4] Multilevel security英语Multilevel security (MLS) Protection Profiles (such as MLSOSPP similar to B2)[5] is more general than B2. They are pursuant to MLS, but lack the detailed implementation requirements of their Orange Book英语Trusted Computer System Evaluation Criteria predecessors, focusing more on objectives. This gives certifiers more subjective flexibility in deciding whether the evaluated product’s technical features adequately achieve the objective, potentially eroding consistency of evaluated products and making it easier to attain certification for less trustworthy products. For these reasons, the importance of the technical details of the Protection Profile is critical to determining the suitability of a product.

Such an architecture prevents an authenticated user or process at a specific classification or trust-level from accessing information, processes, or devices in a different level. This provides a containment mechanism of users and processes, both known and unknown (an unknown program (for example) might comprise an untrusted application where the system should monitor and/or control accesses to devices and files).

实现

[编辑]
已隱藏部分未翻譯内容,歡迎參與翻譯

A few MAC implementations, such as 優利系統' Blacker英语Blacker (security) project, were certified robust enough to separate Top Secret from Unclassified late in the last millennium. Their underlying technology became obsolete and they were not refreshed. Today there are no current implementations certified by TCSEC英语TCSEC to that level of robust implementation. However, some less robust products exist.

  • Amon Ott's RSBAC (Rule Set Based Access Control) provides a framework for Linux kernels that allows several different security policy / decision modules. One of the models implemented is Mandatory Access Control model. A general goal of RSBAC design was to try to reach (obsolete) Orange Book (TCSEC) B1 level. The model of mandatory access control used in RSBAC is mostly the same as in Unix System V/MLS, Version 1.2.1 (developed in 1989 by the National Computer Security Center of the USA with classification B1/TCSEC). RSBAC requires a set of patches to the stock kernel, which are maintained quite well by the project owner.
  • An 美国国家安全局 research project called SELinux added a Mandatory Access Control architecture to the Linux内核, which was merged into the mainline version of Linux in August 2003. It utilizes a Linux 2.6 kernel feature called LSM (Linux Security Modules interface). Red Hat Enterprise Linux version 4 (and later versions) come with an SELinux-enabled kernel. Although SELinux is capable of restricting all processes in the system, the default targeted policy in RHEL confines the most vulnerable programs from the unconfined domain in which all other programs run. RHEL 5 ships 2 other binary policy types: strict, which attempts to implement 最小权限原则, and MLS, which is based on strict and adds MLS labels. RHEL 5 contains additional MLS enhancements and received 2 LSPP英语Labeled Security Protection Profile/RBACPP/CAPP/EAL4+ certifications in June 2007.[6]
  • TOMOYO Linux英语TOMOYO Linux is a lightweight MAC implementation for Linux and 嵌入式Linux, developed by NTT Data Corporation英语NTT Data Corporation. It has been merged in Linux Kernel mainline version 2.6.30 in June 2009.[7] Differently from the label-based approach used by 安全增强式Linux, TOMOYO Linux performs a pathname-based Mandatory Access Control, separating security domains according to process invocation history, which describes the system behavior. Policy are described in terms of pathnames. A security domain is simply defined by a process call chain, and represented as a string. There are 4 modes: disabled, learning, permissive, enforcing. Administrators can assign different modes for different domains. TOMOYO Linux introduced the "learning" mode, in which the accesses occurred in the kernel are automatically analyzed and stored to generate MAC policy: this mode can be used as first step of policy writing, making it easy to customize later.
  • SUSE (now supported by Novell) and Ubuntu 7.10 have added a MAC implementation called AppArmor. AppArmor utilizes a Linux 2.6 kernel feature called LSM (Linux Security Modules interface). LSM provides a kernel API that allows modules of kernel code to govern ACL (DAC ACL, access control lists). AppArmor is not capable of restricting all programs and is optionally in the Linux kernel as of version 2.6.36.[8]
  • Linux and many other Unix distributions have MAC for CPU (multi-ring), disk, and memory; while OS software may not manage privileges well, Linux became famous during the 1990s as being more secure and far more stable than non-Unix alternatives. Linux distributors disable MAC to being at best DAC for some devices - although this is true for any consumer electronics available today.
  • grsecurity英语grsecurity is a patch for the Linux kernel providing a MAC implementation (precisely, it is a RBAC implementation). Hardened Gentoo英语Hardened Gentoo offers a pre-patched kernel with grsecurity. grsecurity is not implemented via the LSM API.[9]
  • 微软 Starting with Windows Vista and Server 2008 Windows incorporates 强制完整性控制, which adds Integrity Levels (IL) to processes running in a login session. MIC restricts the access permissions of applications that are running under the same user account and which may be less trustworthy. Five integrity levels are defined: Low, Medium, High, System, and Trusted Installer.[10] Processes started by a regular user gain a Medium IL; elevated processes have High IL.[11] While processes inherit the integrity level of the process that spawned it, the integrity level can be customized on a per-process basis: e.g. IE7 and downloaded executables run with Low IL. Windows controls access to objects based on ILs, as well as for defining the boundary for window messages via 用户界面特权隔离. Named objects, including files, registry keys or other processes and threads, have an entry in the ACL governing access to them that defines the minimum IL of the process that can use the object. MIC enforces that a process can write to or delete an object only when its IL is equal to or higher than the object’s IL. Furthermore, to prevent access to sensitive data in memory, processes can’t open processes with a higher IL for read access.[12]
  • FreeBSD supports Mandatory Access Control, implemented as part of the TrustedBSD project. It was introduced in FreeBSD 5.0. Since FreeBSD 7.2, MAC support is enabled by default. The framework is extensible; various MAC modules implement policies such as Biba英语Biba Integrity Model and Multi-Level Security英语Multi-Level Security.
  • Sun's Trusted Solaris英语Trusted Solaris uses a mandatory and system-enforced access control mechanism (MAC), where clearances and labels are used to enforce a security policy. However note that the capability to manage labels does not imply the kernel strength to operate in Multi-Level Security英语Multi-Level Security mode[來源請求]. Access to the labels and control mechanisms are not[來源請求] robustly protected from corruption in protected domain maintained by a kernel. The applications a user runs are combined with the security label at which the user works in the session. Access to information, programs and devices are only weakly controlled[來源請求].
  • Apple's Mac OS X MAC framework is an implementation of the FreeBSD MAC framework.[13] A limited high-level sandboxing interface is provided by the command-line function sandbox_init. See the sandbox_init manual page for documentation.[14]
  • Oracle Label Security英语Oracle Label Security is an implementation of mandatory access control in the Oracle数据库.
  • SE-PostgreSQL英语SE-PostgreSQL is a work in progress as of 2008-01-27,[15][16] providing integration into SE-Linux. It aims for integration into version 8.4, together with row-level restrictions.
  • Trusted RUBIX英语Trusted RUBIX is a mandatory access control enforcing DBMS that fully integrates with SE-Linux to restrict access to all database objects.[17]
  • Astra Linux OS developed for 俄罗斯陆军 has its own mandatory access control.[18]
  • Smack英语Smack (software) (Simplified Mandatory Access Control Kernel) is a Linux内核 security module that protects data and process interaction from malicious manipulation using a set of custom mandatory access control rules, with simplicity as its main design goal.[19] It has been officially merged since the Linux 2.6.25 release.[20]

参见

[编辑]

脚注

[编辑]
  1. ^ Technical Rational Behind CSC-STD-003-85: Computer Security Requirements. 1985-06-25 [2008-03-15]. (原始内容存档于July 15, 2007). 
  2. ^ The Common Criteria Portal. [2008-03-15]. (原始内容存档于2006-07-18). 
  3. ^ US Department of Defense. DoD 5200.28-STD: Trusted Computer System Evaluation Criteria. December 1985 [2008-03-15]. (原始内容存档于2008-03-17). 
  4. ^ Controlled Access Protection Profile, Version 1.d. National Security Agency. 1999-10-08 [2008-03-15]. (原始内容存档于2012-02-07). 
  5. ^ Protection Profile for Multi-Level Operating Systems in Environments Requiring Medium Robustness, Version 1.22. National Security Agency. 2001-05-23 [2008-03-15]. (原始内容存档于2009-03-30). 
  6. ^ National Information Assurance Partnership. The Common Criteria Evaluation and Validation Scheme Validated Products List. [2008-03-15]. (原始内容存档于2008-03-14). 
  7. ^ TOMOYO Linux, an alternative Mandatory Access Control. Linux 2 6 30. Linux Kernel Newbies. [2017-02-12]. (原始内容存档于2012-04-05). 
  8. ^ Linux 2.6.36 released 20 October 2010. Linux 2.6.36. Linux Kernel Newbies. [2017-02-12]. (原始内容存档于2018-06-10). 
  9. ^ Why doesn't grsecurity use LSM?. [2017-02-12]. (原始内容存档于2016-07-22). 
  10. ^ Matthew Conover. Analysis of the Windows Vista Security Model. 赛门铁克. [2007-10-08]. (原始内容存档于2008-03-25). 
  11. ^ Steve Riley. Mandatory Integrity Control in Windows Vista. [2007-10-08]. (原始内容存档于2007-09-29). 
  12. ^ Mark Russinovich英语Mark Russinovich. PsExec, User Account Control and Security Boundaries. [2007-10-08]. (原始内容存档于2010-04-15). 
  13. ^ TrustedBSD Project. TrustedBSD Mandatory Access Control (MAC) Framework. [2008-03-15]. (原始内容存档于2010-01-23). 
  14. ^ sandbox_init(3) man page. 2007-07-07 [2008-03-15]. (原始内容存档于2008-07-25). 
  15. ^ SEPostgreSQL-patch. [2017-02-12]. (原始内容存档于2017-02-13). 
  16. ^ Security Enhanced PostgreSQL. [2017-02-12]. (原始内容存档于2009-02-07). 
  17. ^ Trusted RUBIX. (原始内容存档于2008年11月21日). 
  18. ^ (俄文) Ключевые особенности Astra Linux Special Edition по реализации требований безопасности информации页面存档备份,存于互联网档案馆
  19. ^ Official SMACK documentation from the Linux source tree. (原始内容存档于2012-09-21). 
  20. ^ Jonathan Corbet. More stuff for 2.6.25. (原始内容存档于2012-09-21). 

参考资料

[编辑]

外部链接

[编辑]