SE Linux 是如何工作的呢？首先，别指望一开始就是分布式的。 SE Linux 是 包括在标准中的一个成果，而不要认为它的成果是成为 那个 标准。作者希望在 Linux 内核中具有必要的访问控制，这就是支持 SE Linux 的思想。许多实现问题在它可以用在现实世界中之前都需要加以解决（或代码编写）。幸运的是，Linux 历史上就有一些供应商为了费用做这些事，我现在希望某一天能看到 RedHat 的 SE Linux。
整个安全性体系结构称为 Flask，在犹他大学和 Secure Computing Corp. 的协助下由 NSA 设计。在 Flask 体系结构中，安全性策略的逻辑和通用接口一起封装在与操作系统独立的组件中，通用接口是用于获得安全性策略决策的。这个单独的组件称为安全性服务器，即使它只是个内核子系统而已。该服务器的 SE Linux 实现定义了一种混合的安全性策略，由类型实施 (TE)、基于角色的访问控制 (RBAC) 和可选的多级别安全性 (MLS) 组成，所以广泛用于军事安全性中。该策略由另一个称为 checkpolicy 的程序编译，它由安全性服务器在引导时读取。文件被标为 /ss_policy 。这意味着安全性策略在每次系统引导时都会有所不同。策略甚至可以通过使用 security_load_policy 接口在系统操作期间更改（只要将策略配置成允许这样的更改）。
Flask 有两个用于安全性标签的与策略无关的数据类型 -- 安全性上下文和 安全性标识 。安全性上下文是表示安全性标签的变长字符串。安全性标识 (SID) 是由安全性服务器映射到安全性上下文的一个整数。SID 作为实际上下文的简单句柄服务于系统。它只能由安全性服务器解释。Flask 通过称为对象管理器的构造来执行实际的系统绑定。它们不透明地处理 SID 和安全性上下文，不涉及安全性上下文的属性。任何格式上的更改都不应该需要对对象管理器进行更改
安全性服务器只为包含用户、角色、类型和可选 MLS 范围合法组合的安全性上下文提供 SID。“合法性”是由安全性策略配置（将在本文的稍后部分介绍）所确定的。
一般来说，对象管理器查询安全性服务器以根据标签对（主体的和客体的）和对象的类获得访问决定。类是标识对象是哪一种类（例如，常规文件、目录、进程、UNIX 域套接字，还是 TCP 套接字）的整数。向量中的许可权通常由对象可以支持的服务和实施的安全性策略来定义。访问向量许可权基于类加以解释，因为不同种类的对象有不同的服务。例如，访问向量中使用的许可权位表示文件的 'unlink' 许可权，它也用于表示套接字的 'connect' 许可权。向量可以高速缓存在访问向量高速缓存 (AVC) 中，也可以和对象一起存储，这样，对象管理器就不必被那些已执行的决策的请求淹没。
对象管理器还必须为将标签分配给它们的对象定义一种机制。在服务流中指定管理器如何使用安全性决定的控制策略还必须由管理器定义和实现。在策略更改的情况下，对象管理器必须定义将调用的处理例程。在任何情况下，对象管理器都必须将对象的安全性上下文作为不透明的字符串处理。通过这种方式，不应该有合并到对象管理器中的特定于策略的逻辑.
