等保2.0测评:CentOS访问控制

一、说明

权限控制在等保测评里仅仅说了要求，但是怎么落地却基本没写，所以，我觉得还是有必要了解一下centos系统大概有什么方法可以实现对用户的权限控制，不至于测评的时候完全不知道怎么测。

这里我把我现在知道的关于权限控制的方法都列举出来，供大家参考参考。

另外，我使用的是centos6。

二、查看

无论针对什么权限，以下三个文件至少需要查看的：

/etc/passwd
/etc/shadwo
/etc/group

通过这三个文件可以知道可登录的普通账户有哪些，以及用户组的情况，毕竟要判断用户的权限，至少应该知道用户的情况吧。

2.1. passwd

通过passwd文件，首先判断出哪些是普通用户、系统用户和超级用户（root）系统用户的uid在centos6中是大于0小于500的，500这个值的设置应该是在login.defs文件中。

然后判断出哪些用户不能登录，比如最后是/sbin/nologin以及/bin/false就不可登录。

2.2. shadow

通过shadow判断出哪些用户已经被不登录了。

2.2.1. 锁定或密码不可用

这里可以用passwd命令进行判断：

[root@centos01 ~]# passwd -S cx
cx PS 2019-03-26 0 9999 7 99 (密码已设置，使用 SHA512 加密。)

里面的PS意思就是密码已设置。

然后shadow中可能的情况有（每一段的第一句是shadow中实际的行，第二句是用passwd -S username 查询出来的值）：

games:*:15980:0:99999:7:::
games LK 2013-10-02 0 99999 7 -1 (更改当前使用的认证方案。)

cx:*:17970:0:99999:7:::
cx LK 2019-03-15 0 99999 7 -1 (更改当前使用的认证方案。)

dbus:!!:17966::::::
dbus LK 2019-03-11 0 99999 7 -1 (密码已被锁定。)

cx:!:17970:0:99999:7:::
cx LK 2019-03-15 0 99999 7 -1 (密码已被锁定。)

cx::17970:0:99999:7:::
cx NP 2019-03-15 0 99999 7 -1 (密码为空。)

上面除了最后一段也就是空密码是可以登录外，其余的都不可以。

密码字符串开头，也就是第一个:的右边加上!或!!字符串，无论!或!!字符串的后面有或没有密码字符串（这里没有，都是空密码），都代表被锁定。

至于(更改当前使用的认证方案。)，也是不能登录，这里的意思应该是因为密码字符串也是按照一定的格式存储的，比如告诉了系统用了哪种加密算法。

这样系统才知道当你输入密码后，要怎么对你输入的字符串进行加密，然后才能能拿来和shadow中的加密字符串进行对比。

你随便乱填的话，系统就认不出来了，也没法进行对比然后让你登录了。

比如你随便在密码字符串那输入一些字符串，其结果会显示为(更改当前使用的认证方案。)：

cx:djfhjdhfs:17970:0:99999:7:::
cx LK 2019-03-15 0 99999 7 -1 (更改当前使用的认证方案。)

2.2.2. 密码已经过期且已过宽恕期

如果设置了密码最长使用时间，且宽恕期也设置了，那么当密码过期，且宽恕期也过去了的话。

则该账号也无法登录，只有等具有权限的用户比如root来修改shadow文件了。

注意：如果仅仅是密码过期，则该账号仍然可登录，只要登录的时候修改密码即可。

虽然可以直接从shadow文件中进行判断，但是那个格式太不友好了，可以用chage命令：

[root@centos01 ~]# chage -l cx
Last password change : Jun 28, 2019
Password expires : never
Password inactive : never
Account expires : Jan 20, 11761191
Minimum number of days between password change : 0
Maximum number of days between password change : 99999
Number of days of warning before password expires : 7

密码过期时间和宽恕时间都可以看到。

2.2.3. 账号已过期

账号过期的话也没法登录，也可以直接从shadow文件中进行判断，但还是用chage命令看比较好：

