在AppArmor代码中,下列代码反映了AppArmor眼中的操作:
深入研究AppArmor的代码之后,作者发现上述代码并不是为了访问控制,而是为了在输出日志消息时体现操作类型的。而且上面只是一个框架,有些部分还没有完成,比如“OP_SYSCTL”,只有定义没有使用。
用于访问控制的是下面这些代码:
上面这些代码只是文件部分的操作许可。AppArmor不止可以对文件操作进行控制,还可以对其他客体对象进行访问控制,只不过对其他客体对象的访问控制没有像文件那样有明确的常量定义。下面看一下代码:(www.xing528.com)
在Linux 3.14-rc4主线中的AppArmor可以对三种客体进行访问控制:文件、能力和资源限制(rlimit)。在代码中,这三种客体的访问控制策略分别对应结构aa_profile的成员file、caps和rlimits。对于能力,AppArmor判断进程所需的能力是否包含在结构aa_profile的成员caps中对于资源限制,AppArmor判断进程当前的资源是否小于aa_profile的成员rlimits中的相关项。下面列出aa_caps和aa_rlimit的定义:
Linux系统中的客体类型很多,AppArmor只对其中一小部分施加了强制访问控制。其他部分就要靠Linux的自主访问控制了。作者认为,不太合乎逻辑的是AppArmor将对自身策略的管理也交给了属于自主访问控制的能力机制:具有CAP_MAC_ADMIN能力的进程可以修改AppArmor策略,尽管AppArmor可以对能力进行访问控制。
最后强调一点,AppArmor的开发还在进行中,新的AppArmor增加了对新型客体(如网络)的访问控制。
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。