我当时在想，拥有比root用户更高权限的用户可能是有利的。

您会看到，我想保留所有活动以及几乎所有现有的root用户特权。

但是，我希望能够在极其个别的情况下拒绝特权授予root权限。

优点之一是可以防止在更新过程中安装某些不需要的文件。这只是一个可能优势的例子。

因为apt-get更新是由root或具有sudo特权运行的，所以apt-get能够在更新过程中替换某些不需要的文件。

如果我可以拒绝这些特定文件的特权，则可以将它们设置为simlink，/dev/null或者可以将其设置为空白占位符文件，该文件可以具有在更新过程中拒绝替换文件的权限。

此外，我不禁想起了在接受Ubuntu创作者之一采访时说的一句话，当时那个家伙说了一些有关用户如何更好地信任“我们”（指Ubuntu开发者）的事情，“因为我们有根”，这是在具有root权限的情况下如何执行系统更新的参考。

简单地更改安装过程以说出解决此问题的方法绝对不是我在这里感兴趣的。既然我的脑子里有一个想法，就是有权拒绝超级用户访问权限，那么我想找出一种方法来实现此目的。

我只是考虑过这一点，到目前为止还没有花任何时间来思考这个问题，我非常有信心可以解决这个问题。但是，我很想知道这是否已经完成，或者这可能不是一个新的想法或概念。

基本上，似乎应该有某种方法可以拥有一个超级超级用户，该超级超级用户的权限仅超出系统权限一个级别。

注意：尽管我认为可接受的答案最符合标准，但我非常喜欢@CR的答案。也。

我想在树上创建一个实际的用户（我），但我想我有一天要花一天时间坐下来。

另外，我不是在这里尝试使用Ubuntu。如果我对此感到负面，就不会将其用作主要发行版。

所需的“用户”称为LSM：Linux安全模块。最著名的是SELinux和AppArmor。

这样，您可以防止某些二进制文件（及其子进程）执行某些操作（即使其UID为root）。但是您可以允许对它们getty及其子进程执行这些操作，以便可以手动执行。

您误解了root用户的概念。

用简单的英语来说，root是“树顶”。

如果您决定一天有一个“超级超级用户”，然后下个月决定一个“超级超级用户”（！），该怎么办？您想走多远的树？您将如何调整所有权限和层次结构以使其正常工作？谁总是最重要的？必须有人在最顶端，这就是root。故事结局。

这里给出的解决方案-包括AppArmor和SELinux-并没有真正改变这一点。它们只是允许对root权限和进程进行更精细的控制。

在我看来，您的更新过程不适合预期的结果。但这根本不是root用户的错。不要使事情复杂化，而应将其root视为最高权限的用户，然后其他所有事情都必须向下进行。

我知道有些人会将此标记为低，但用户层次结构中没有更高的级别，所有其他解决方案仅对root权限的工作方式进行了稍微不同的控制。但是他们不会创建具有更高权限的新用户。

你不能有“更多的权限”不是一个用户root，因为root代表了可能的权限的最高水平。使用“比根目录更能控制”这样的短语是矛盾的- root具有完全的控制权和所有可能的权限，因此在此之上无能为力。

如果只想防止文件或目录被更改/删除，则只需在文件或目录上设置不可变标志。

chattr +i <file>

除非删除该标志，否则即使root用户也无法对他们执行任何操作。也可以使用容器/命名空间系统来防止root用户访问，但这似乎对您所需要的东西来说是过大的了。

• 您可以限制超级用户而不是拥有超级超级用户。请参阅 在gnu / linux上设置文件权限等的不同方法是什么

• 还有AppArmor和SELinux。

• 和/或配置sudo，这样您就不会放弃完整的root特权。您可以对其进行设置，以便用户只能运行带有预定参数的预定命令。

• 您还可以使用虚拟化来限制root用户：

  • cgroups，名称空间，chroot等（docker这样做）
  • en
  • 虚拟箱

• 另请参见etckeeper：此工具修订版控制/etc目录，并与apt同步。默认情况下，它是不安全的，恶意安装可能破坏它，但您也可以通过将其推送到防火墙备份存储库中来进行更改。

• 通常使用修订控制和防火墙备份存储库。这有助于意外的，故意的损坏和硬件故障。

防火墙备份存储库可以位于其他计算机，Internet或其他虚拟机（或虚拟机主机）上。

对于像APT这样的软件，在正常运行中需要访问几乎所有系统，限制是有问题的。即使您阻止它访问系统的某些部分，恶意分发者也很可能有足够的可能性来解决。例如，通过替换库或仅二进制文件或添加恶意配置更改，最终将使用不受限制的根。

根据您要放置多少限制，某些安装脚本可能会中断。

有关限制应用程序和用户的方法，您可以编写AppArmor或SELinux策略。哪种策略会更受支持取决于您的发行版：基于Debian的版本对AppArmor有更好的支持，而基于Fedora / RHEL的发行版默认启用SELinux。