[root@centos01 ~]# chage -l cx
Last password change : Jun 28, 2019
Password expires : never
Password inactive : never
Account expires : Jan 20, 11761191
Minimum number of days between password change : 0
Maximum number of days between password change : 99999
Number of days of warning before password expires : 7

其中的Account expires就是账号过期时间，注意，这个和密码过期后又过了宽恕期后不能登录，不是一回事，虽然都不能登录。

2.3. group

cx:x:500:cx,cv
cv:x:501:

这个很简单，唯一需要说的就是，最后一个:的右边，即为把这个组当成附加组的用户的用户名，可以有很多个，用,隔开。

所以cx:x:500:cx,cv的意思就是cx、cv用户的附加组中有cx组。

那把cx组当成基本组的用户是哪个呢？这里一般默认来说就是和cx组同名的用户，但是用户的基本组是可以改的，比如可以设置cx的基本组是cv组，而实际上从group文件中并不能确认用户的基本组到底是哪一个用户组，因为这文件里没有这样的信息。

所以最确切的方法是看passwd里的：

cx:x:500:500:cx:/home/cx:/bin/bash

这里cx用户的基本组的id是500，所以cx用户的基本组也是cx组。

所以cx组是cx用户的基本组，也同时是cx用户的附加组。

其实这里可以直接用命令查看：

[root@centos01 ~]# id cx
uid=500(cx) gid=500(cx) 组=500(cx)

这里就表明了，cx的基本组的id是500，同时cx的所在的组（包括附加组和基本组）有id为500这个组，因为附加组和基本组是同一个组，所以不会重复排列。

而cv用户，就很简单了：

[root@centos01 ~]# id cv
uid=501(cv) gid=501(cv) 组=501(cv),500(cx)

cv的基本组是cv组，附加组是cx组。

那么cv的基本组cv组是不是也是cv的附加组呢？答案为不是，因为在group文件里最后一个:的右边，并没有cv（用户名）。

三、目录和文件权限

这个其实没啥好说的，目录和文件的创建者、所属组、其他用户的rwx属性，代表某用户是否具有读、写、执行权限。

所以通过对目录和文件进行设置，就能控制用户的对目录和文件的行为。

比如oracle数据库安装时，你用哪个用户去启动安装脚本，oracle的数据库目录的owner就会是这个用户（但root用户不能执行这个安装脚本）。

所以该用户才能够启动数据库，然后对数据库文件进行读和写。当然这里并不是直接用cat等命令读或者其他命令进行写，而是在sqlplus中用执行sql语句，但本质上，还是要拥有读写权限才可以的。

3.1. 文件

如果对文件具有读r权限， 就代表可以使用cat、head、tail等命令查看文件内容。

如果对文件具有写w权限，就代表可以使用vim等命令修改文件内容，这里稍微注意下，可以修改文件内容不代表你能够直接删除文件，因为这需要具有上级目录的权限。

如果对文件具有执行x权限，就代表可以执行该文件，当然，这需要这个文件是可执行文件比如脚本才行（对于目录执行权限也具有意义）。

3.2. 目录

目录的权限有点点复杂，原理嘛，大家去网上搜一搜“linux目录的x权限”就知道了，网上说得非常详细，我这里只说结果。

如果对目录具有读r权限，看上去应该是可以使用ls命令查看目录下文件的信息（名字、大小、权限等），但实际上如果只具有读权限，那么你用ls命令能看到的信息就只有目录下的文件名，目录下文件的其余信息看不到。你必须同时具有执行x权限，才可以正常查看目录下文件的信息。

如果对目录具有写w权限，看上去你就可以用rm等命令操作目录下的文件，但实际上如果只具有写权限，那么你用rm是删除不了目录下的文件的，你也必须同时具有执行x权限才能删除目下的文件。

如果对目录具有执行x权限，你就可以用cd命令进入目录，然后读取或写入目录下的文件（如果你对该文件具有相应的权限的话）。

