同Tomoyo一样,AppArmor的强制访问控制机制是基于文件路径的。在AppArmor中的域主要是由进程所执行的文件的路径决定的。Tomoyo会不厌其烦地将进程以及进程的祖先所执行过的文件的路径都记录在进程的域中。AppArmor不同,它只会将最后一次执行的文件的路径作为域。
AppArmor将域设计成一种树状结构,域下可以有子域。这种设计的目的是让进程的域转换受到额外的限制。假设系统中有A、B、C三个域。系统管理员定制策略允许这三个域互相转换。域A下又有a、b、c三个子域。系统管理员可以定制策略允许域A转换到子域a、b、c,但无法定制出策略让域B和域C直接转换到域A的子域a、b、c。
和其他安全模块一样,在AppArmor中域间转换的途径有两条,一是执行文件,二是进程运行时自我改变。同样,域间转换会反映在策略上,需要策略允许。
1.文件执行
AppArmor中的域与进程所执行的文件相关,所以在进程执行文件时就有可能引起域的变化。结果是下面几种情况之一:
(1)根据文件名找到域,转换到文件所对应的域。这种情况又分为两种情况:
1)在当前域中存在相关的子域,转换到子域。
2)不存在子域,或不允许转换到子域,在当前域外存在一个以被执行的文件的文件名命名的域,转换到那个外部域。
(2)留在当前域。
(3)转换到“不受控制”(unconfined)的域。
10.1节说过AppArmor的设计主旨是针对单个应用的安全,而不致力于整个系统的安全。一般情况下,AppArmor的策略只能覆盖一部分进程。系统中其他进程都工作在不受控制的状态,这些进程的域就是“unconfined”。不仅如此,AppArmor的策略还允许进程将域转换为“unconfined”,从受控制的状态转换到不受控制的状态。
2.自我改变(www.xing528.com)
AppArmor的域的第二种转换方式是通过伪文件接口/proc/[pid]/attr/current。这种转换不能为所欲为,需要受到几个条件的限制:
(1)只能改进程自己的域,不能改别的进程的域。
(2)如果进程不是处在“unconfined”状态,并且进程的no_new_privs [21] 被置位,则不能修改。
(3)如果进程不是处在“unconfined”状态,并且进程的no_new_privs未被置位,则需要策略允许改动。
“自我改变”又有两种方式,第一种方式是向/proc/self/attr/current中写入“changeprofile NewDomain”。如果策略允许,那么执行后进程的域就是“NewDomain”。“changeprofile”是“单程车票”,第二种方式“changehat”是“往返车票”。第二种方式是向/proc/self/attr/current中写入“changehat token^hatdomain”,如“changehat 1234^hat”,如果策略允许,那么执行后进程的域就是“hat”。之后进程再向/proc/self/attr/current中写入“changehat 1234”,进程的域就恢复为原先的域了。上面例子中的“1234”称为令牌(token),它是进程和内核之间的“小秘密”,专门用来让进程返回原先的域。
“changeprofile”可以用来做域间转换,包括转换到外部域和转换到子域。“changehat”只能用于父域转换到子域。
3.命名空间
AppArmor也提供了命名空间(namespace)的概念,不同命名空间中策略配置相互隔离,不同的命名空间中同名的域可以有不同的策略。在实现中命名空间是一个被“:”包裹的字符串
其中“//”是可选项。
切换命名空间只能通过“changeprofile”方式,也就是向/proc/self/attr/current中写入“:namespace://domainname”。
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。