AppArmor
2021-11-09 10:47:33 
阿炯
AppArmor (“Application Armor”，意为“应用盔甲”)是一个Linux内核安全模块，允许系统管理员通过每个程序的配置文件限制程序的功能。如它的帮助页面所说，“AppArmor 是一个对内核的增强工具，将程序限制在一个有限的资源集合中，它独特的安全模型将对访问属性的控制绑定到程序而非用户。”
AppArmor 通过提供强制访问控制(MAC)来补充传统的Unix自主访问控制(DAC)模型。从Linux内核的2.6.36版本开始，它已经被包含在主流分支中，并且自2009年它的开发得到了 Canonical 公司的支持，采用C, Perl, C++, sh语言开发并在GPLv2下授权。
功能特性
AppArmor 对相关程序的约束与控制通过 apparmor_parser 加载到内核的配置文件来提供，这一般通过 /etc/init.d/apparmor 中的 SysV initscript来控制。可以以两种模式运行：执行(enforcement)模式或学习(complain/learning)模式：
1、执行模式 - 加载的配置文件中定义的策略将会被执行，并且会向 syslogd 报告违规尝试。
2、学习 - 以“学习”模式加载的配置文件不会执行策略。它仅仅会报告违反策略的尝试。这种模式对于开发配置文件很方便。利用这种模式可以根据各个程序针对性地生成配置文件。
AppArmor 是使用Linux安全模块(LSM)内核接口实现的。在2009年，Linux 2.6.30 中包含了一个名为 Tomoyo 的新解决方案；像 AppArmor 一样，它也使用基于路径的访问控制。
与SELinux相比
AppArmor 是作为 SELinux 的替代品出现的，因为对 SELinux 的批评者认为它难以让管理员设置和维护。与基于将标签应用于文件的 SELinux 不同，AppArmor 使用文件路径来确认文件。AppArmor 的支持者声称，它对普通用户而言要比 SELinux 更简单、更易学习。他们还认为 AppArmor 对现有系统的要求更低：例如 SELinux 需要支持“安全标签”的文件系统，因此无法为通过 NFS 挂载的文件提供访问控制。AppArmor 则对文件系统没有要求。
但不论如何，这两个软件产品对让管理员加强系统的安全性都非常有帮助。他们都专注于访问控制，强化了标准的Linux访问控制策略。他们都生成日志，并提供审计活动的工具。他们都在应用程序层内工作。从技术上讲，他们同样地使用LSM与Linux内核进行交互。它们允许管理员使用GUI与非GUI工具。最后，它们都允许管理员在没有真正阻止访问的情况下尝试策略(而只是警告)，以便仅在足够数量的测试之后才应用安全加固策略。
SELinux 和 AppArmor 的不同主要体现在管理方式和集成方式上。例如一个重要的区别：SELinux 通过 inode 编号而不是路径标识文件系统对象。这意味着如果给一个无法访问的文件创建了硬链接，在 AppArmor 中它将可以访问，但 SELinux 通过新创建的硬链接仍然会拒绝访问——由 inode 引用的基础数据是一样的。另外在文档数量上 AppArmor 要比 SELinux 略逊一筹，这意味着网上寻找解决方案的难易程度同样有所差异。
SELinux与Apparmor最大的区别在于：Apparmor使用文件名(路径名)最为安全标签，而SELinux使用文件的inode作为安全标签，这就意味着，Apparmor机制可以通过修改文件名而被绕过，另外在文件系统中，只有inode才具有唯一性。SELinux 拥有三个基本的操作模式，Enforcing 是其缺省的模式。此外，它还有一个 targeted 或 mls 的修饰语。这让 SELinux 规则的应用有多广泛，当中 targeted 是较宽松的级别。
Enforcing：这个缺省模式会在系统上启用并实施 SELinux 的安全性政策，拒绝访问及记录行动
Permissive：在 Permissive 模式下，SELinux 会被启用但不会实施安全性政策，而只会发出警告及记录行动。Permissive 模式在排除 SELinux 的问题时很有用
Disabled：SELinux 已被停用
从上面不难看出，两者在强制模式上作用一样，而SELinux的宽松模式(Permissive)对应着apparmor的complain模式。从一些测试结果来看，也比较推荐使用selinux而不是apparmor 。在docker/lxc的相关文档中，也会找到apparmor相关的部分，如 online judge 这些应用也和apparmor/SElinux扯上关系。提到上面这些就不得不提下沙盒(sandbox)，沙盒不仅在安全上有用，还可以在很多场合取代基于虚拟机的应用隔离方案(沙盒化的进程是效率最高的虚拟机)，而linux上的沙盒应用基本上都是基于apparmor/SElinux的。
访问控制与资源限制
1)文件系统的访问控制
Apparmor可以对某一个文件，或者某一个目录下的文件进行访问控制，包括以下几种访问模式：
r Read mode
w Write mode (mutually exclusive to a)
a Append mode (mutually exclusive to w)
k File locking mode
l Link mode
linkfile->target Link pair rule (cannot be combined with other access modes)
可读、可写、可扩展、可链接等(还有可执行x在表中没有列出)……
在配置文件中的写法，如：/tmp r, (表示可对/tmp目录下的文件进行读取)
注意一点，没在配置文件中列出的文件，程序是不能访问的，类似白名单。
2)资源限制
Apparmor可以提供类似系统调用setrlimit一样的方式来限制程序可以使用的资源。要限制资源，可在配置文件中这样写：
set rlimit [resource] <= [value],
其resource代表某一种资源，value代表某一个值，要对程序可以使用的虚拟内存做限制时，可以这样写：
set rlimit as<=1M, (可以使用的虚拟内存最大为1M)
注意：Apparmor可以对程序要使用多种资源进行限制(fsize,data,stack,core,rss,as,memlock,msgqueue等)，但暂不支持对程序可以使用CPU时间进行限制。(现在OJ一般都对ACMer提交的程序的运行时间有严格的限制，所以要将Apparmor用于OJ后台安全模块，必须自己另外实现对CPU时间的限制)
3)访问网络
Apparmor可以程序是否可以访问网络进行限制，在配置文件里的语法是：
network [ [domain] [type] [protocol] ]
了解网络编程的应该知道domain、type和protocol是什么。要让程序可以进行所有的网络操作，只需在配置文件中写：
network,
要允许程序使用在IPv4下使用TCP协议，可以这样写：
network inet tcp,
4)capability条目
在linux的手册页里面有一个capablities列表，apparmor可以限制程序是否可以进行列表里的操作，如：capability setgid,(允许程序进行setgid操作)
Capability statements are simply the word capability followed by the name of the POSIX. 1e capability as defined in the capabilities(7) man page.
时间线
AppArmor 在1998~2003年首先在 Immunix Linux中被使用。当时AppArmor被称为SubDomain，这个名字意在将特定程序的安全配置文件分割成不同的域，而程序可以动态地在不同的域中进行切换。 AppArmor 首先在 SLES 和 openSUSE 中可用，并且在 SLES 10 和 openSUSE 10.1 中默认首先启用。
2005年5月，Novell 收购了 Immunix 并将 SubDomain 重命名为 AppArmor，并开始对其 Linux 内核进行代码清理和重写。从2005年到2007年9月，AppArmor 由 Novell 维护。从那时起，SUSE 就是商标名 AppArmor 的合法所有者。
AppArmor 在2007年4月第一次成功移植并打包于 Ubuntu。它成为Ubuntu 7.10版本的默认软件包，并最终作为Ubuntu 8.04发行版的一部分，默认设置只保护 CUPS。从 Ubuntu 9.04 开始，更多的项目(如MySQL)已经安装了配置文件。在 Ubuntu 9.10 中，AppArmor 的功能不断得到改进，因为它提供了客户会话、libvirt 虚拟机、Evince文档查看器的配置文件。它还提供了一个可选的 Firefox 的配置文件。
AppArmor 第一次被集成到 Linux 内核中是在2010年10月的2.6.36版本。
2014年，AppArmor 已经集成到了 Synology 的 DSM 5.1 Beta中
最新版本：3.0
项目主页：https://gitlab.com/apparmor
AppArmor 通过提供强制访问控制(MAC)来补充传统的Unix自主访问控制(DAC)模型。从Linux内核的2.6.36版本开始，它已经被包含在主流分支中，并且自2009年它的开发得到了 Canonical 公司的支持，采用C, Perl, C++, sh语言开发并在GPLv2下授权。
功能特性
AppArmor 对相关程序的约束与控制通过 apparmor_parser 加载到内核的配置文件来提供，这一般通过 /etc/init.d/apparmor 中的 SysV initscript来控制。可以以两种模式运行：执行(enforcement)模式或学习(complain/learning)模式：
1、执行模式 - 加载的配置文件中定义的策略将会被执行，并且会向 syslogd 报告违规尝试。
2、学习 - 以“学习”模式加载的配置文件不会执行策略。它仅仅会报告违反策略的尝试。这种模式对于开发配置文件很方便。利用这种模式可以根据各个程序针对性地生成配置文件。
AppArmor 是使用Linux安全模块(LSM)内核接口实现的。在2009年，Linux 2.6.30 中包含了一个名为 Tomoyo 的新解决方案；像 AppArmor 一样，它也使用基于路径的访问控制。
与SELinux相比
AppArmor 是作为 SELinux 的替代品出现的，因为对 SELinux 的批评者认为它难以让管理员设置和维护。与基于将标签应用于文件的 SELinux 不同，AppArmor 使用文件路径来确认文件。AppArmor 的支持者声称，它对普通用户而言要比 SELinux 更简单、更易学习。他们还认为 AppArmor 对现有系统的要求更低：例如 SELinux 需要支持“安全标签”的文件系统，因此无法为通过 NFS 挂载的文件提供访问控制。AppArmor 则对文件系统没有要求。
但不论如何，这两个软件产品对让管理员加强系统的安全性都非常有帮助。他们都专注于访问控制，强化了标准的Linux访问控制策略。他们都生成日志，并提供审计活动的工具。他们都在应用程序层内工作。从技术上讲，他们同样地使用LSM与Linux内核进行交互。它们允许管理员使用GUI与非GUI工具。最后，它们都允许管理员在没有真正阻止访问的情况下尝试策略(而只是警告)，以便仅在足够数量的测试之后才应用安全加固策略。
SELinux 和 AppArmor 的不同主要体现在管理方式和集成方式上。例如一个重要的区别：SELinux 通过 inode 编号而不是路径标识文件系统对象。这意味着如果给一个无法访问的文件创建了硬链接，在 AppArmor 中它将可以访问，但 SELinux 通过新创建的硬链接仍然会拒绝访问——由 inode 引用的基础数据是一样的。另外在文档数量上 AppArmor 要比 SELinux 略逊一筹，这意味着网上寻找解决方案的难易程度同样有所差异。
SELinux与Apparmor最大的区别在于：Apparmor使用文件名(路径名)最为安全标签，而SELinux使用文件的inode作为安全标签，这就意味着，Apparmor机制可以通过修改文件名而被绕过，另外在文件系统中，只有inode才具有唯一性。SELinux 拥有三个基本的操作模式，Enforcing 是其缺省的模式。此外，它还有一个 targeted 或 mls 的修饰语。这让 SELinux 规则的应用有多广泛，当中 targeted 是较宽松的级别。
Enforcing：这个缺省模式会在系统上启用并实施 SELinux 的安全性政策，拒绝访问及记录行动
Permissive：在 Permissive 模式下，SELinux 会被启用但不会实施安全性政策，而只会发出警告及记录行动。Permissive 模式在排除 SELinux 的问题时很有用
Disabled：SELinux 已被停用
从上面不难看出，两者在强制模式上作用一样，而SELinux的宽松模式(Permissive)对应着apparmor的complain模式。从一些测试结果来看，也比较推荐使用selinux而不是apparmor 。在docker/lxc的相关文档中，也会找到apparmor相关的部分，如 online judge 这些应用也和apparmor/SElinux扯上关系。提到上面这些就不得不提下沙盒(sandbox)，沙盒不仅在安全上有用，还可以在很多场合取代基于虚拟机的应用隔离方案(沙盒化的进程是效率最高的虚拟机)，而linux上的沙盒应用基本上都是基于apparmor/SElinux的。
访问控制与资源限制
1)文件系统的访问控制
Apparmor可以对某一个文件，或者某一个目录下的文件进行访问控制，包括以下几种访问模式：
r Read mode
w Write mode (mutually exclusive to a)
a Append mode (mutually exclusive to w)
k File locking mode
l Link mode
linkfile->target Link pair rule (cannot be combined with other access modes)
可读、可写、可扩展、可链接等(还有可执行x在表中没有列出)……
在配置文件中的写法，如：/tmp r, (表示可对/tmp目录下的文件进行读取)
注意一点，没在配置文件中列出的文件，程序是不能访问的，类似白名单。
2)资源限制
Apparmor可以提供类似系统调用setrlimit一样的方式来限制程序可以使用的资源。要限制资源，可在配置文件中这样写：
set rlimit [resource] <= [value],
其resource代表某一种资源，value代表某一个值，要对程序可以使用的虚拟内存做限制时，可以这样写：
set rlimit as<=1M, (可以使用的虚拟内存最大为1M)
注意：Apparmor可以对程序要使用多种资源进行限制(fsize,data,stack,core,rss,as,memlock,msgqueue等)，但暂不支持对程序可以使用CPU时间进行限制。(现在OJ一般都对ACMer提交的程序的运行时间有严格的限制，所以要将Apparmor用于OJ后台安全模块，必须自己另外实现对CPU时间的限制)
3)访问网络
Apparmor可以程序是否可以访问网络进行限制，在配置文件里的语法是：
network [ [domain] [type] [protocol] ]
了解网络编程的应该知道domain、type和protocol是什么。要让程序可以进行所有的网络操作，只需在配置文件中写：
network,
要允许程序使用在IPv4下使用TCP协议，可以这样写：
network inet tcp,
4)capability条目
在linux的手册页里面有一个capablities列表，apparmor可以限制程序是否可以进行列表里的操作，如：capability setgid,(允许程序进行setgid操作)
Capability statements are simply the word capability followed by the name of the POSIX. 1e capability as defined in the capabilities(7) man page.
时间线
AppArmor 在1998~2003年首先在 Immunix Linux中被使用。当时AppArmor被称为SubDomain，这个名字意在将特定程序的安全配置文件分割成不同的域，而程序可以动态地在不同的域中进行切换。 AppArmor 首先在 SLES 和 openSUSE 中可用，并且在 SLES 10 和 openSUSE 10.1 中默认首先启用。
2005年5月，Novell 收购了 Immunix 并将 SubDomain 重命名为 AppArmor，并开始对其 Linux 内核进行代码清理和重写。从2005年到2007年9月，AppArmor 由 Novell 维护。从那时起，SUSE 就是商标名 AppArmor 的合法所有者。
AppArmor 在2007年4月第一次成功移植并打包于 Ubuntu。它成为Ubuntu 7.10版本的默认软件包，并最终作为Ubuntu 8.04发行版的一部分，默认设置只保护 CUPS。从 Ubuntu 9.04 开始，更多的项目(如MySQL)已经安装了配置文件。在 Ubuntu 9.10 中，AppArmor 的功能不断得到改进，因为它提供了客户会话、libvirt 虚拟机、Evince文档查看器的配置文件。它还提供了一个可选的 Firefox 的配置文件。
AppArmor 第一次被集成到 Linux 内核中是在2010年10月的2.6.36版本。
2014年，AppArmor 已经集成到了 Synology 的 DSM 5.1 Beta中
最新版本：3.0
项目主页：https://gitlab.com/apparmor