所以，对于目录的纯读权限和纯写权限几乎没有任何意义。

3.3. umask

3.3.1. 说明

文件和目录创建出来就具有一个默认的权限，通过umask就可以设置默认的权限到底是多少，所以这个肯定也算是访问控制的一种。

首先，如果用户创建的是目录，则默认所有权限都开放，为777，也就是：rwxrwxrwx，至于文件，则是rw-rw-rw- 。

然后umask的作用就是从默认权限里拿掉一些权限，最后的结果就是实际的权限了。

查看umask的值：

[root@centos01 ~]# umask
0022

第一位0和网上说和SUID，SGID和SBIT这三特殊权限有关，SUID 对应4，SGID对应2，sticky 粘位对应1，不过我还没实验过，先不管它。

后面三位就代表着从owner、group、other那拿掉什么权限：

新建文件：666-022=644；
新建目录：777-022=755.

注意，这里是拿掉权限，而不是直接做减法。

想象一下，如果umask的值是0111（拿掉owner、group、other的执行权限），那么对于文件而言其实没有拿掉任何权限。

因为文件默认为666，本来就没有执行权，所以执行umask后还是666，而不是变成666-111=555（执行+阅读）

3.3.2. 配置文件

而umask主要应该在etc/profile和etc/bashrc文件中进行配置，他们的默认值都一样：

if ($uid > 199 && "`id -gn`" == "`id -un`") then
    umask 002
else
    umask 022
endif

如果uid大于199，且用户名等于基本组的组名则为002，否则就是022，区别就是group的w权限有没有被拿走。etc/profile在每次登录的时执行，etc/bashrc是在登录后调用bash shell时执行。所以，一般来说，etc/bashrc中的umask语句会覆盖etc/profile中的。

另外，如果你用的不是bash shell，比如修改了/etc/passwd里的值，让用户使用csh shell，那么在执行etc/profile后接着执行的就应该是csh.cshrc。

另外，在/etc/login.defs里有这么一段：

#The permission mask is initialized to this value. If not specified, 
#the permission mask will be initialized to 022.
UMASK           077

其实这个是针对用户的home目录的，当设置CREATE_HOME为yes的时候 ，创建用户时就会自动创建用户的home目录，这里就是专门对home目录设置的umask。

四、进程权限

4.1. 说明

进程启动后，肯定是被某个用户所启动的，或者是以某用户的身份所启动的，那么进程所具有的权限（比如该进程能否读写某文件），也是由这个用户决定的。

网上资料如下（具体可看：https://blog.csdn.net/bluemickey/article/details/22940873）：

大概意思就是说，调用进程时进程会涉及到这些id，而进程是否能够对文件和目录进行操作，则是由有效用户Id、有效组Id以及附加组Id去判断的。

正常情况下，有效用户Id、有效组Id就等于实际用户Id和实际组Id。

4.2. SUID、SGID

但如果对该执行文件设置了SUID，又如果该用户和该执行文件的owner都具有这个执行文件的x权限，则这个用户在运行这个执行文件时，产生的进程的有效用户ID是该执行文件的Owner Id。

而类似的还有SGID，也具有和SUID一样的功能，不过是针对可执行文件的Group Id（GUID还有其他的作用，这里就不说了）。

一般都会用passwd命令来进行说明，passwd命令设置了SUID，如下（rws中的s）：

-rwsr-xr-x 1 root root 47032 Jul 16  2015 /usr/bin/passwd

故而其他非root用户可以用passwd命令修改自己的密码，因为进程的有效用户id变成了root的id，所以才能修改shadow文件：

-rw-r----- 1 root shadow 1292 Aug 25 16:56 /etc/shadow

但是，有一个问题，网上没怎么说，既然非root用户都可以调用passwd命令去修改shadow文件，为啥还是只能修改自己的密码呢？其他用户的密码为啥还是修改不了？

4.3. 代码的判断

所以这里实际上是passwd内部进行了判断，源代码如下（c语言）：

