了解 AIX 高级特性: 简便的基于角色的访问控制

详细步骤和示例

安全性是操作系统关注的主要问题之一。这个文章系列介绍 AIX® 上的新特性,基于角色的访问控制和多级安全性。本系列的第 1 部分讨论 AIX 基于角色的访问控制 (RBAC) 以及如何把根用户的角色、责任和授权分配给多个用户。

Rajesh K. Jeyapaul, 技术负责人,AIX 开发支持, IBM  

/developerworks/i/p-rjeyapaul.jpgRajesh K. Jeyapaul 拥有软件系统和商业管理硕士学位。他领导印度 Bangalore 的 AIX 开发支持团队,编写过多份 IBM 红皮书。他的专长包括 AIX 问题判断、高可用性、虚拟化和性能。



2009 年 8 月 03 日

您可以访问“AIX 6 资源中心”了解更多和 AIX 6 相关的资源:

简介

过去,由单一用户(root 用户)控制系统的安全机制。root 用户决定谁可以登录、谁可以访问数据、哪些进程有权进入内核模式等。但是,单一 root 用户的缺点是,如果未经授权的人控制了根用户,系统就非常容易受到攻击。

为了避免这个问题,AIX 的最新版本(5.3TL07 和 6.1)引入了 RBAC 和多级安全性 (MLS) 等新的安全特性,还在传统的基于 root 用户的身份验证中增加了其他特性,比如 Trusted Execution (TE)、Encrypted File System (EFS) 等。

本文通过示例解释如何理解和应用 RBAC 和 MLS 等新特性。

安全管理概述

  • 传统机制
  • RBAC

传统机制

可以使用 DAC(Discretionary Access Control,自主访问控制)控制对数据的访问(按进程/文件关系)。但是,具有所有特权的 root 用户是单一用户。 root 用户可以进行任何访问控制和执行任何操作。这可能造成严重的安全威胁。

另外, root 用户常常担任系统管理员、安全官(维护安全策略)和系统操作员(执行日常活动)等许多职位。由单一用户控制系统,其他用户完全无法控制系统中的活动。

RBAC 可以把 root 用户的角色和授权分配给多个用户。本文解释 RBAC 如何改进系统的安全性。

RBAC

传统的 AIX 系统具有有限的授权集,可以使用它们决定对某些管理命令的访问。下面的示例显示 passwd 命令就是一个 setuid 程序,setuid 程序有权作为非 root 用户执行。它还能够作为非 root 用户修改 /etc/security/passwd 文件。DAC 不允许这么做。

passwd 命令等 setuid 程序
$ ls -l 'which passwd'
-r-sr-xr-x    1 root     security      40014 May 07 2008  /usr/bin/passwd

# ls -l /etc/security/passwd
-rw-------    1 root     security        467 Mar 10 23:48 /etc/security/passwd

这会导致严重的风险,任何人只要通过恶意的 setuid 程序控制了 root shell,就能够做任何事。

在 AIX 第 6 版之前, root 用户的部分权力可以分配给非 root 用户。不同的 root 用户任务(命令)具有不同的授权。这些授权分组为角色并分配给不同的用户:

  • 任务 -> 授权
  • 授权 -> 角色
  • 角色 -> 用户

但是,root 用户仍然是惟一的最高权威。能够访问 root 用户的人可以做任何事。

从 AIX 第 6 版开始,改进了基于角色的访问机制。

  • 可以禁用 root 访问。
  • root 任务分配给系统定义的三个用户。
  • 根据用户的责任分配特权、授权和角色。

这样就消除了通过单一路径破坏系统的可能性。


授权、角色和特权的工作方式。

  • 授权分配给命令。
  • 角色分配给用户。
  • 特权与特定的进程相关联。
  • 为了执行命令,需要把显式的特权分配给命令,通过授权控制它们的执行。

系统给某些命令预先分配了授权,给系统定义的用户分配了角色。

另外,管理员用户可以给可执行程序提供(用户定义的)授权并把授权分配给角色。每个用户都被分配一个角色。

因此,具有已定义角色的用户应该能够执行任何授权的命令。

shutdown 命令
命令: Shutdown
授权: aix.system.boot.shutdown 
角色: isso, so
特权: Root privileges

具有信息系统安全官(ISSO)或相似角色的用户能够执行关机吗?

是的。这个用户的角色允许执行关机。通过前面的示例可以看出,只有具有这些角色、授权和特权的用户能够执行关机。

恶意用户是否可能获得 ISSO 角色并使用自己的 shutdown 程序攻击系统?

