在Ubuntu上，默认情况下只能出于“安全原因”使用sudo。但是，我不确定这是否比在文本模式控制台上使用登录名更安全。如果攻击者可以以我的普通用户身份运行代码，则有太多事情可能出错。例如，添加别名，向我的PATH添加内容，设置LD_PRELOAD和X11键盘记录程序，仅举几例。我唯一能看到的好处就是超时，所以我永远不会忘记注销。
我对su也有同样的疑问，但是它甚至没有时间限制。某些操作（尤其是IO重定向）对su更为方便，但是从安全角度而言，这似乎更糟。
在文本模式控制台上登录似乎是最安全的。由于它是由init启动的，因此如果攻击者可以控制PATH或LD_PRELOAD，则他已经是root。 X上运行的程序无法拦截按键事件。我不知道X上运行的程序是否可以拦截[ctrl] + [alt] + [f1]（并打开一个看起来像控制台的全屏窗口）或就像Windows上的[ctrl] + [alt] + [del]一样安全。除此之外，我看到的唯一问题是缺少超时。
所以我错过了什么吗？为什么Ubuntu家伙决定只允许sudo？如何提高任何方法的安全性？
SSH呢？传统上，root用户无法通过SSH登录。但是使用上述逻辑并不是最安全的做法：
允许通过SSH进行root操作
切换到文本模式
以root用户身份登录< br ssh到另一台计算机
以root身份登录吗？
#1 楼
安全总是要权衡取舍。就像在海底的安全，无插电的谚语服务器中一样，如果根本无法访问它，root将是最安全的。LD_PRELOAD和PATH攻击就像那些您描述的是假设有一个攻击者已经可以访问您的帐户，或者至少可以访问您的dotfile。 Sudo不能很好地防止这种情况的发生-毕竟，如果他们拥有密码，则无需稍后欺骗您...他们可以立即使用
sudo。考虑一下Sudo最初设计的目的：将特定命令（例如管理打印机的命令）委派给“次级管理员”（也许是实验室中的研究生）而无需完全放弃root。我现在看到的最普遍的用法是使用sudo来完成所有操作，但这不一定是程序要解决的问题（因此，配置文件语法异常复杂）。
但是，sudo-for- unrestricted-root确实解决了另一个安全问题：root密码的可管理性。在许多组织中，它们往往像糖果一样被传递，写在白板上，并永远保留下去。这留下了很大的漏洞，因为撤销或更改访问权限成为了一个大生产量。即使要跟踪哪台计算机具有什么密码也是一个挑战，更不用说跟踪谁知道哪台计算机了。
请记住，大多数“网络犯罪”来自内部。在描述了root密码的情况下，很难找到是谁做的-远程日志中的sudo可以很好地解决问题。
在您的家庭系统上，我认为这实际上更多是为了方便不必记住两个密码。很可能许多人只是简单地将它们设置为相同，或者更糟的是，最初将它们设置为相同，然后让它们不同步，而将根口令保留为rot。
对于SSH完全使用密码是危险的，因为密码嗅探的特洛伊木马ssh守护程序已放置在大约90％的真实系统漏洞中。最好使用SSH密钥，这对于远程根访问也可以是一个可行的系统。
但是问题是，现在您已经从密码管理转向密钥管理和ssh密钥并不是很容易管理。没有限制复制的方法，如果有人确实进行了复制，则他们会尝试用暴力破解密码短语。您可以制定政策，要求密钥必须存储在可移动设备上，并且仅在需要时才安装，但是无法强制执行—现在，您介绍了可移动设备丢失或被盗的可能性。
最高的安全性将来自一次性密钥或基于时间/计数器的加密令牌。这些可以通过软件来完成，但是防篡改的硬件甚至更好。在开源世界中，有WiKiD，YubiKey或LinOTP，当然还有专有的重量级RSA SecurID。如果您是中型或大型组织，或者甚至是一个注重安全的小型组织，我强烈建议您研究其中一种用于管理访问的方法。
对于家庭来说，这可能是过高的选择。 ，只要您遵循明智的安全实践，您就不会真正有管理上的麻烦。
评论
我会接受这个作为答案，因为它可以使Ubuntu开发人员在将sudo设置为默认方法时的思考变得更加清晰。远程日志记录似乎也是一个好主意，并且鉴于我已经在使用syslog-ng，因此设置起来应该不会太困难，因此我的所有计算机都将日志记录到所有其他计算机上。我将坚持目前切换到文本模式并从那里登录以进行完全root访问的做法。委派部分权限当然是使用sudo的好方法，而我从未考虑过。
–stribika
2011年3月4日19:42
sudo与Windows Vista中的“用户帐户控制”非常相似。两者的设计实际上都不是为了增加安全性，而是实际上是使其更容易以受控方式降低安全性。但是，由于它们使以低摩擦方式临时提升特权变得更加容易，因此您无需长时间以提升特权运行，从而提高了安全性。 （在Unix中，这并不是什么大问题，但是在Windows中，我记得连续几天都以管理员身份运行，只是因为切换非常痛苦。）
–Jörg W Mittag
2011年3月5日，1：10
密码嗅探木马ssh守护进程？如果它们可以替换ssh守护程序，则它们已经具有root用户。
–psusi
11年8月15日在20:01
@psusi：是的，在该系统上；在多个系统之间共享密码（通过目录服务）的环境中，这种折衷很容易以这种方式传播。即使是单个系统，在检测到漏洞后重新安装后，也很麻烦为每个人重新设置密码。
–mattdm
2011年8月15日在20:05
Ops报告卡的最后一项还提到了更改公司所有root密码的潜在困难，这非常值得一读。
–通配符
16年6月1日在1:04
#2 楼
这是一个非常复杂的问题。 mattdm已经涵盖了许多要点。在su和sudo之间，当您考虑单个用户时，su更加安全，因为发现密码的攻击者无法立即获得root特权。但是，所有要做的就是让攻击者找到一个本地根漏洞（相对不常见）或安装木马并等待您运行su。
与多个控制台登录相比，Sudo还是有优势的用户。例如，如果系统配置有远程防篡改日志，则您始终可以找出上次运行sudo的用户（或盗用了其帐户的用户），但不知道是谁在控制台上键入了root密码。 >
我怀疑Ubuntu的决定部分是出于简单性的考虑（仅记住一个密码），部分是出于安全性和易于在共享机器（企业或家庭）上分发凭据的目的。
Linux没有安全的注意密钥或其他用于身份验证的安全用户界面。据我所知，甚至OpenBSD都没有。如果您担心root访问，则可以完全禁用正在运行的系统的root访问：如果要成为root用户，则需要在bootloader提示符下键入一些内容。显然，这并不适合所有用例。 （* BSD的安全级别是这样工作的：在高安全级别上，有些事情是不重启就无法做的，例如降低安全级别或直接访问已安装的原始设备。）
限制可以使用的方式扎根并不总是安全的收获。记住安全三合会的第三个成员：机密性，完整性，可用性。将自己锁定在系统之外可以阻止您对事件做出响应。
评论
如果他们可以找到您的密码，那么他们可以轻松地找到根密码。您也可以将sysrq-k用作安全注意序列。
–psusi
2011年8月15日在20:19
Linux有安全注意事项，请参阅内核文档
–btshengsheng
16年6月12日在23:10
@btshengsheng Linux可以具有“安全注意密钥”，但是由于可以对其进行配置，因此您不确定它可以在任何特定计算机上运行。它也取决于键盘布局，因此可以通过重新分配其中一个键来绕过它。它被称为“安全注意密钥”，但并不完全符合要求。
–吉尔斯'所以-不再是邪恶的'
16年6月12日在23:16
#3 楼
安全的OpenWall GNU / * / Linux发行版的设计者也对su（成为root用户）和sudo表达了批评。您可能有兴趣阅读此线程：...不幸的是，su和sudo都有些微妙，但从根本上来说是有缺陷的。
除了讨论
su的缺陷之外等等，Solar Designer还针对使用su的一个特定原因：是的，它过去通常是sysadmin
来“ su root”而不是登录
。 />作为根。那些被问到
实际上能够提出有效的
理由的少数人会提到
这种方法实现的更好的问责制。是的，这确实是支持此
方法的一个很好的理由。但这也是唯一的。 ...（了解更多）
在其发行版中，它们“在默认安装中完全摆脱了SUID根程序”（即，包括
su；它们不使用功能）为此）：对于服务器，我认为人们需要重新考虑，并且在大多数情况下，
不允许
调用su和sudo。用户。从以前的“以非root用户身份登录，然后
su或sudo到root”系统管理员“智慧”，没有任何增加的安全性，与以非root用户身份登录相比，
>并直接作为root用户（两个单独的
会话）。相反，从安全角度来看，后一种方法是唯一正确的方法。
http://www.openwall.com/lists/owl-users/ 2004/10/20/6
（对于多个
sysadmins的问责制，系统需要像猫头鹰一样支持具有多个root特权
帐户的
。 ）
（对于使用X的台式机，这会变得更复杂。）
您还必须处理...
顺便说一句，他们将
sulogin替换为msulogin以允许使用多个根帐户进行设置：msulogin允许一个人在进入单用户模式时也输入用户名（并保留“问责制”）（此信息来自此讨论）俄语）。评论
对于基本上是防火墙的系统，这没多大好处，但是如果您打算运行，例如，随机运行mysql / postgresql / bind / powerdns / apache和生产系统中的其他程序，则可以开始遇到问题时，就像用X描述的那样。本质上，他们已经在很多可用性上交换了一定程度的安全性；由系统管理员决定这是否是一个公平的权衡。就个人而言，我会坚持使用Debian。
– Shadur
2011年9月23日在10:13
#4 楼
您似乎在假设使用sudo始终保留环境变量，但情况并非总是如此。以下是sudo联机帮助页的摘录：有两种不同的方法来处理环境变量。默认情况下，启用env_reset sudoers选项
。这将导致命令
在最小的环境中执行
，其中包含TERM，PATH，
HOME，SHELL，LOGNAME，USER和USERNAME，以及
允许的调用过程中的变量
env_check和env_keep sudoers
选项。实际上，有一个
白名单用于环境变量。
但是，如果在sudoers中禁用了env_reset选项，则任何未由env_check和
env_delete选项是从调用过程继承的。在这种情况下，
env_check和env_delete的行为类似于
黑名单。由于不可能
将所有潜在危险的环境变量列入黑名单，因此建议
使用默认的env_reset行为
。
在所有情况下，值以（）开头的环境变量
被删除
，因为它们可以被解释为bash函数。 sudo允许或拒绝的
环境变量列表包含在以root身份运行时sudo -V的输出
中。
所以如果
env_reset已启用（默认设置），攻击者无法覆盖PATH或其他环境变量（除非您专门将它们添加到应保留的变量白名单中）。评论
我的意思是，如果攻击者可以控制我的路径，那么他可以使我运行任何东西，而不是真正的/ usr / bin / sudo。例如，/ tmp / sudo会显示密码：当我键入内容时不显示任何内容，将输入的内容发送给他，说密码错误，然后执行真正的sudo。
–stribika
2011年3月4日17:47
嗯，我想在那种情况下，您可以直接运行/ usr / bin / sudo而不是依靠shell为您找到它。但是你是对的，这是我没想到的问题。
–塞德里克
2011-3-4在17:52
@CedricStaub：据我所知，似乎没有人想到这一点。我可以给出完整的路径，但可以尝试以下方法：alias / usr / bin / sudo =“ echo pwned”除此之外，还涉及大量程序（X，xterm，shell），其中任何一个都可以窃取密码。这就是为什么我说安全切换存在太多问题。
–stribika
11 Mar 4 '11 at 17:59
你试过了吗？我做了：bash：别名：`/ usr / bin / sudo'：无效的别名
– maaartinus
2011年3月4日在22:22
@maaartinus：有趣。它在ZSH中工作。
–stribika
2011-3-5在9:22
#5 楼
最安全的方法是使用（至少）2048个长密钥（禁用密码登录）并使用物理设备来存储密钥的ssh登录。评论
当然可以，但是从根到根或从无特权到无特权然后切换到根？ （为了安全起见，我实际上使用的是4096位密钥。并非到处都支持较大的密钥。）
–stribika
2011年3月4日在18:23
@stribika好吧，两个。如果机器受到威胁，您仍然不要松开钥匙。这样可以防止扩散（密码最大的问题）。
–ŠimonTóth
2011年3月4日18:40
#6 楼
我只想在主题外添加一些内容。（对于该主题，请在此处检查'/ bin / su-'）
我认为上述“安全性”也应链接到
我们要保护的实际数据。
如果我们要保护，它将并且应该有所不同：
my_data，my_company_data，my_company_network。
通常，如果我谈论安全性，那么我也谈论“数据安全性”和备份。我们还可以添加容错系统等。
鉴于此，我认为整体安全性是可用性，“数据安全性”和所需工作之间的平衡。来实现一个安全的系统。
Ubuntu的目标是而且最终仍然是最终用户：Sudo是默认用户。
Fedora是该版本的免费版本。 RedHat反过来更面向服务器：
Sudo以前被禁用。
对于其他发行版，我没有直接的信息。
我现在正在使用，主要是软呢帽。作为旧式用户，我从来没有键入'su'。
但是即使我不是打字员，我也可以在很短的时间内键入“ / bin / su-”。
PATH变量不是问题（我键入路径）。
原则上，“-”（减号）也应删除我的用户环境变量并仅加载根变量。即避免了一些额外的麻烦。
也许还可以使用LS_PRELOAD。
其余的我想@mattdm相当精确。
但是把它放在正确的盒子。假设脚本编写的智能工具包
可以访问我的数据。你觉得他到底要怎么办？
-发布我的照片？我的？
-试图找出我的女友名字并告诉她我访问了色情网站？
在单用户图片中，两种最糟糕的情况是：
-孩子被删除我所有的数据：出于娱乐或错误的目的
-孩子使用我的机器对其他实体进行进一步的攻击。<br />或类似的目标。
对于第一种情况，我在上面提到过，与网络安全相比，在备份上要花更多的精力。是的，您保存。我的意思是硬件崩溃没有什么不同。
第二种情况更加微妙。但是有关于这些活动的信号。
在任何情况下，您都可以做到，但是我不会配置我的家用PC
免受恐怖袭击！
我将跳过其他情况。
欢呼声
F
#7 楼
如果担心的是可以使用受损的用户帐户来嗅探用于sudo或su的密码，那么请为sudo和su使用一次性密码。 您可以强制远程用户使用密钥，但是出于合规目的，可能无法通过密钥。设置需要双重身份验证的SSH网关盒，然后从那里允许密钥使用可能更有效。这是有关这种设置的文档：使用WiKID两因素身份验证保护您的SSH部署。
#8 楼
您还可以查看privacyIDEA，它不仅使您可以使用OTP登录到计算机（或执行su / sudo），而且还可以脱机进行OTP。此外它能够管理您的SSH密钥。即如果您有许多计算机和几个root用户，则所有SSH密钥都集中存储。因此，如果密钥不再受信任，很容易“撤消” /删除SSH密钥。
当然，有组织任务和工作流可以保护系统。
评论
在您的ssh解决方案中，您是说要从另一个盒子中放入可能受感染的盒子吗？ 1 /如果是，那么，按照您的思路，您必须确保其他盒子不会受到损害，然后再使用它。 2 /如果否，那么您遇到同样的问题。@asoundmove：我的ssh情况有4个用户：root @ hosta，root @ hostb，stribika @ hosta，stribika @ hostb。假设攻击者可以同时运行两个stribika（毕竟他们都运行了flashplugin，无论如何），我仍然想要安全的root用户访问权限。因此，这两个盒子都可以部分受损。
“获得root特权的最安全方法”就像要求使用链锯的最安全方法。本质上是危险的。您想要的是减轻风险。