/* Only root gets to specify a user name. */
        username = NULL;
        if ((extraArgs != NULL) && (extraArgs[0] != NULL)) {
                if (getuid() != 0) {
                        /* The invoking user was not root. */
                        audit_log_acct_message(audit_fd, AUDIT_USER_CHAUTHTOK,
                                NULL, "password change", extraArgs[0],
                                getuid(), NULL, NULL, NULL, 0);
                        fprintf(stderr,
                                _("%s: Only root can specify a user name.\n"),
                                progname);
                        exit(-3);
                } else {
                        /* The invoking user was root. */
                        username = extraArgs[0];
                        /* Sanity-check the user name */
                        if (strlen(username) > MAX_USERNAMESIZE) {
                                fprintf(stderr,
                                        _("%s: The user name supplied is too long.\n"),
                                        progname);
                                exit(-3);
                        }
                }
 
                /* If there is more than one unrecognized argument, we suddenly
                 * get confused. */
                if (extraArgs[1] != NULL) {
                        fprintf(stderr,
                                _("%s: Only one user name may be specified.\n"),
                                progname);
                        exit(-3);
                }
        }

意思很简单，判断passwd后是否带有参数，如果带有参数就判断getuid()的值是否等于0，不等于0它就不是root用户，不是root用户就别想修改别人的密码了，该干嘛干嘛去……

这里的getuid()的返回值是实际用户id，所以非root用户到这就“原形毕露”了。

相对应的，也存在一个geteuid()函数，它的返回值就是有效用户id。

所以如果一个用户对一个可执行文件有x权限，不代表就万事大吉了。

第一：你可以运行这个可执行文件，但是这个进程可能会涉及到的对其他文件的操作（读、写、执行等）不一定具备足够的权限。

第二： 可能在代码里又对你进行了限制，比如iptables这个文件

-rwxr-xr-x. 1 root root 10688 11月 23 2013 /etc/init.d/iptables

other拥有x权限，但是一个非root用户传入status参数想查看iptables的状态时，却不会有反应。

那是因为iptables在一开头就进行了判断：

#only usable for root
[ $EUID = 0 ] || exit 4

4.4. root的权限

root拥有最高权限，但是这不是一句空话，它表现为在linux里root确实可以对任何文件、目录做几乎任何事情，而实现的机制是因为linux的代码是这样规定的。

但是如果我自己写一个脚本，里面的代码逻辑是如果uid不为0才能往下执行，root的“最高权限”就没了吧？（当然root直接修改脚本那另说）。

类似的比如oracle的安装过程中，如果你用root账号去执行安装脚本，就会是这样：

这估计也是在脚本里写的一个逻辑判断。

五、 更精细化的文件权限控制

一般的，对目录和文件，可以实现创建者、所属组、其他用户这三类用户（UGO）的访问权限设置(r、w、x)。而setfacl命令，则可以更为精确的在这三类用户之外对权限进行分配，叫做ACL权限设置。比如：让某一个用户对某一个文件具有某个权限。

与setfacl相对的，可以用getfacl查看设置好的ACL权限。

5.1. ACL

比如用getfacl命令来查看一个定义好了的ACL文件：

[root@localhost ~]# getfacl ./test.txt
#file: test.txt
#owner: root
#group: admin
user::rw-
user:john:rw-
group::rw-
group:dev:r--
mask::rw-
other::r--

类型

说明

这里稍微说明下，mask::rw-代表着这个文件的最大权限，在ACL中定义的用户、组的权限实际都不是真实权限，真实的权限是要跟mask的权限相与之后产生的权限。

如这个例子，mask的值为rw，所以定义的ACL的权限中，假如john的权限设置为rwx，那么那么它的最终权限就是与mask相与之后的结果，也就是rw。（当然，对于txt文件而言，执行权限没有啥意义）。

注：Mask只对其他用户和组的权限有影响，对owner和other的权限是没有任何影响的。

5.2. ACL与UGO