不可能。因为这里的恶意用户是一个恶意管理员,他不具有做所有事的完整授权。另外,使用标签 (MLS) 在系统级执行另一级检查以改善安全性,这会检查其他一些特权。

这里要理解的要点是,具有管理员授权的用户只能分配授权和角色。控制管理员用户的恶意用户无法做任何事,因为单靠管理员无法做任何破坏性的事。

只允许特定的用户执行特定的操作。单一 root 用户的责任被分配给多个用户。这样就提高了安全性。

在授权层次结构中,系统定义的授权以 aix 开头(见前面的示例,这些授权可能不能修改或删除)。


root 用户有什么变化?

谁替代 root 用户的角色?

可以禁用对系统的 root 访问并通过一个或多个用户账号执行所有任务。

AIX V6 有三个预定义的角色,它们分配给三个预定义的用户:

  • ISSO,信息系统安全官(Information System Security Officer)
  • SO,系统操作员(System Operator)
  • SA,安全管理员(Security Administrator)

下表定义这些用户的角色和授权:

表 1. 预定义用户的预定义角色
用户角色责任
ISSOISSO
  • 建立和维护安全策略
  • 为用户设置密码
  • 网络配置
  • 设备配置
SOSO
  • 系统关机和重新引导
  • 文件系统备份、恢复和限额
  • 系统错误日志记录、跟踪和统计
  • 工作负载管理
SASA
  • 用户管理,不包括密码
  • 文件系统管理
  • 软件安装和更新
  • 网络守护进程管理和设备分配

命令和示例

下表给出一些命令的详细信息,帮助您了解如何使用授权和角色。

表 2. 命令的详细信息
任务命令
创建授权mkauth (auth_name) 或 smitty rbac-> Authorizations-> Add an Authorization ->Authorization Name
检验授权lsauth
把命令与授权关联起来 setsecattr -c accessauths= (auth_name) (command)
创建角色mkrole authorizations= (auth_name) (role name)
把角色与用户关联起来chuser roles=(role_name) (user name)

使用 setkst 更新内核表

与激活角色相关的操作rolelist -a [检查与登录会话的用户相关联的角色]

swrole (role_name) [切换以激活角色]

rolelist -e [检查会话中哪个角色是激活的]

请通过以下示例了解这些命令:

如何作为 testuser 执行 shutdown 命令
步骤 A:创建和分配(用户定义的)授权和角色:
	mkauth test_auth
	setsecattr -c accessauths=test_auth shutdown
	mkrole authorizations=test_auth test_role
	chuser roles=test_role testuser
	setkst

步骤 B:执行

	作为 testuser 登录
	使用以下命令切换到 test_role 角色:
	swrole test
	(提示输入 testuser 的密码)
	使用以下命令检查 testuser 是否有角色:
	rolelist -e
	这显示相关联的角色是 test_role
	执行 shutdown 命令

到目前为止,已经讲解了如何使用授权和角色。前面的示例解释如何给非 root 用户分配执行 shutdown 等命令的授权。这个示例只是为了解释 RBAC 的使用方法。并不建议把执行 shutdown 等命令的权力分配给非 root 用户。下面的示例说明创建用户和设置用户的密码不是单一用户的责任。需要使用多个角色(用户)创建用户和设置用户的密码。

如何创建用户并修改和设置用户密码
1.	作为 isso 登录
2.	swrole isso
3.	mkuser (user_name)
4.	作为 so 登录
5.	swrole so
6.	passwd (user_name)

这说明如何分配角色和授权,以及在没有正确授权的情况下很难篡改活动。

如何挂载文件系统
1.	作为 isso 登录
	a.	swrole isso
2.	挂载文件系统
	a.	mount: Write permission is required to mount over /mnt.  - FAILS
3.	作为 so 登录
	a.	swrole so
	b.	挂载文件系统
	c.	用 df 命令检查挂载。    - SUCCEEDS

这样就把 root 用户的责任分配给了其他用户,降低了安全风险。

总之,可以把授权分配给可执行命令。把角色分配给用户,具有已定义角色的用户应该能够执行命令。在 RBAC 授权的基础上,检查 DAC 权限。要想绕开 DAC,需要特权。


特权

到目前为止,您已经了解了授权和角色如何增强系统的安全性。现在,看看特权在这个安全系统中的作用。

  • 进程满足授权之后,还需要特权才能执行命令。
  • 即使命令和进程有必需的授权,它们仍需特权才能访问文件。
  • 特权提供设备访问控制。

简单地说,在执行系统调用等特权操作之前,操作系统使用授权判断是否符合条件,


特权的示例

