![设置特定的安全安排](https://linux22.com/image/228639/%E8%AE%BE%E7%BD%AE%E7%89%B9%E5%AE%9A%E7%9A%84%E5%AE%89%E5%85%A8%E5%AE%89%E6%8E%92.png)
我需要在 Oracle 8 系统上设置特定的安全安排。
将会有一些用户被添加到 unix 组中。
这些用户不应是 sudoers/wheel 组中的用户,该组也不应授予管理员权限。
由于属于该组,这些用户应该能够执行但不能更改某些脚本。
当这些用户执行时,这些脚本将需要能够读取和修改某些文件,但是,用户不应该通过任何其他方式访问(甚至不能读取)这些文件。
如何设置 unix 文件权限/文件夹结构/组成员身份才能使这种安排生效?
答案1
用户可以轻松地添加到新组中。脚本(与可执行文件不同)无法通过 setgid/setuid 权限分配权限,因此组需要文件中的一个条目,sudoers
以便在用户运行选定的脚本集时向其授予权限。 (该特权不需要 - 实际上也不应该 - 是root
访问权限。)
初始点。我们将该组称为ops
,我们将拥有用户alice
和bob
。他们应该能够/opt/scripts
以 user 身份执行脚本privops
,我们也需要创建该脚本。您可能更喜欢对用户和组使用相同的名称,但我在这里将它们分开以明确哪个是哪个。
首先创建目标用户、成员资格组并向其中添加用户:
useradd privops
groupadd ops
usermod -a -G ops alice
usermod -a -G ops bob
现在使用visudo
向文件添加新行sudoers
(或者更好的是,创建您自己的文件visudo /etc/sudoers.d/ops
):
%ops ALL=(privops) NOPASSWD: /opt/scripts/*
此时,Alice 和 Bob 可以以用户身份sudo
从该目录执行脚本。确保目录的脚本只能由组成员执行:/opt/scripts
privops
ops
chown root:ops /opt/scripts/*
chmod ug=rx,o= /opt/scripts/*
您应该确保受限访问文件由该用户帐户拥有privops
并且只能由该用户帐户读取/写入:
chown privops:ops /opt/privdata/*
chmod u=rw,go= /opt/privdata/*
用法示例(第一遍):
# As alice
sudo -u privops /opt/scripts/myscript arg1 arg2…
如果您想提高脚本的可用性,请让他们调用自己(sudo
如果他们还不是目标用户)。
#!/bin/sh
if [ "$(id -nu)" != 'privops' ]
then
exec sudo -u privops "$0" "$@"
exit 1
fi
# original code continues from here…
然后,爱丽丝和鲍勃可以使用这样的命令,甚至可以将它们添加到他们的$PATH
/opt/scripts/myscript arg1 arg2…
# Or
export PATH="$PATH:/opt/scripts"
myscript arg1 arg2…
因为您要向脚本添加权限,以/opt/scripts
确保它们编写得特别仔细,而调用者没有机会突破。由于您似乎不熟悉这种类型的解决方案,您可能需要寻求专业建议。
答案2
考虑以不同的方式来做这件事。与其允许用户运行具有提升权限的脚本,不如允许这些用户执行更有限的操作,并使用单独的进程监视该操作和响应。
实现此目的的一种方法是设置一个/opt/commands
目录,该目录可由给定特权组中的用户写入(可能是限制删除标志,防止人们删除属于他人的文件。
然后,以专用用户身份运行的单独进程将在那里查找新文件(使用 inotify,或者只是每 10 分钟运行一次进行检查,或者其他方式)。如果新文件与仔细定义的特殊名称列表,运行相应的脚本来修改隐藏文件。 “命令”文件甚至可以具有可用作输入的内容。您必须非常小心地“清理”此输入,并且不要以任何可能的方式使用它被处决— 但这是一个比尝试使受限制的 shell 脚本安全更容易的问题。 (不过,很容易搞砸!)
这种间接方法意味着用户实际上没有必要有读取和写入秘密文件的权限,但应该受到限制实际上这样做。
这是一种“系统管理员让它工作”的黑客方法。作为一名前系统管理员,我觉得这没什么可耻的。但是,与其使用基于文件系统的方法,你不妨考虑使用总线,即基本上就是为了这种情况而设计的。