使用 SELinux 安全上下文 / ACL 修改文件

Question

好的，所以我有一堆我写的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迁移

Answer 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 设置为 permissive 使用 # 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例如下面没有被列入其中，为布尔discriptions更方便的工具是semanage的布尔-l

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

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

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

在这种情况下，使用#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

这里user_home_t是 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这样您就可以通过输入# system-config-selinux. 通过使用“脚本”过滤，我发现许多脚本使用 bin_t 作为它们的上下文。您还可以使用它更改强制模式。我的主目录中的脚本可以愉快地执行，user_home_t但如果您遇到这些麻烦，我怀疑您在其他地方。