安全操作系统基于ACL的自主访问控制机制的设计与实现

维普资讯 http://www.cqvip.com 计算机科学２００４Ｖｏ１．３１Ｎ￣－．７　安全操作系统基于ＡＣＬ的自主访问控制机制的设计与实现　孙亚楠石文昌　梁洪亮孙玉芳　（中国科学院软件研究所　北京１　０００８０）　摘要　自主访问控制机制是安全操作系统必不可少的安全机制之一，而传统的文件权限保护模式不能提供更细柱　度的自主访问控制，无法满足越来越高的系统安全的要求。本文探讨了基于访问控制表的自主访问控制机制的设计与　实现的主要思想，并提出了利用文件系统的扩展属性机制存储访问控制表以及将自主访问控制机制实现为一个基于　ＬＳＭ安全框架的可加载模块的方法。　关键词　自主访问控制，访问控制表，扩展属性，Ｌｉｎｕｘ安全模型　Ｄｅｓｉｇｎ　ａｎｄ　Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　ｏｆ　ＡＣＬ　Ｂａｓｅｄ　Ｄｉｓｃｒｅｔｉｏｎａｒｙ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ　Ｍｅｃｈａｎｉｓｍ　ｉｎ　Ｓｅｃｕｒｅ　Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ　ＳＵＮ　Ｙａ—ｒＮａｎ　ＳＨＩ　Ｗｅｎ—ｒＣｈａｎｇ　ＬＩＡＮＧ　Ｈｏｎｇ—ｒＬｉａｎｇ　ＳＵＮ　Ｙｕ—ｒＦａｎｇ　（Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｓｏｆｔｗａｒｅ，Ｃｈｉｎｅｓｅ　Ａｃａｄｅｍｙ　ｏｆ　Ｓｃｉｅｎｃｅｓ，Ｂｅｉｊｉｎｇ　１　０００８０）　Ａｂｓｔｒａｃｔ　Ａｓ　ｔｈｅ　ｔｒａｄｉｔｉｏｎａ１　ｆｉｌｅ　ｓｙｓｔｅｍ　ｐｅｒｍｉｓｓｉｏｎ　ｍｏｄｅｌｉｎ　１ｉｎｕｘ　ｉＳ　ｉｎａｄｅｑｕａｔｅ　ｔＯ　ｐｒｏｖｉｄｅ　ｆｉｎｅ　ｇｒａｉｎｅｄ　ｄｉｓｃｒｅｔｉｏｎａｒｙ　ａｃｃｅｓｓ　ｃｏｎｔｒｏ１　ａｎｄ　ｃａｎ　ｎｏｔ　ｍｅｅｔ　ｔｈｅ　ｎｅｅｄ　ｏｆ　ｓｔｒｏｎｇ　ｓｙｓｔｅｍ　ｓｅｃｕｒｉｔｙ．Ｔｈｉｓ　ｐａｐｅｒ　ｆｏｃｕｓｅｓ　ｏｎ　ｔｈｅ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏ１　Ｌｉｓｔ　（ＡＣＬ）ｂａｓｅｄ　Ｄｉｓｃｒｅｔｉｏｎａｒｙ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏ１（ＤＡＣ）Ｍｅｃｈａｎｉｍ　ｌｎ　ｓｅｃｕｒｅ　Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ　ａｎｄ　ｐｒｅｓｅｎｔｓ　ａ　ｍｅｔｈｍｏｄ　ｔＯ　ｐｕｔ　ＡＣＬ　ｏｎ　Ｅｘｔｅｎｄｅｄ　Ａｔｔｒｉｂｕｔｅ（ＥＡ）ｍｅｃｈａｎｉｓｍ　ａｎｄ　ｔＯ　ｉｍｐｌｅｍｅｎｔ　ＤＡＣ　ｍｅｃｈａｎｉｓｍ　ａｓ　ａ　１ｏａｄａｂｌｅ　ｋｅｒｎｅ１　ｍｏｄｕｌｅ　ｗｉｔｈ　ｔｈｅ　ｈｏｏｋｓ　ｉｎｓｅｒｔｅｄ　ｉｎｔｏ　ｋｅｒｎｅ１　ｂｙ　ｔｈｅ　Ｌｉｎｕｘ　Ｓｅｃｕｒｉｔｙ　Ｍｏｄｕｌｅ（ＬＳＭ）．　Ｋｅｙｗｏｒｄｓ　ＤＡＣ（Ｄｉｓｃｒｅｔｉｏｎａｒｙ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏ１），ＡＣＬ（Ａｃｃｅｓｓ　Ｃｏｎｔｒｏ１　Ｌｉｓｔ），ＥＡ（Ｅｘｔｅｎｄｅｄ　Ａｔｔｒｉｂｕｔｅ），ＬＳＭ（Ｌｉｎｕｘ　Ｓｅｃｕｒｉｔｙ　Ｍｏｄｕｌｅ）　１引言　操作系统中的所有活动都可看作是主体对客体的一系列　操作，一个安全操作系统必须具备良好的访问控制机制来控　制主体对客体的活动。自主访问控制（ＤＡＣ）机制是安全操作　系统必不可少的安全机制之一，其基本原理是在身份鉴别机　制的基础上，由客体属主决定某一主体对文件、目录等客体的　访问权限，权限一经确定，将作为以后判断该主体对客体是否　具有以及具有什么权限的有效依据。传统的ＤＡＣ机制，即　“属主／同组用户／：ｇ他用户”文件权限保护模式将系统资源的　２自主访问控制机制及其设计　２．１　访问控制矩阵模型　访问控制机制的原理可以用图Ｉ的访问控制矩阵　表　示，在矩阵　中，Ｓ是主体集合，Ｏ是客体集合，Ｒ．　表示主体　Ｓ．对客体　的访问模式　。　Ｓｕｂｊｅｃｔｓ＼ｏｂｊｅｃｔｓ　Ｓ．　Ｏ　毒　、　ｌ　鼍　ｔ　一　访问权限划分为读、写、执行／搜索，指定给属主、同组用户和　其他用户三类，没有精确到属主以外的其他任一主体，粒度较　粗，不能满足实际应用的安全要求。访问控制表（ＡＣＬ）是实现　ＤＡＣ的一个有效方法，因此国内外的安全操作系统，如　Ｔｒｕｓｔｅｄ　Ｘｅｎｉｘ、Ｔｒｕｓｔｅｄ　ＢＳＤ、ＩＲＩＸ等，都采用ＡＣＬ提供更细　粒度和更灵活方便的自主访问控制，客体属主可以借助ＡＣＬ　给系统中任意主体或主体组指定自己拥有的任意权限，也可　以限制系统中任意主体或主体组不能以任何方式访问客体。　本文讨论我们研制的安全操作系统ＳＥＣＩＭＯＳ中ＤＡＣ　机制的设计与实现。该机制利用内核中的扩展属性机制（ＥＡ）　图１访问控制矩阵　为了实现良好的自主访问控制机制，由访问控制矩阵　提供的信息必须以某种形式存放在系统中。目前，访问控制矩　阵都不是被完整地存储，因为矩阵中的许多元素常常为空，空　元素将会造成存储空间的浪费，且查找某个元素会耗费很多　时间，因此在实现时通常基于矩阵的行或列来表达访问控制　信息。ＡＣＬ就是基于列的机制，它利用为客体提供一个主体　明细表的方法来表示访问控制矩阵　。　２．２访问控制表的语法规则　ＡＣＬ的语法规则兼容ＰＯＳＩＸ．１ｅ＋２ｃ标准ｌ－３］，每个ＡＣＬ　由一组ＡＣＬ规则组成，用来设置单一主体或一组主体对客　存储ＡＣＬ，并在内核中安插钩子函数实现资源访问控制，根　据用户指定方式或默认方式，阻止非授权主体访问客体，并控　制访问权限扩散。访问控制的粒度是单一主体，没有访问权的　主体只允许由授权主体指定对客体的访问权。我们的设计以　国家标准ＧＢ１　７８５９—１９９９“计算机信息系统安全保护等级划分　准则”第四级要求ｌ－ｌ　为依据。　体的访问权限，规则的外部形式是“［ｄｅｆａｕｌｔ：］规则类型标签：　规则限制符：权限”，如表１所示。为了可以同时对所有主体进　行设置，本文讨论的ＳＥＣＩＭＯＳ系统的ＤＡＣ机制对ＡＣＬ进　行扩充，增加了ＡＣＬ—ＡＬＬ和ＡＣＬ—ＮＯＮＥ规则。一个有效　硕士生，主要研究方向为系统软件与计　＊）国家８６３高技术研究发展项目（２ｏｏ２ＡＡ１４１０８０）和国家自然科学基金项目（６００７３０２２）资助。孙亚楠算机安全。石文昌研究员，博士，主要研究方向为系统软件与计算机安全。梁洪亮博士，主要方向为系统软件与计算机安全　孙玉芳研究　员，博导，主要研究方向为系统软件与中文信息　・１５３・　维普资讯 http://www.cqvip.com ＡＣＬ必须包含ＡＣＬ—ＵＳＥＲ—ＯＢＪ、ＡＣＬ—ＧＲＯＵＰ—ＯＢＪ和　ＡＣＬ—ＯＴＨＥＲ三条基本规则，若包含ＡＣＬ—ＵＳＥＲ或ＡＣＬ—　ＧＲＯＵＰ规则，则必须具有一条ＡＣＬ—ＭＡＳＫ规则，其余规则　可选。若一个ＡＣＬ同时包含ＡＣＬ—ＡＣＬＬ和ＡＣＬ—ＮＯＮＥ规　则，则两者的权限集不能相交。ＡＣＬ从作用上分为Ａｃｃｅｓｓ　ＡＣＬ和Ｄｅｆａｕｌｔ　ＡＣ［　两种类型，前者确定客体访同权限，后　者只适用于目录类型的客体，用于确定在目录下创建新客体　时，新客体继承父目录的权限，不直接用于访问裁决。　表１　ＡＣＬ规则的类型　类型标签　外部形式（类型标签：规则限制符：权限）　ＡＣＬ——ＵＳＥＲ——０ＢＪ　［ｄｅｆａｕｌｔ：ｕｓｅｒ：：ｐｅｒｍｉｓｓｉｏｎｓ　ＡＣＬ—ＵＳＥＲ　［ｄｅｆａｕｌｔ：ｕｓｅｒ：ｕｉｄ或ｕｓｅｒ—ｎａｍｅ：ｐｅｒｍｉｓｓｉｏｎｓ　ＡＣＬ——ＧＲＯＵＰ——ＯＢＪ　［ｄｅｆａｕｌｔ：］ｇｒｏｕｐ：：ｐｅｒｍｉｓｓｉｏｎｓ　规则含义　客体属主对客体的权限　某个用户对客体的权限　属主所在组对客体的权限　ＡＣＬ—ＧＲＯＵＰ　ＡＣＬＭＡＳＫ　［ｄｅｆａｕｌｔ：］ｇｒｏｕｐ：ｇｉｄ或ｕｓｅｒ—ｎａｍｅ：ｐｅｒｍｉｓｓｉｏｎｓ　［ｄｅｆａｕｌｔ：ｍａｓｋ：：ｐｅｒｍｉｓｓｉｏｎｓ　某个用户组对客体的权限　限制除了客体属乇和ｏｔｈｅｒ之外的特定用户和用户组的　最大权限　其他用户对客体的权限　所有用户对客体都具有的权限　所有用户对客体都不具有的权限　ＡＣＬ—ＯＴＨＥＲ　ＡＣＬ—ＡＬＬ　ＡＣＬ—ＮＯＮＥ　［ｄｅｆａｕｌｔ：］ｏｔｈｅｒ：：ｐｅｒｍｉｓｓｉｏｎｓ　［ｄｅｆａｕｌｔ：］ａｌｌ：：ｐｅｒｍｉｓｓｉｏｎｓ　［ｄｅｆａｕｌｔ：ｎｏｎｅ：：ｐｅｒｍｉｓｓｉｏｎｓ　２．５访问控制表的客体与权限细化及访问检查算法　ＡＣＬ的主体为进程或用户，客体细化为文件、目录、设　备、符号连接、系统进程、进程间通信等类型。其中对文件、目　录和设备类型，访问控制细化到具体单个客体，对符号连接、　系统进程和进程间通信类型的客体则提供整体的控制。主体　对客体的权限由原来的读、写、执行扩充为读、写、执行、搜索、　权限时，才允许进程对客体的访问　。当用户进程请求搜索一　条路径，进程必须具有路径名中每一个目录分量的搜索权　ＡＣＬ的访问检查算法逻辑描述如图２所示。　表２客体的ＡＣＬ最大权限集　客体　客体的最大权限集　创建、删除、硬连接、截断、追加、重命名、改变所有者或组、改　变目录、读属性、修改属性、关闭、克隆、终止、发信号、获取状　态数据等。　普通文件　读、写、创建、执行、删除、硬连接、截断、追加、重命名、改　变所有者或组、改变目录、读属性、修改属性、关闭　目录　设备　搜索、创建、删除、重命名、改变所有者或组、读属性、修改　属性　由于ＤＡＣ是由资源的属主决定谁可以对资源进行何种　访问，在实际应用中，某些关键资源的属主可能对系统和安全　读、写、读属性、修改属性、符号连接、改变所有者或组、关　闭　没有深入了解，较难准确地设置资源的安全属性。因此本文讨　论的ＤＡＣ机制必须尽可能地弥补这一点，为各类客体规定　了最大权限集，防止操作人员的误操作，如表２所示。　当一个用户进程访问一个客体时，将进程的有效ＵＩＤ、　ＧＩＤ等用户标识信息和请求访问方式（ｍｏｄｅ）与客体的Ａｃ—　ｃｅｓｓ　ＡＣＬ中的规则进行比较，决定是否赋予其相应的访问权　限。仅当一条匹配的ＡＣＬ规则的权限集包含所有请求的访问　系统进程　创建、克隆、发信号、终止、改变所有者或组、获取状态数　据　符号连接　由符号连接目标的最大权限集所决定　进程通信　创建、删除、读属性、修改属性、读、写、关闭　ｉｆ（客体　Ａｃｃｅｓｓ　ＡＣＬ包含ＡＣＬ—ＡＬＬ规则）且（该规则的权限集包含进程请求的权限）　ｔｈｅｎ　Ａｃｃｅｓｓ　ｉｓ　ｇｒａｎｔｅｄ　ｉｆ（客体Ａｃｃｅｓｓ　ＡＣＬ包含ＡＣＬ—ＮＯＮＥ规则）且（该规则的权限集包含进程请　求的权限）　ｔｈｅｎ　Ａｃｃｅｓｓ　ｉｓ　ｄｅｎｉｅｄ　ｉｆ（进程的有效ＵＩＤ匹配客体属主的ＵＩＤ）　ｆ　ｉｆ（ＡＣＬ—ＵＳＥＲ—ＯＢＪ规则的权限集包含进程请求的权限）　ｔｈｅｎ（ｔｈｅｎ　Ａｃｃｅｓｓ　ｉｓ　ｇｒａｎｔｅｄ　Ｉ　ｅｌｓｅ　Ａｃｃｅｓｓ　Ｉｓ　ｄｅｎｔｅｄ　ｉｆ（客体Ａｃｃｅｓｓ　ＡＣＬ包含ＡＣＬ—ＵＳＥＲ规则）且（进程的有效ＵＩＤ匹配　其中一条ＡＣＬ—ＵＳＥＲ规则的限制符）　ｆ　ｉｆ（该ＡＣＬ－ＵＳＥＲ规则的权限集包含进程请求的权限）且　＋ｈ。　、“一‘Ｊｔｈｅｎ　Ａｃｃｅｓｓ　ｉｓ　ｇｒａｎｔｅｄ　Ｉ　ｅｌｓｅ　Ａｃｃｅｓｓ　ｉｓ　ｄｅｎｉｅｄ　（ＡＣＬ—ＭＡＳＫ规则的权限集包含进程请求的权限）　ｉｆ（进程的有效ＧＩＤ匹配客体属主的ＧＩＤ）　ｋ。　』ｉｆ（ＡＣＬ—ＵＳＥＲ—ＯＢＪ规则的权限集包含进程请求的权限）　“　“、ｔｈｅｎ　Ａｃｃｅｓｓ　ｉｓ　ｇｒａｎｔｅｄ　ｅｌｓｅ　Ａｃｃｅｓｓ　ｉｓ　ｄｅｎｉｅｄ　ｆ　ｉｆ（客体Ａｃｃｅｓｓ　ＡＣＬ包含ＡＣＬ—ＧＲＯＵＰ规则）且（进程　　ｌ的有效ＧＩＤ匹配其中一条ＡＣＬ—ＧＲＯＵＰ规则的限制符）　　ｌｋ。　ｅｌｓ　……１　ｔｈｅｎ　Ａｃｃｅｓｓ　ｉｓ　ｇｒａｎｔｅｄ　　ｌＩ　ｅｌｓｅ　Ａｃｃｅｓｓ　ｉｓ　ｄｅｎｉｅｄ　ｆ　ｉｆ（该ＡＣＬ—ＧＲＯＵＰ规则的权限集包含进程请求的权限）　Ｊ　且（ＡＣＬ—ＭＡＳＫ规则的权限集包含进程请求的权限）　ｆ　【　　Ｉｅｌｓｅ（ｔｈｅｎ　Ａｃｃｅｓｓ　ｉｓ　ｇｒａｎｔｅｄ　ｌ　ｅｌｓｅ　ＡｃｃｅｓＳ　ｉｓ　ｄｅｎｉｅｄ　ｆ　ｉｆ（ＡＣＬ—ＯＴＨＥＲ规则中的权限包含进程请求的权限）　图２访问检查算法伪代码　２．４访问控制表的初始化及继承机制　创建一个客体时，由属主、超级用户或授权用户决定是否　・为它初始化Ａｃｃｅｓｓ　ＡＣＬ。首先确定各类客体的上级客体。文　件／目录类型的客体的上级客体就是父目录，可以一直追溯到　１５４・　维普资讯 http://www.cqvip.com 根（／）目录，／目录的上级客体指定为该类型的Ｄｅｆａｕｌｔ客体。　设备类型的客体的上级客体是该类型的Ｄｅｆａｕｌｔ客体。对于　ＩＰＣ和系统进程的客体．系统初始默认只有Ｄｅｆａｕｌｔ客体。各　类客体的［）ｅｆａｕｌｔ客体是整个此类客体的抽象，具有不会随　着客体的变化而变化的Ｄｅｆａｕｌｔ　ＡＣＬ　。　当用ｃｒｅａｔ（）、ｍｋｄｉｒ　（）、ｍｋｎｏｄ（）、ｍＵｉｆｏ（）和ｏｐｅｎ（）（有　０　ＣＲＥＡＴ参数）等函数新建一个文件时，它的Ａｃｃｅｓｓ　ＡＣＬ　按如下顺序计算：　１．若它的上级客体具有Ｄｅｆａｕｌｔ　ＡＣＬ，则继承这个Ｄｅ—　ｆａｕｌｔ　ＡＣＬ作为它的初始Ａｃｃｅｓｓ　ＡＣＬ。再修改这个Ａｃｃｅｓｓ　ＡＣＬ中与文件权限位模式对应的ＡＣＬ　ＵＳＥＲ　０ＢＪ、ＡＣＬ　ＧＲＯＵＰ一０ＢＪ和ＡＣＬ　ＯＴＨＥＲ规则，去除创建进程的ｍｏｄｅ　参数中没有指定的权限．得到新客体的Ａｃｃｅｓｓ　ＡＣＬ。　２．如果上级客体没有Ｄｅｆａｕｌｔ　ＡＣＬ．则由创建进程的　ｍｏｄｅ参数和文件创建掩码ｕｍａｓｋ一起决定新客体的Ａｃｃｅｓｓ　ＡＣＬ。新客体的ＡＣＬ—ＵＳＥＲ—ＯＢＪ、ＡＣＬ　ＧＲ０ＵＰ一０ＢＪ、和　ＡＣＬ—ＯＴＨＥＲ规则的权限由文件创建掩码决定．去除创建进　程的ｍｏｄｅ参数中没有指定的权限，得到新客体的Ａｃｃｅｓｓ　ＡＣＬ。　由于对访问权限进行了细化，为了更好地实现权限继承　机制，引入权限屏蔽值ｍａｓｋ的概念，其每一位对应一项权限．　分别用ｏ／１表示。权限屏蔽值ｍａｓｋ一般默认为全１。如果没有　具体指明主体对客体（文件／目录、符号连接、设备）的权限，则　主体可以继承它对当前客体的上级客体的Ｄｅｆａｕｌｔ　ＡＣＬ，若　不想继承，就将相应的权限位设为０，反之为１。当客体被创建　后，可以设置它的权限屏蔽值。将权限屏蔽值与继承上级客体　的Ｄｅｆａｕｌｔ　ＡＣＬ的权限项相与，作为当前主体对当前客体的　权限，并覆盖Ｄｅｆａｕｌｔ　ＡＣＬ相应的权限项。　５实现方法　５　１访问控制表的存储与传递　要实现访问控制表，关键问题之一是访问信息的存放，需　保证其机密性、完整性和可用性。由于访问控制信息一般都很　短小，因此可以作为扩展属性存储，并通过预分配好大小的缓　冲区在内核和用户空间传递。为一个客体增加一个ＡＣＬ时，　就为之分配一个单独的扩展属性块，记录着（ｎａｍｅ：ｖａｌｕｅ）对。　在Ｅｘｔ２／Ｅｘｔ３文件系统中每个ｉ节点结构中都有一个预留域　ｚ一　ｌｅ—ａｃｌ，指向存储与这个ｉ节点关联的ＡＣＬ信息的扩展　属性块。因此只需一次磁盘访问就可以检索到ｉ节点的扩展　属性。为了保证信息的完整性，一个ｉｎｏｄｅ的所有扩展属性一　般存储在一个扩展属性块中　Ｊ。　为了提高效率，若多个ｉ节点的ＡＣＬ扩展属性都相同，　这些ｉ节点就可以共享相同的扩展属性块。通过计算扩展属　性块的哈希值可以检测到相同块并对该块进行缓冲。当需要　产生一个新块时，会先在缓冲中寻找。如果找到同样的块，重　用该块（只需要增加磁盘引用计数，最大为１０２４），否则分配一　个新块。如果一个指向共享的ＥＡ块的ｉｎｏｄｅ和它的ＡＣＬ属　性名和值被修改了，且没有被引用，则采用覆盖写的机制进行　更新　当一个文件系统中的客体第一次被访问时，它的访问控　制表从ｉ节点和扩展属性块中转换成能被快速处理的内存格　式。由于对ＡＣＬ访问会很频繁，当沿着路径在嵌套很深的目　录中访问ＡＣＬ时尤其如此，因此为了加快权限检查和文件创　建，我们对ＡＣＬ采用缓存方式。　５．２访问控制表与文件权限模式的协调　Ｌｉｎｕｘ的文件权限保护模式是在每个文件上附加一段有　关存取信息的二进制位，缺点是客体的属主不能精确控制单　个主体对客体的访问权，优点是非常简单、高效，在某些应用　上起到一定的作用。因此将仅限位保护模式与ＡＣＬ共存于系　统中，文件权限位模式的ｏ　ｗ，　／ｇｒｏｕｐ／ｏｔｈｅｒ分别映射到　ＡＣＬ　ＵＳＥＲ一０ＢＪ、ＡＣＬ　ＧＲＯＵＰ　ＯＢＪ（若ＡＣＬ有ＡＣＬ～　ＭＡＳＫ则映射列ＡＣＬ　ＭＡＳＫ）、ＡＣＬ　ＯＴＨＥＲ，保持完全同　步。ＡＣＬ的处理函数兼容文件仪限模式的处理函数．如　ｃｈｍｏｄ（）、ｃｒｅａｔ（）、ｓｔａｇ（）等。　当要进行访问权限检查时，采用一定的算法使二者协调　工作。Ｔｒｕｓｔｅｄ　Ｘｅｎｉｘ安全操作系统采用的算法是首先判断要　访问的客体是否具有ＡＣＬ．若有．进行ＡＣＬ权限检查，若无．　则检查文件权限保护模式一］。本文的自主访问控制机制是基　于ＬＳＭ安全模型框架上实现，我们采用与Ｔｒｕｓｔｅｄ　Ｘｅｎｉｘ不　同的算法。当要决定主体对客体是否拥有某种权限时．首先判　断主体请求是否满足系统对客体的文件权限保护模式，满足　则允许主体进行请求的操作；若不满足，则检查该客体是否具　有访问控制表，若有再判断是否满足访问控制表机制，若满　足，允许主体进行请求的操作，反之拒绝请求。　５．５　自主访问控制机制的基本框架　本文讨论的ＳＥＣＩＭＯＳ安全操作系统的ＤＡＣ机制的实　现目标是基于ＬＳＭ安全模型框架　］，通过完善钩子函数，实　现对资源的访问控制，减小对内核的改动，能不加修改地运行　现有应用程序，并且使得系统开销应尽可能减小。ＤＡＣ机制　的基本框架如图３所示　进程ｌＨ　Ｌ　二：系统调用　　善　耋蛋蠢霎磬、、＞限位保护模式？—，，——————　墨，　一　／　访问客体是　否　否具有ＡＣＬ？　＼／　ＬＳＭ钩子　最　授权　图３　ＤＡＣ机制基本框架　在ＤＡＣ中，将ＡＣＬ作为ＥＡ在用户空间和内核空间传　递、在ＶＦＳ和更底层的文件系统层之间传递，这样简化了系　统接口。扩展属性是根据名字来识别的，比如“ｓｙｓｔｅｍ．ｐｏｓｉｘ—　ＡＣＬ—Ａｃｃｅｓｓ”和“ｓｙｓｔｅｍ．ｐｏｓｉｘ—ＡＣＬ—Ｄｅｆａｕｌｔ”分别代表了客　体的ＡＣＬ和Ｄｅｆａｕｌｔ　ＡＣＬ，ＡＣＬ属性值以一种体系结构无关　的格式存储。遵循Ｐｏｓｉｘ．１ｅ标准的应用程序通过调用ｌｉｂＡＣＬ　库实现兼容，该库实现了ｐｏｓｉｘ．１ｅ标准定义的ＡＣＬ处理函　数。ＡＣＬ的权限检查通过在系统调用中插入钩子函数来实　现，当关闭ＡＣＬ机制时，钩子返回ＮＵＬＬ。　（下转第１６２页）　・］５５・　维普资讯 http://www.cqvip.com ５　ＵＡ设计　ＵＡ驻留于客户端．主要为用户应用系统提供按入服务．　ＸＭＬＳｃｈｅｍａ数据类型和Ｊａｖａ数据类型之间的映射。Ａｃ—　ｃｅｓｓＳｅｒｖｉｃｅＩＦ的Ｊａｖａ定义如下：　ｐｕｂｌｉｃ　ｉｎｔｅｒｆａｃｅ　ＡｃｃｅｓｓＳｅｒｖｉｃｅＩＦ　ｅｘｔｅｎｄｓ　Ｒｅｍｏｔｅ｛　ｐｕｂｌｉｃ　ａｂｓｔｒａｃｔ　Ｓｏｕｒｃｅ　ｓｅｎｄＤａｔａ（Ｓｏｕｒｃｅ　ｓｏｕｒｃｅＤａｔａ）ｔｈｒｏｗｓ　Ｒｅｍｏ—　ｔｅＥｘｃｅｐｔｉｏｎ；　ｐｕｂｌｉｃ　ａｂｓｔｒａｃｔ　Ｓｏｕｒｃｅ　ｒｅｃｅｉｖｅＤａｔａ（Ｓｔｒｉｎｇ　ｍｅｍｂｅｒｌｄ）ｔｈｒｏｗｓ　Ｒｅ—　ｍｏｔｅＥｘｃｅｐｔｉｏｎ；　并且作为接收方还要随时接收从ＭＣ发送的其它用户的交换　数据。ＵＡ的设计要考虑跨平台和可移植的要求，不能受到用　户应用系统运行平台的限制。ＥａｓｙＳｗｉｔｃｈ采用ＸＭＬ—ＲＰＣ作　ｐｕｂｌｉｃ　ａｂｓｔｒａｃｔ　Ｓｃｈｅｍａｌｎｆｏ口ｇｅｔＳｃｈｅｍａＩｎｆｏ（Ｓｔｒｉｎｇ　ｍｅｍｂｅｒＩｄ）　ｔｈｒｏｗｓ　ＲｅｍｏｔｅＥｘｃｅｐｔｉｏｎ；　为接口层基本的服务调用方式，最大限度地降低了数据中间　件的ＡＰＩ层的访问难度，同时保证了平台独立性要求。　５．１　ＵＡ和用户应用系统的交互模式　ｐｕｂｌｉｃ　ａｂｓｔｒａｃｔ　Ｅｒｒｏｒｌｎ［ｏ口ｇｅｔＥｒｒｏｒＩｎ｛ｏ（）ｔｈｒｏｗｓ　ＲｅｍｏｔｅＥｘｃｅｐ—　ｔｌｏｎ；　｝　ＵＡ屏蔽了ＥａｓｙＳｗｉｔｃｈ内部的复杂结构和运行过程，向　企业应用系统展现出一个单一的服务接口。同时，ＵＡ还能适　应用户环境的变化．比如当用户ＩＰ地址发生变化时，ＵＡ能　够即时发送更新信息到ＭＣ。ＵＡ和用户应用系统之间的交　换模式如图４所示。　Ｉ　７Ａ　总结为适应各企业应用系统间进行数据交换协作的需　求．解决异构系统集成困难，本文基于行业内交流数据的相似　性和相关性理论．通过行业数据标准的设立和数据模式的节　点分解构造出可重构的数据交换核心，并在此基础上通过采　用ＳＯＡＰ，ＸＭＬ—ＲＰＣ等标准协议规范开发了应用集成框架，　从而完整地实现了一个异构系统基于数据交换的协作平台　ＥａｓｙＳｗｉｔｃｈ。通过对数据交换核心的重构可使ＥａｓｙＳｗｉｔｃｈ适　用于不同领域，比如证券系统问交易数据的交换，电子政务系　统间的公文流转等。本文所实现的ＥａｓｙＳｗｉｔｃｈ系统现已初步　应用于重庆市摩托车电子商务平台，是一个典型的行业内企　业数据交换的应用。需要指出的是，ＥａｓｙＳｗｉｔｃｈ不仅可用于　图４　ＵＡ和用户应用系统交互模式示意图　１）ＡｃｃｅｓｓＳｅｒｖｉｃｅＩＦ是ＵＡ的接入服务接口，它为用户应　用系统中的ｃｌｉｅｎｔ方提供包括数据交换在内的所有服务调　用。　行业内相关企业进行数据交换集成，对于企业内部各个子系　统进行数据协作也能很好地支持。　根据企业实际的业务流程框架及信息技术的发展状况可　以把企业集成分为数据集成和服务集成。基于数据处理的商　务过程，对于自主运行的应用系统来说，在收到某一类型的业　２）ＤａｔａＲｅｃＳｖｒ是ＵＡ中的数据接收服务器，它随时准备　接收从ＭＣ发送的其它企业的交换数据消息。　３）ｒｅｃｅｉｖｅｒ是用户应用系统提供的数据接收服务接口，用　户必须在安装ＵＡ时定义ｒｅｃｅｉｖｅｒ的位置信息。当　ＤａｔａＲｅｃＳｖｒ收到数据消息后，从配置文件中读取ｒｅｃｅｉｖｅｒ的　信息，然后通过动态调用方式生成ＸＭＬ—ＲＰＣ服务请求并发　送到ｒｅｃｅｉｖｅｒ中，完成一次数据交换过程。　务数据后能够触发内部处理流程，ＥａｓｙＳｗｉｔｃｈ对于这种基于　数据交换的应用协作提供了完整的解决方案。如何扩展　ＥａｓｙＳｗｉｔｃｈ的应用集成框架，实现对企业间基于功能服务的　集成是下一步研究的内容。　参考文献　１　Ｇａｂｒｉｃｋ　Ｋ　Ａ，Ｗｅｉｓｓ　Ｄ　Ｂ．Ｊ２ＥＥ　ａｎｄ　ＸＭＬ　Ｄｅｖｅｌｏｐｍｅｎｔ。Ｍａｎｎｉｎｇ　Ｐｕｂｌｉｃａｔｉｏｎ，２００２　５．２基于ＸＭＬ—ＲＰＣ服务接口的实现　ＵＡ中的ＡｃｃｅｓｓＳｅｒｖｉｃｅＩＦ和用户应用系统提供的ｒｅ—　ｃｅｉｖｅｒ都是基于ＸＭＬ—ＲＰＣ方式定义的服务接口，它通过　ＷＳＤＬ文档来描述其服务的名称及参数类型，调用指令和返　回数据都是以标准的ＳＯＡＰ封装传送的。ＵＡ方的Ａｃ—　２　ＳＯＡＰ　Ｖｅｒｓｉｏｎｌ　２　Ｓｐｅｃｉｆｉｃａｔｉｏｎ．ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００３／　ＰＲ－ｓｏａｐｌ２－ｐａｒｔ１—２００３０５０７／．ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００３／　ＰＲ—ｓｏａｐ１２－ｐａｒｔ２—２００３０５０７／　３　ＪＡＸＲＰＣ一１．０　Ｓｐｅｃｉｆｉｃａｔｉｏｎ，Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ，２００２　４　ＳＡＡＪ１．１　Ｓｐｅｃｉｆｉｃａｔｉｏｎ，Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ，２００２　ｃｅｓｓＳｅｒｖｉｃｅＩＦ是采用ＪＡＸ—ＲＰＣ来开发的，ＪＡＸ—ＲＰＣ提供了　基于ＳＯＡＰ的ＲＰＣ调用运行环境，其核心是实现了标准　（上接第１５５页）　５　Ｍｙｅｒｓｏｎ　Ｊ　Ｍ．Ｔｈｅ　Ｃｏｍｐｌｅｔｅ　Ｂｏｏｋ　ｏｆ　Ｍｉｄｄｌｅｗａｒｅ．Ａｕｅｒｂａｃｈ　Ｐｕｂ—　ｎｃａｔｉｏｎｓ，２００２　地支持实际应用中的ＤＡＣ要求。　５．４性能影响分析　如果将ＡＣＬ信息集中存放在文件中，要访问ＡＣＬ，在文　件最近未被访问过的前提下，需要至少两次磁盘访问，而通过　文件系统的扩展属性机制存放ＡＣＬ，利用文件系统ｉｎｏｄｅ的　缓冲机制，可以减少访问磁盘的次数。且扩展属性块可以被多　次引用，提高了效率。　结束语本文探讨了安全操作系统ＳＥＣＩＭＯＳ中基于访　问控制表的自主访问控制机制的设计与实现的主要思想，并　讨论了ＡＣＬ如何与传统ｌｉｎｕｘ的文件权限保护模式在系统　中协调工作的问题。本文所提出的ＤＡＣ机制不仅对授权主　体细化到单个用户，并且对权限和系统可操作的客体类型也　参考文献　１　中国国家标准一计算机信息系统安全保护等级划分准则ＧＢ１７８５９—　１９９９　２　石文昌，孙玉芳．安全操作系统研究的发展（上）．计算机科学，　２００２．（２９）６　３　ＩＥＥＥ　Ｄｒａｆｔ　Ｐ１００３．１ｅ／２ｃ　ＩＥＥＥ　Ｓｔａｎｄａｒｄ　Ｄｅｐａｒｔｍｅｎｔ，１９９７　４　Ｇｒｕｎｂａｃｈｅｒ　Ａ．Ｐｏｓｉｘ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ　Ｌｉｓｔｓ　ｏｎ　Ｌｉｎｕｘ，ＳｕＳＥ　Ｌａｂｓ。　ｌｉｎｕｘ　ＡＧ　５红旗安全操作系统技术白皮书．ｈｔｔｐ：／／ｗｗｗ．ｒｅｄｆｌａｇ—ｌｉｎｕｘ．ｃｏｍ／　ｓｅｃｕｒｉｔｙ／ｄｏｃｕｍｅｎｔ／ｗｈｉｔｅｐａｐｅｒ．ｐｄｆ　６　Ｇｉｌｄｆｉｎｄ　Ａ．Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ　ｌｉｓｔｓ　ａｎｄ　Ｅｘｔｅｎｄｅｄ　ａｔｔｒｉｂｕｔｅｓ　ｏｎ　ｌｉｎｕｘ．　ＳＧＩ　７　Ｆｉｎａｌ　ｅｖａｌｕａｔｉｏｎ　ｒｅｐｏｒｔ．Ｔｒｕｓｔｅｄ　Ｘｅｎｉｘ　ｖ３．０。Ｎａｔｉｏｎａｌ　Ｃｏｍｐｕｔｅｒ　Ｓｅｃｕｒｉｔｙ　ｃｅｎｔｅｒ　加以细化，针对不同类型的客体给出客体的权限范围，完善了　访问权限检查算法。提出了权限屏蔽值和Ｄｅｆａｕｌｔ客体的概　念，使我们的安全操作系统ＳＥＣＩＭＯＳ的ＤＡＣ机制能够灵活　８　Ｍｏｒｒｉｓ　Ｊ，ｅｔ　ａ１．Ｌｉｎｕｘ　Ｓｅｃｕｒｉｔｙ　Ｍｏｄｕｌｅｓ：Ｇｅｎｅｒａｌ　Ｓｅｃｕｒｉｔｙ　Ｓｕｐｐｏｒｔ　ｆｏｒ　ｔｈｅ　Ｌｉｎｕｘ　Ｋｅｒｎｅ１．ｈｔｔｐ：／／ｗｗｗ．ｉｎｔｅｒｃｏｄｅ．ｃｏｒｎ．ａｕ／ｉａｍｅｓｍ／　ｌｓｍ—ｕｓｅｎｉｘ—ｈｔｍｌ／ｌｓｍ—ｈｔｍ１．ｈｔｍｌ，２００２　・１６２・