https://www.elliot98.top/tags/apparmor/Recent content in AppArmor on Lutong's HomepageHugozh-cnFri, 22 May 2020 09:23:49 +0800https://www.elliot98.top/post/tech/apparmor/Fri, 22 May 2020 09:23:49 +0800https://www.elliot98.top/post/tech/apparmor/<blockquote> <p>AppArmor 是 Linux 系统中提供的强制访问控制 （MAC） 的安全控件，能够为我们的服务器提供更多的安全保障。但凡提起强制访问控制，我就会想起《计算器安全》这门课上学到的一堆枯燥的名词、概念和模型。仿佛强制访问控制离我们太远，很无趣，也没什么用。且慢，不妨让我们从 Linux 原生的访问控制说起。</p> </blockquote> <h2 id="linux-权限是不完备的">Linux 权限是不完备的？</h2> <p>Linux 系统原生控制机制（DAC) 相比大家都已经了解了。自主访问控制最大的特点就是由文件所有者来对文件进行访问控制。文件所有者可以对文件的权限进行设置，比如 Linux 系统下，就将一个文件的权限设置为 <code>属主权限 (u)</code> ，<code>属组权限 (g)</code> 以及<code>其他人权限 (o)</code> 三类来进行控制。当一个进程要读写一个文件的时候， Linux 内核就要充当看门老大爷的角色，判断这个进程是否有读写的权限。如果进程的<code>有效所有者</code>和<code>文件所有者</code>相同，则根据<code>属主权限 (u)</code>进行判断；如果<code>有效用户组</code>与<code>文件属组</code>相同，则根据<code>属组权限(g)</code>进行判断；否则根据<code>其他人权限(o)</code>进行判断。</p> <p>就好比张三和李四是同一间寝室的同学。张三有张三柜子的钥匙，他可以对柜子里的东西进行处置（属主权限）。张三和李四都拥有寝室的钥匙（张三和李四都属于同一个用户组）。但是隔壁寝室的老王却没有办法进入张三的寝室，也没有办法大概张三的柜子。这时候一切都很美好、很和谐。但是有一天，张三想把柜子里的大宝贝分享给隔壁寝室的老王。他应该怎么做呢？</p> <ol> <li>修改柜子的属者，把柜子交给老王？不行，这个柜子还是张三的，他可不想随便把柜子里的大宝贝送给别人。</li> <li>将老王加入到寝室的用户组里？不行，李四不愿意把钥匙交给隔壁老王。</li> <li>修改柜子的其他人权限？不错，老王是能够访问柜子了，可是隔壁的隔壁的老陈也能偷瞟柜子里的大宝贝了。</li> </ol> <p>张三没有办法，他只能再新建一个用户组（比如叫做“大宝贝分享组”），然后把老王添加到这个组中，然后再修改柜子的用户组为“大宝贝分享组”。很麻烦，对吧？ 其实还有一个困难。就是张三根本就没有办法使用 groupadd 命令，这一个命令是管理员命令，只能由班长来使用，可惜张三他并不是班长。因此这个办法也不能行得通。上面说了这么多，其实只是想吐槽一下 Linux 自主访问控制的设计是不完备的，不能满足很多需求。</p> <blockquote> <p>Windows NT 内核下的权限设计就要完备得多。Windows 下的文件权限控制不再分为属主、属组和其他人三类，而是可以为系统中的每一个用户、每一个用户组单独的分配权限。这些权限构成了一个叫做 ACL 的访问控制列表。</p> </blockquote> <h2 id="从自主访问控制到强制访问控制">从自主访问控制到强制访问控制</h2> <p>上面这个所说的这个问题其实对于普通用户来说，或许还并不关键。但是对于 root 用户来说，却变成了一个非常致命的问题。root 用户经常要下方一些权限给特定的用户或者特定用户组，这些操作往往是非常复杂且 dirty 的，最关键的是稍有不慎就可能导致严重的安全问题。</p> <p>Linux 内核后续强制访问控制模块，强制访问控制就是集中式的控制每一个进程的能力（比如能访问哪些文件、拥有哪些权限、可以监听什么网络地址等等）。这时候对于进程的限制不再是由文件所有者进行控制了，而是直接由<strong>系统管理员进行控制，也可以进行更加精细的设计</strong>。</p> <p>最早的 Linux 强制访问控制是 SeLinux 模块，想必各位 Centos 管理员都听说过。这个模块配置太复杂了，因此很多人上手的第一件事就是关闭这个模块。在 Debian/Ubuntu 下，使用 AppArmor 更为原生、更加简单易用。虽然没有 SeLinux 那么强，但是也能提供不错的安全防护。</p> <blockquote> <p>另一个不使用 SeLinux 的原因是很多人认为美国国家安全局 NSA 主导的 SeLinux 不靠谱，可能有·后门。</p>