防止其他用户查看我的文件

防止其他用户查看我的文件

参考:root/超级用户可以读取我的读保护文件吗?

我的 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

相关内容