lsconf 示例
lsconf 不是特权命令,它没有执行特权操作所需的授权。
按照 DAC 确定访问权限。 

它具有以下 DAC 权限:

# ls -l 'which lsconf'
-r-xr-xr-x    2 root     system        12712 Mar 14 2008  /usr/sbin/lsconf

具有 DAC 特权的任何人都可以执行 lsconf。有意思的是,lsconf 命令在内部执行 bootinfo 等命令,而 bootinfo 命令是一个特权命令。这意味着用户需要授权和特权才能执行 bootinfo。因此,没有所需授权的用户无法执行 bootinfo。

bootinfo 示例
命令:  bootinfo -k   
授权和特权:
$ lssecattr -c 'which bootinfo'
/usr/sbin/bootinfo accessauths=aix.system.boot.info innateprivs=PV_DAC_R,
PV_DAC_W,PV_DEV_CONFIG,PV_KER_RAS,PV_MAC_,PV_MIC secflags=FSF_EPS
DAC 权限:
$ ls -l 'which bootinfo'
-r-xr-x---    1 bin      bin           13984 Mar 14 2008  /usr/sbin/bootinfo

在这里,通过一个角色把授权 aix.system.bootinfo 分配给用户,这个用户应该能够执行 bootinfo 命令。但是,DAC 不允许任何非 root 用户执行这个文件。

具有所需授权但没有 DAC 权限的用户有可能执行命令吗?

是的,如果进程有执行命令所需的特权,就可能出现这种情况。在这个示例中,如前面的输出所示,bootinfo 具有 PV_DAC* 特权。

下面的命令显示与 shell 相关联的特权:

$ lssecattr -p $$
282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=
编辑 /etc/hosts 文件
$ lssecattr -f /etc/hosts
"/etc/hosts" does not exist in the privileged file database.

这不是特权文件。
因此,具有 DAC 访问权的用户应该能够编辑这个文件。

$ ls -l /etc/hosts
-rw-rw-r--    1 root     system         1962 Mar  3 16:35 /etc/hosts

DAC 说明,除了 root 用户和属于 system 组的用户之外,其他用户对此文件没有写访问权。

$ lssecattr -p $$
282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=

因此,在这里按照 DAC 访问权处理,只允许非 root 用户有 READ 权限。

编辑 /etc/environment 文件
$ lssecattr -f /etc/environment
/etc/environment writeauths=aix.security.user

这是特权文件。
$ ls -l /etc/environment
-r--r--r--    1 root     system         1907 Mar 12 22:45 /etc/environment
DAC 访问权限说明没有用户具有 WRITE 权限。 

$ lssecattr -p $$
282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=

shell 进程具有 root 特权,但是用来访问这个文件的 vi 命令不是特权命令。
这意味着,即使用户有编辑这个文件所需的授权,aix.security.user,vi 也无法访问文件。

$ lssecattr -c 'which vi'
/usr/bin/vi does not exist in the privileged command database.

编辑 /etc/environment 文件需要什么?
(i)   用户有所需的授权 aix.security.user
(ii)	正在执行的 shell 有所需的特权
(iii)	访问此文件的命令有所需的特权

对于这种情况,AIX 提供 vi 编辑器的特权版本 pvi,它具有读写此文件的特权。 

$ lssecattr -c 'which pvi'
/usr/bin/pvi accessauths=ALLOW_ALL innateprivs=PV_PROC_PRIV,PV_DAC_R,PV_DAC_W,
PV_DAC_X,PV_DAC_O
  • 特权命令具有以下属性:
    accessauths、innateprivs、authprivs、inheritprivs
  • 特权文件具有以下属性:
    readauths 和 writeauths
  • 特权设备具有以下属性:
    readprivs 和 writeprivs

结束语

本文通过示例和场景解释了 RBAC 特性。我希望本文能够帮助您更好地了解 AIX 高级特性 RBAC 和 MLS。

表 3. RBAC 经验规则
-DAC授权角色特权说明
文件,命令,设备YESNONONO按照 DAC 权限。
文件,命令,设备YESYESYESNO按照 DAC 权限。
文件,命令,设备YESYESYESYES有授权的用户优先执行特权操作。绕过 DAC。
  • 分配单一用户责任。
  • 单一用户无法破坏系统。
  • 可以禁用 root 访问权。

如果需要进一步帮助,请与 IBM® 技术支持联系。如果对这个主题有任何不明之处,请与作者联系。

参考资料

学习

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=AIX and UNIX
ArticleID=417921
ArticleTitle=了解 AIX 高级特性: 简便的基于角色的访问控制
publish-date=08032009