如果授予用户访问所有命令的权限,那么sudo比直接使用su安全吗?


40

因此,我一直在阅读su和之间的区别sudo,每个人似乎都同意这种sudo方法比允许访问根帐户本身更安全。他们说,使用root帐户,您只需一个命令就可以破坏整个系统。这我明白。但是,在系统上创建的初始用户也可以使用sudo访问所有命令。我可以通过运行找出答案su -l。如果是这种情况,那么我可以简单地运行sudo <game-ending command>以破坏我的系统。那么,与允许我直接访问超级用户帐户相比,这种方法又如何更好或更安全?我可以运行所有相同的命令...

是因为sudo在命令行上使用我是在明确告诉计算机我认为我在做什么?他们是否认为人们会忘记他们在超级用户帐户下的权限,除非他们明确表示是这样?

人们还指出,如果系统被外国人入侵并进入,则以root用户身份登录将使他们对我的系统造成可怕的后果。但是在我看来,如果他们已经可以访问我的帐户并知道我的密码,他们可以通过使用sudo并输入我的密码来做这些同样糟糕的事情,因为他们甚至不需要知道超级用户的密码。我什么不来?



2
感谢您提出这个问题,所以现在有一些事情向那些一直说sudo更安全但无法证明其合理性的人展示。
user253751 '18

Answers:


40

我个人并不一定认为它更安全,并且(sudo)的大多数好处都在多用户系统上。在单用户系统上,这可能是洗手间。

好处是(无特定顺序):

  • sudo具有出色的日志记录功能。sudo记录每个命令。
  • sudo可以进行更精细的控制。可以将sudo配置为授予对某些但不是全部命令的root访问权限。
  • sudo使用登录密码。这可以保护必须提供root密码(就像使用su一样),并且与上述有关更细粒度的控制/对root的访问有关。
  • 在Ubuntu中,默认情况下,root帐户是锁定的。这阻止了解密者登录(通过说ssh远程),他们不得不猜测用户名和密码。如果root帐户未锁定(如su一样),那么他们只需破解root的密码即可。
  • sudo -i可能是从用户中隔离根的环境变量的最佳方法。这不时出现,但有点深奥。参见https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells
  • 有些人认为必须在希望以root用户身份运行的每个命令之前键入sudo或sudo超时,这会使他们停止并更加清晰地思考,从而减少了错误或运行错误的命令。如果这样做对您有帮助,那也将是一个好处。

可能还有更多好处,但是,恕我直言,这是主要的好处。

另请参见-https: //help.ubuntu.com/community/RootSudo

尝试回答您的其他一些想法:

  • 只要知道密码,su或sudo都不会阻止您运行恶意代码。都不是更好或更安全的方法。
  • 饼干可以通过多种方法获取外壳。当您在安全通知-https ://usn.ubuntu.com/usn/中看到“运行任意代码”时,这意味着破解者可以运行/ bin / bash或任何其他代码。因此,破解者可以通过各种漏洞利用而无需知道您的登录名或密码即可获取shell访问权限。sudo或su都无济于事。
  • 如果饼干拥有外壳访问权限,则无需根访问权限就可以造成很大的损失。例如,用于加密您所有个人数据的勒索软件。
  • 如果破解者可以通过su或sudo拥有对具有root用户访问权限的帐户的shell访问权限,则该cracker可以通过本讨论范围之外的许多方法来获得root用户访问权限。在这方面,sudo或su都不是更好的选择。

因此,尽管您已经观察到sudo的问题或缺陷,但是su具有完全相同的漏洞,而su在这些方面并不优于sudo,恕我直言


最好选择在停止初始化时允许所有用户控制电源(关闭电源和重新启动),而不是使用sudoers条目或使用组名。
mckenzm '18

8
我相信最大的优势是必须证明每个命令都需要超级用户权限。我在Linux的早期经验中发现,当我修改系统时,往往总是以root身份至少在一个终端中运行。不幸的是,很容易通过误解或误解在终端发出破坏性命令。如果在“根终端”中,则可能导致从备份或重新安装进行还原。须藤保护了我很多次!
rolinger

14
不损害root密码可能是sudo的最大优势。您可以授予root权限而不会泄露任何秘密。
托尔比约恩Ravn的安德森

您不仅可以限制命令,还可以限制指定的参数。但是我不同意被锁定的根与它有关。因为您可以将ssh配置为不允许root登录。su和sudo相比,还有一些其他问题:sudo使用您的用户密码,这比要被泄露的密码少了一个,这通常不是一件好事。像这个世界上的所有事物一样,做某事的方法也有不同,这并不意味着一种方法比其他方法更正确(如果有的话)在100%的情况下。然后有偏好。
Pryftan

