☰

使用 SELinux 安全上下文/ACL 对文件进行 chmodding

tag-icon • tag-icon access-control permissions selinux administration root
使用 SELinux 安全上下文/ACL 对文件进行 chmodding

好的，我编写了一堆bash&python脚本，它们都放在一个大目录中。实际上，它们有单独的子目录，但它们都嵌套在这个主目录中。
因此，为了便于讨论，目录结构如下所示：

find . -type d
.
./scripts/sh
./scripts/sh/a
./scripts/sh/b
./scripts/sh/c
./scripts/py
./scripts/py/x
./scripts/py/y
./scripts/py/z

find无论如何，我尝试使用和一举使整个脚本集合可执行chmod：

find . -type f -exec chmod +x {} +

通常情况下，这就是我所要做的全部工作，但我注意到该+x位仍未设置。他们的所有权限仍然如下所示：

ls -l ./scripts/py/z
-rw-rw----.  1 root 1015  801 May  7 12:00 script_name.py

据说。.字符（权限标志后面）表示某种 SELinux 安全上下文，带有访问控制列表或类似内容。我检查了一下getfacl，不知道该找什么；第一个是目录，第二个是脚本文件之一：

getfacl -acp ./scripts/py/z &&
getfacl -acp ./scripts/py/z/*
user::rwx
group::rwx
other::--x

user::rw-
group::rw-
other::---

我尝试了以下setfacl选项，但无济于事：

setfacl --help | grep 'remove'
  -x, --remove=acl        remove entries from the ACL(s) of file(s)
  -X, --remove-file=file  read ACL entries to remove from file
  -b, --remove-all        remove all extended ACL entries
  -k, --remove-default    remove the default ACL

root因此，在用户权限不受尊重且sudo毫无用处的情况下，我不得不问；我该如何重新获得对自己文件的访问控制权？

迁移自security.stackexchange.com

答案1

ACL 和 SELinux 上下文完全不同。这里有一个很好的教程这里对于 CentOS

要查看 SELinux 是否确实阻止了您的访问，请使用sestatus

$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

Enforcing我的输出表明 SELinux 正在积极阻止脱离上下文的访问。

使用以下方法临时将 SELinux 设置为宽容# sudo setenforce Permissive

$ sudo setenforce Permissive
[sudo] password for trogdor: 
$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

宽容模式仍会提醒您 SELinux 上下文违规，但不会阻止它们。这是检查 SELinux 是否真的是问题所在的绝佳方法。如果是，并且现在一切正常，请使用 将 SELinux 重新设置为强制执行sudo setenforce Enforcing。（顺便说一句，使用 setenforce 对 SELinux 的更改不会在重启后生效）。

如果问题出在 SELinux 上，那么您必须找到脚本应有的正确上下文，或者也许可以使用布尔值进行简单修复。

如果您在主目录中，则只需设置 SELinux 布尔值即可。要查看布尔值，请参阅 CentOS 布尔值的描述这里但我注意到下面的 user_exec_content 示例未列出，用于布尔描述的更方便的工具是 semanage boolean -l

# getsebool -a | grep exec
...
user_exec_content --> off
...

#sudo semanage boolean -l
...
user_exec_content              (off  ,   off)  Allow user to exec content
...

第一个 off 显示其当前状态，即当前设置为关闭；下一个 off 显示默认状态，这意味着在重新启动或文件系统重新标记后它仍然处于关闭状态。

在这种情况下，使用#setsebool -P user_exec_content on -P 标志可以使布尔更改在重新启动后永久生效

如果是上下文问题，那很好，上下文更易于使用，因为它们更直观。对于 SELinux 布尔值的实际作用，似乎需要反复试验和积累经验，例如，不知道 user_exec_content 的实际作用。

使用带有 -Z 标志的 ls 来查看文件的上下文，例如 ls -alZ。

$ ls -alZ
-rwxrwxr-x. trogdor trogdor unconfined_u:object_r:user_home_t:s0 backup.sh

这里用户主页是 backup.sh 的上下文。假设您有另一个目录具有执行脚本的正确上下文，则可以使用以下命令将该上下文镜像到 ./scripts 目录中：

# chcon -R --reference /onethatworks ./scripts

要仔细检查是否进行了更改，请使用ls -alZ ./scripts

restorecon -Rv ./scripts

应重新标记文件系统，将所有文件和目录递归地重新标记到更新后的上下文。在本例中，它只执行脚本目录及其内容。

如果可行，则此处所做的更改将不会在重启后生效，您可以使用以下命令使更改永久生效。

# semanage fcontext -a -s system_u -t <context_that_worked> "./scripts(/.*)?

管理 SELinux 的另一种选择是安装，policycoreutils-gui这样您就可以通过输入 来访问 selinux 配置 gui # system-config-selinux。通过使用“脚本”进行过滤，我发现许多脚本使用 bin_t 作为其上下文。您还可以使用它更改强制模式。我的主目录中的脚本可以顺利执行，user_home_t但如果您遇到这些问题，我怀疑您在其他地方。

相关内容