UGO也就是我们常用的文件权限模式，比如：-rwxr-xr-x. 1 root root 10688 11月 23 2013 /etc/init.d/iptables

而当你对某文件设置了ACL之后，再用ls命令查看UGO，就会发现多出一个+号：

[root@localhost ~]# ls -l
-rwxrwxr--+ 1 root admin 0 Jul 3 23:10 test.sh

并且其中原来代表group权限的权限位，被mask所替代，也就是说rwxrwxr--中的rwx不再代表group的权限，而是代表mask，用getfacl 查看如下：

[root@localhost ~]# getfacl --omit-header ./test.sh 
user::rwx user:john:rwx 
group::rw- 
mask::rwx
other::r--

可以得知，group的实际权限是rw-。

5.3. 更多内容

实际上setfacl和getfacl相关的内容很多，我这里只是摘抄了一部分比较基础的，想要详细了解的可以点击：https://www.cnblogs.com/MLibra/p/6240209.html
我这里就不继续摘抄了。

六、chroot命令

linux的目录结构如下：

通过chroot命令可以将根目录设置为指定的位置，而根目录之上的位置将不可再访问，则这样就实现了一定的访问控制。

具体内容，大家可以看一看：https://www.ibm.com/developerworks/cn/linux/l-cn-chroot/

七、sudo命令

sudo命令可以允许用户以另外的某个用户的身份执行某些命令，它的配置文件为/etc/sudoers。

比如在sudoers文件中这样配置：

7.1. 常见形式

beinan ALL=(root) /bin/chown, /bin/chmod

表示的是beinan用户可以在任何可能出现的主机名的主机中，可以切换到root下执行 /bin/chown ，可以切换到任何用户招执行/bin/chmod 命令，但切换的时候都需要输入beinan自己的密码。

如果是这样：

beinan ALL=(root) NOPASSWD: /bin/chown,/bin/chmod

则beinan用户在任何可能出现的主机名的主机中，都可以切换到root下去执行/bin/chown命令，而且还不需要输入beinan用户自己的密码。（但执行chmod时还是需要beinan输入自己的密码）

所以在等号右边是一种这样的格式：

授权用户 主机=[(切换到哪些用户或用户组)] [是否需要密码验证] 命令1,[(切换到哪些用户或用户组)] [是否需要密码验证] [命令2],[(切换到哪些用户或用户组)] [是否需要密码验证] [命令3]......

[(切换到哪些用户或用户组)]：如果不写，则默认为切换到root用户。如果是ALL ，则代表能切换到所有用户。与此相对应的，sudo命令有一个-u参数，以指定的用户作为新的身份。若不加上此参数，则预设以root作为新的身份。

[是否需要密码验证]：如果不写，则默认为要输入自己的密码。如果是NOPASSWD:，则代表不需要输入自己的密码。