但是otoh如果需要根访问权限的用户不止一个(这不是我要讨论的,因为那只是-充其量是最热烈的讨论),那么sudo在那里就占有优势。
Pryftan

10

想象一下,您有20分钟的时间来做复杂的事情。你有点宿醉,你必须着急。您说“让我们使用su”。“这会节省一些时间”是您的理由。

偶然输入

rm -rf /*

代替

rm -rf ./*

您的系统现在处于阻塞状态,您有10分钟的截止日期。

如果您明确选择何时需要root用户,则可以最大程度地减少这种情况的发生。可能不需要根,rm -r ./*为什么要使用根呢?为什么要冒险?

这就是“安全”在这里的意思。将用户(所有用户,而不仅仅是初学者)犯致命错误的风险降至最低。

当然,这是一个极端的例子,不应在生产环境中发生(我保证它在生产环境中发生)。

安全方面,有些东西sudo也更好。正如@Panther所说 -记录,限制,root密码是SPOF等)


4
天哪,如果您只是做... chown -R nobody:nobody /甚至不需要chown -R nobody ../root ,就不需要等待那么长时间。chmod当然在递归模式下也有类似的问题。但是,您要说的最好的一点是,只有在需要时才应该是root。登录的权限越少,通常使用的权限就越好。
Pryftan

2
不过,当您感到宿醉时,可以+1进行编程。
abhicantdraw '18

4
那么,这有何不同sudo?您写sudo rm -rf /*而不是sudo rm -rf ./*然后重新繁荣。
ilkkachu

2
在实际命令方面,@ ilkkachu对所发生的变化影响很小。但是您必须明确声明要以root用户身份执行此操作。这才是重点。安全与风险管理有关。当然,您仍然可以建立系统。但是,拥有根特权的时间越少,犯致命错误的机会就越少。安全就是将概率降到最低。
dijksterhuis

2
@ilkkachu因为您不会输入sudo rm -rf ./*。您大概对当前目录中的内容具有写访问权,因此该命令不需要sudo。所以typoed命令结束是rm -rf /*,其产生的“权限被拒绝”的消息,让你知道你需要一个很长的字符串ctrl-c它得到你其实可以删除的东西之前,而不是只在删除一切/bin/boot/dev,一半的/etc前您甚至意识到有些问题。

9

我想在其他答案中添加一些历史观点。不幸的是,除了我自己对Usenet讨论和杂志文章的记忆,我没有任何资料准备。

一段时间以前,在1990年代,即使没有太多计算机知识,发行版也使得在您自己的硬件上安装Linux变得更加容易。¹因此,Linux开始吸引越来越多的人,这些人以前从未像以前那样成为系统管理员,一些UN * X方言。取而代之的是,许多系统用于(单用户)Windows 95/98等系统。他们了解到,大多数Linux系统管理任务都使得有必要在那个奇怪的“ root”帐户下工作。

因此,某些用户只是以root用户身份登录,并使用该帐户来完成所有日常工作。为什么他们应该有类型su一再或登录密码到一个新的tty只是一些管理命令?但是,对所有内容使用root当然不是一个好主意,因为如果在错误的位置使用一些无关紧要的命令,可能会对系统造成更大的损害。这甚至导致了一些发行版(是否是SuSE?)修改了root用户的桌面背景,以显示一个大警告:您应该仅将该帐户用于管理任务。

因此,Ubuntu方式sudo具有一些优势(除了Panther已经列出的那些优势)。

  • 您不能直接登录到帐户。²:-)
  • 安装过程不会要求您输入(附加)root密码,您只需要一个(您的用户)密码。
  • sudo会缓存您的凭据,因此对于依次执行的多个管理命令,您只需输入一次密码(与相比su)。这减少了仅以root特权打开外壳或新终端的冲动。
  • 而且,它使在线和在文档中告诉用户更容易,他们必须以管理员身份输入哪些命令,而不必输入。³

¹对于那些不愿意自己做的人,有装扮派对。
²但是,以普通用户身份登录后,您可以使用诸如sudo -i或的命令sudo su - root来获取root shell。
³但是您当然知道,您不应该简单地从Internet复制并粘贴命令,对吗?


您是否在Ubuntu中说不能做到:sudo su -sudo su - root?因为我已经看到过类似的说法,例如MacOS X没有root,但是当只需要执行第一个命令时,这是完全错误的……
Pryftan

2
当然有一个帐户。我说过您不能“直接登录”,这意味着您无法root在登录提示或X登录对话框中输入用户名和密码,并且无法以root用户身份启动会话但是您可以使用您的命令之一(我更喜欢sudo -i它,因为它更短,而且我很懒)来获得root shell。
Dubu

1
请再次阅读我的评论:)我说有些人说MacOS X没有root帐户,但实际上它具有root帐户,这使我想起了这一点(我并不认为它等同于Ubuntu中没有root帐户)。但就我所知,Ubuntu的开发人员都疯狂到足以修补sudo,从而不允许这样做,因此是我的问题。
Pryftan

1
@Pryftan正如我在上面的评论中所说,您的两个命令都可以正常工作,并且将为您提供root shell。我将其添加到我的答案中。
Dubu

是。我知道:)我并不是说那是假的或不是事实。我是说,这使我想起了一些人说的话,但说错了。因此,使该部分大胆。
Pryftan

2

几十年来,已经有可能通过ssh禁用root登录。Ubuntu禁用root帐户并使人们对所有内容进行sudo的方式不过是一种a头。只需“ sudo -s”,您便拥有一个根shell。通过ssh禁用root登录并保留在那里。


8
...注意,仅对任何ssh登录(而不只是root帐户)进行密钥登录是一种很好的做法。
rackandboneman '18

是。几分钟前,我在评论中指出了这一点。Otoh的特权最低是总的来说最好的,因此只有在需要时才升级,这适用于您是通过ssh还是本地登录。@rackandboneman所说的内容当然也是绝对正确的,尽管对我来说,即使使用ssh键,无论系统如何,我都禁用远程root完全停止。
Pryftan

0

根据配置,sudo <game ending command>不一定会正常工作。当然,如果sudoers配置读取为“ user ALL =(ALL)ALL”,则sudo不会提供任何其他保护。不过,您可以指定需要经常运行的特权命令的列表,例如安装新软件包,而忽略诸如的危险命令rm

这样,如果您以身份登录root,则可以运行所有命令,但是由于您仅偶尔需要这样做,因此<game ending command>可以大大降低运行的风险。


1
以及命令的特定参数。
Pryftan

1
和每个组而不是每个用户。在多用户环境中,使用团队是无价之宝,可能需要人员来去,也可能需要特定角色。
Panther

0

那个sudo允许您只允许某些命令,这并不是sudo优于su的唯一好处。

在大多数商店中,这甚至不是最重要的好处。

使用sudo,您知道谁执行了特定命令。

现在也许这对您来说无关紧要。例如,您可能是计算机的唯一用户。如果是这样,那么sudo可能不会比su更好。

但是许多主机拥有多个管理员。

sudo变得非常有用,因为如果有人做错了事,sudo会让您知道是谁做的。

这样一来,您就可以了解发生错误的原因,并教育人们防止再次发生错误,或者在必要时从某人中删除工具。

另外,当人们知道自己的行为被记录下来时,他们通常会多加小心。

须藤不是完美的。

如果两个人同时执行“ sudo sh”,则很难将命令归属于另一个。

恶意管理员可以随时删除或编辑日志-尽管干净地进行操作并不总是像人们想像的那样容易,尤其是在集中式日志记录的情况下。

sudo不一定会出于原始问题中指出的所有原因而停止愚蠢或恶意的行为。

但这确实为您提供了预防复发的更好机会。


1.仅当您花时间正确配置它时。默认的Ubuntu系统不执行(也不能执行)。2.仅当用户无法在事后编辑日志时,他们才可以进行编辑,除非可以运行的命令受到限制。(这不是默认的Ubuntu用例)
ilkkachu

@ilkkachu,尽管您有一些优点,但这里的论点毫无意义。关键点不是默认设置,关键是可以配置和微调sudo。您根本无法将su配置为采取这些方式。su是全部或全部,没有办法限制命令,事实上sudo提供了更好的日志记录。su或sudo都无法针对破解者在受威胁的系统上可能做或不能做的事情提供任何安全性,而且没有人以这种方式提供sudo的支持。sudo日志在正常的日常操作中具有很大的价值。

@Panther,很好,问题标题为“ ...是否已授予用户访问所有命令的权限?” 因此,我确实假设它们意味着通常的默认Ubuntu配置,其中sudo允许所有操作。当然,您可以对其进行配置,以限制允许用户运行的命令,但我认为问题并非如此。
ilkkachu

答案扩大了。
Ben Aveling '18

@ilkkachu-重新阅读我的回答“就我个人而言,我不一定认为它更安全,并且(sudo)的大多数好处都在多用户系统上。在单用户系统上,这可能是洗手间。” 然后,我继续解释sudo的其他优点,其中之一是它是可配置的。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.