AppArmor和SELinux都在白名单策略上工作，这些策略包含允许（或拒绝）特定操作的规则。将策略应用于exec处的流程，类似地，在登录时将策略应用于其流程时可以限制用户。不能回避周全的策略（如果不考虑内核错误）。以root用户身份（uid 0）运行的受限进程受配置的策略限制，除非策略明确允许，否则无法对其进行更改。

AppArmor策略语言定义了一个拒绝规则，该规则可用于构建黑名单策略。开始使用AppArmor的一个好地方是AppArmor 手册页，Wiki，以及在发行版中查找现有配置/etc/apparmor.d/。

SELinux Wiki中提供了大量SELinux管理和开发材料。SELinux 参考策略托管在github上。

我不敢相信没有人提到过钉住...

几年前，微软发布了一个补丁，使Windows 10计算机无法与我们的旧Samba NT4域控制器进行通信。发现问题后，我们将Samba软件包固定为当前版本，并且apt仍然可以正常运行。

完整的Debian演练很好地说明了这一过程：

在/etc/apt/preferences（或下的一个新文件/etc/apt/preferences.d/）中，添加一些文本以指定哪个软件包和版本：

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

检查文档以获取确切的语法，但这是我们固定软件包版本的快速又肮脏的方法。Root 可以像root一样总是绕过它，但这解决了程序包管理器试图自动升级您的程序包的问题。

注意：此答案是假设您有XY问题

实际上很简单。

根是您的“超级超级用户”

创建一个名为“ admin”的帐户，并授予他所有root用户的权限，除了您不需要的用户之外。

然后创建一个名为bob的用户，并让他“成为管理员”。通过使用su甚至sudo。

现在，您有一个普通用户（bob）一个可以执行管理任务的超级用户（admin）和一个超级超级用户（root）。

如果您想将名称“ root”更改为其他名称，您甚至可以这样做。从技术上讲，仅用户ID（0）很重要。

如果只希望阻止特定文件的安装，那么限制root权限不是实现此目的的方法。还值得注意的是，常规答案（不可变文件或LSM）将不适用于您的特定用例，因为APT（和大多数其他程序包管理器）如果无法安装文件将获得救助。

您想问的真正问题是：

有没有一种方法可以防止APT安装特定文件？

这与您在多个级别上提出的要求完全不同。

现在，对于这个问题，我还不能确定自己是100％，但是我确实知道许多其他软件包管理器都有防止安装特定文件的选项（例如，Gentoo的Portage系统具有选项INSTALL_MASK=，该选项实际上接受外壳程序）样式的匹配模式（无法安装）。我非常愿意打赌，APT存在这种选项（或者可能是dpkg本身）。

将备份副本放在安全的地方。安装/更新后，请立即从备份中替换特定文件。因此，没有错误可以使安装正常进行，但是您仍然可以取回要保留的文件。

在已安装的驱动器上工作

请注意，这主要是一个概念性的答案，但我认为它应该有效并且与您要实现的目标保持一致。

让系统X为您的工作系统，让系统Y为您控制的其他系统

1. 从Y挂载目录作为X的驱动器
2. 设置权限的方式应使X的root用户对该已安装驱动器中的所有内容都具有权限，只有少数例外

现在，您拥有可以执行几乎所有操作的“工作根”，并且拥有您的“超级根”，即系统Y的实际根帐户，可以真正执行所有操作。

您可以运行Xen hypervisor之类的type-1虚拟机监控程序 ，并让其将常规操作系统作为虚拟客户机托管。系统管理程序在比根用户“更深”的级别上控制虚拟客户机OS，因为它可以控制运行客户机OS的（虚拟）硬件。

您可以对虚拟机管理程序进行编程，以多种方式操纵来宾操作系统，包括更改权限，创建和应用备份，在来宾操作系统中挂钩某些更改或说明以注入其他功能，进行验证等。这将是一种有效且可能有用的方式用“用户”（实际上是系统管理程序的功能）来实现unix类型的系统，以“即使root也不能做”

我认为这种方法可能会过分

看一下cgroups和Linux名称空间，作为实现这种目标的另一种方法，以及基于它们的工具，例如Docker和lxd。

这些工具使您能够限制以“ root”身份运行的进程可以查看文件系统的哪些部分，限制哪些进程对其可见，并仅向“ root”用户提供某些功能。

卸载 sudo

如何卸载sudo和符号链接/bin/su到/bin/false？将其与确保root无法通过登录ssh并已锁定系统相结合。

这就是root超级*超级用户，其他所有人都从属于该用户。

对于更新期间替换的文件，只需不进行任何更新。更现实的是，将文件的权限更改为440或444使其无法写入。或将它们放在git存储库中，以便如果它们确实被覆盖，则可以将其还原。