%beinan ALL=/usr/sbin/*,/sbin/*

这里加%号代表用户组，%和用户组名之间不能有空格。而/usr/sbin/*中最后的符号代表通配符，表示sbin目录下的的所有命令。

而且对于命令，还可以指定参数，比如：

beinan ALL=/bin/more /etc/shadow

对于beinan用户，在这里只能用more命令查看/etc/shadow文件。

所以从上面的几个例子可以看到，sudo权限的控制粒度可以达到非常细的地步。

7.2. 别名

可以对用户、用户组、命令等设置别名（组），需要使用时直接引用这个别名（组）即可：

User_Alias SYSADER=beinan,linuxsir,%beinan
User_Alias DISKADER=lanhaitun
Runas_Alias OP=root
Cmnd_Alias SYDCMD=/bin/chown,/bin/chmod,/usr/sbin/adduser,/usr/bin/passwd [A-Za-z]*,!/usr/bin/passwd root
Cmnd_Alias DSKCMD=/sbin/parted,/sbin/fdisk 注：定义命令别名DSKCMD，下有成员parted和fdisk ；
SYSADER ALL= SYDCMD,DSKCMD
DISKADER ALL=(OP) DSKCMD

第一行：定义用户别名SYSADER 下有成员 beinan、linuxsir和beinan用户组下的成员，用户组前面必须加%号；

第二行：定义用户别名 DISKADER ，成员有lanhaitun

第三行：定义Runas用户，也就是目标用户的别名为OP，下有成员root

第四行：定义SYSCMD命令别名，成员之间用,号分隔，最后的!/usr/bin/passwd root 表示不能通过passwd 来更改root密码；

第五行：定义命令别名DSKCMD，下有成员parted和fdisk ；

第六行：表示授权SYSADER下的所有成员，在所有可能存在的主机名的主机下运行或禁止运行SYDCMD和DSKCMD下定义的命令（这里的禁止是指SYDCMD定义里的!符号）。更为明确的说， beinan、linuxsir和beinan用户组下的成员能以root身份运行 chown 、chmod 、adduser、passwd，但不能更改root的密码；也可以以root身份运行 parted和fdisk ，本条规则的等价规则是：beinan,linuxsir,%beinan ALL=/bin/chown,/bin/chmod,/usr/sbin/adduser,/usr/bin/passwd [A-Za-z]*,!/usr/bin/passwd root,/sbin/parted,/sbin/fdisk

第七行：表示授权DISKADER 下的所有成员，能以OP的身份，来运行 DSKCMD（所以op才是runas用户，目标用户？） ，不需要密码；更为明确的说 lanhaitun 能以root身份运行 parted和fdisk 命令；其等价规则是：lanhaitun ALL=(root) /sbin/parted,/sbin/fdisk

7.3. 注意

对于某些命令，是不能够给与用户执行权限的，否则就是给与全部权限了。

/bin/bash，如果给与了用户以root身份执行该命令的权限，用户就可以用sudo -s或sudo -i登录任何一个用户。

su命令，如果给与了用户以root身份执行该命令的权限，用户可以切换到任何一个账户。

PS：更多内容请上网搜索。

八、su命令

通过su命令可以从现有账户切换到其他账户，除了root，切换到其它账户都需要目标账户的密码。

所以，从表面上看来su命令起不到什么访问控制的作用，毕竟要切换到目标账户需要知道对方的密码，那还不如直接用目标账户来登录。

但是实际上，它还是存在一些访问控制的功能的。

在/etc/pam.d/su文件中，有如下内容：

auth sufficient pam_rootok.so
#Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
#Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth include system-auth
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session optional pam_xauth.so

其中的#auth required pam_wheel.so use_uid，如果取消注释，则代表所有位于wheel用户组的用户，都失去了su命令的使用权限，无法再通过su命令切换到其他账户上，这里的wheel用户组为系统自创的一个用户组。

另外，其中的#auth sufficient pam_wheel.so trust use_uid，如果取消注释，则代表wheel组的用户为可信任的，wheel组的用户切换到其他账户不需要输入目标账户的口令，就像root一样。

如果想使用自定义的用户组，那么使用以下配置语句即可：

auth required pam_wheel.so use_uid group=myadmingroup

九、环境变量

环境变量也算是访问控制的一种，我们常见的比如安装oracle数据库时，需要指定一个账户进行安装，一般将这个账户命名为oracle。
这个账户就在~/.bash_profile文件中定义了某些环境变量：

[oracle@centos01 ~]$ cat ~/.bash_profile
#.bash_profile
#Get the aliases and functions
if [ -f ~/.bashrc ]; then
  . ~/.bashrc
fi
#User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH
export ORACLE_BASE=/oracle
export ORACLE_HOME=/oracle/app
export ORACLE_SID=oracleSI
export PATH=$ORACLE_HOME/bin:$PATH

这样一来，由于启动监听和oracle数据库的脚本里会用到其中定义的环境变量。

所以哪怕是root，没有配置环境变量，也没法启动启动监听和oracle数据库，因为相关脚本里需要使用的环境变量root账户没有进行定义。

这样，也就起到了一定的访问控制的功能。