我的 Ubuntu 用户帐户名称为“user-3121”,类型为“管理员”。还有一个名为“admin”的帐户,类型为“管理员”。我如何确定“admin”是否可以以我的身份登录或以其他方式查看我在“user-3121”中的文件?
我与其他用户讨论了这个问题,我们尝试修改/etc/sudoers
以保护我的文件:
Cmnd_Alias SHELLS = /bin/sh,/bin/bash,/bin/ksh, /usr/bin/x11/passwd
Cmnd_Alias SU = /usr/bin/su,/bin/su,/usr/bin/gksudo,/usr/bin/sudo,/usr/bin/su bash,/usr/bin/sudo /bin/bash,/usr/sbin/visudo
Cmnd_Alias PASS = /usr/bin/passwd root,/bin/* * root,/bin/* * sysadmin,/bin/* * /home/sysadmin,/usr/bin/passwd
Cmnd_Alias EDIT= /bin/* /etc/sudoers,/bin/* sudoers,/bin/* /etc/passwd,/bin/* passwd,/bin/* /etc/group,/bin/* group,/bin/* /etc/shadow,/bin/* shadow,/*/*/[a-z]* /etc/sudoers,/*/*/[a-z]* /etc/passwd,/*/*/[a-z]* /etc/group,/*/*/[a-z]* /etc/shadow,/*/*/[a-z]* sudoers,/*/*/[a-z]* passwd,/*/*/[a-z]* group,/*/*/[a-z]* shadow
Cmnd_Alias CMDS = /usr/sbin/userdel * sysadmin,/usr/sbin/userdel sysadmin,/usr/sbin/deluser * sysadmin,/usr/sbin/deluser sysadmin
root ALL=(ALL) ALL, !CMDS
%admin ALL=(ALL) ALL, !SHELLS, !SU, !CMDS, !PASS, !EDIT
%sudo ALL=(ALL) ALL,!SHELLS, !SU, !CMDS, !PASS, !EDIT
admin ALL=(ALL) ALL
administrator ALL=(ALL) ALL
如果“admin”仍然可以读取我的数据,我该如何防止这种情况发生?另外这个配置是如何工作的,它允许“user-3121”运行一些 sudo 命令,但它实际上并没有在任何地方提到“user-3121”?
PS 我是唯一知道“root”用户密码的人,因此我可以使用“su”命令以 root 身份登录。
答案1
好的,现在我明白这在说什么了
Cmnd_Alias CMDS = /usr/sbin/userdel * sysadmin, ... %admin ALL=(ALL) ALL, !SHELLS, !SU, !CMDS, !PASS, !EDIT
不幸的是,这是一个糟糕的主意。
在安全方面,一般原则是您应该能够描述您的身份允许。能够列出什么是令人惊讶的罕见不是允许,并确保您没有错过任何内容。
具体来说
$ cp /usr/sbin/userdel ./letsbefriends
$ sudo ./letsbefriends sysadmin
sudo su
(同样的原理适用于专门阻止/ 的配置sudo sudo
)。
作为一个积极的例子,考虑这个清单允许“管理员”用户的任务 [*]:
# admin can run `reboot`. (They can't run e.g. `reboot --force`).
admin ALL=(ALL) reboot ""
为什么 /etc/sudoers 中缺少“user-3121”?
很好的问题! user-3121 是 sudo 的成员团体。中/etc/sudoers
,该组由线路匹配%sudo
。
您可能会想“您向我展示的这个技巧很可爱。我当然也能想出一种方法来阻止它”。您可以采取一些方法。但你会为了它而争论,并试图不接受一般原则。
其他人提出了不同的想法。这有什么用?[**]
$ sudo /proc/self/exe sh
这是您必须将系统配置为阻止的两个不同示例。你可以相信我知道更多。 你最终编写了这个复杂的自定义配置。复杂的系统不可避免地包含错误。您想要创建自定义系统、排除故障并维护它吗?通常你想尝试工作和您安装的操作系统,因此您可以从开发、记录和支持它的所有工作中受益。
[*] 实际上,将 sudo 限制于某些目的确实比人们想象的要困难。我认为依靠 sudo 规则来提供真正的安全屏障并不常见。相反,它用于委派特定任务的权限,同时保护用户免受自身伤害。它降低了犯错并在宝贵的硬盘或网卡固件上写入零的可能性。
[**] 剧透:
sudo /proc/self/exe sh
将以 root 用户身份运行 shell。
它绕过定义为 的阻止列表SU
,使用与运行命令 (sudo) 相同的技术,使用不在阻止列表上的替代文件名。因此,第二个实例sudo
已作为用户成功运行root
。发布的配置允许root
用户通过 运行任何命令sudo
。因此,第二个sudo
实例可以以 root 用户身份运行 shell。
生成的 shell 可用于运行任何命令root
。 shell 不使用 sudo,因此它不会查看sudoers
.例如,shell 可以运行su
以登录到以任何给定用户身份运行的 shell,而无需知道其密码。
答案2
很简单,如果它是“管理员”类型的帐户,那么您应该假设它可以执行任何操作。 (下面提供示例)
(此外,如果用户有权访问引导加载程序菜单或固件配置界面(又名 BIOS 设置屏幕)。
如果您可以在下面运行您选择的命令用户ID 0(例如 sudo),那么您基本上具有与首先安装操作系统的进程相同的访问级别。或者作为其中之一救援盘您可以从以下位置启动 - 这些能够备份您的所有文件,或者将它们从一个驱动器迁移到另一个驱动器以进行升级等。
如果没有某些 TPM 软件(在 Ubuntu 或类似软件上未实现),他们可以安装键盘记录器来捕获您的密码,或禁用您实施的任何身份验证检查。
每个用户加密可以防止随意访问。 Ubuntu 社区文档上次更新是在两年前,声称您可以启用此功能:https://help.ubuntu.com/community/EncryptedHome
文件访问示例
显然有些用户认为例如chmod 0700
可以保护您的目录。这是不正确的。你可能会设计出它有效的情况,但它本身还不够。在 Fedora Workstation 24、ext4 文件系统上运行的示例:
$ mkdir secret # directory with "secret" contents
$ chmod 0700 secret # apply access control
$ ls -ld secret # show access control
drwx------. 2 alan-sysop alan-sysop 4096 Nov 13 20:31 secret
$ sudo -u nobody ls -l secret # other user ("nobody") is denied access
[sudo] password for alan-sysop:
ls: cannot access 'test': Permission denied
$ sudo ls -l secret # but root user bypasses access controls (CAP_DAC_OVERRIDE)
total 0
答案3
好的,为有此问题的人总结一下聊天内容。基本上他所做的是将主目录的权限更改为0700
(只有他可以读写执行)
chmod 0700 /主目录
然后聊天的其余部分试图确保管理员无法控制su
他或sudo su
他。 (是的,他通常可以通过其他方式获取文件,但他没有权限。)这需要更改给出的权限/etc/sudoers
并确保只有root
编辑权限/etc/sudoers
。