为什么以root身份登录不好?

我经常在论坛或其他网站上看到post,你看到人们以这样的方式开玩笑,以root身份运行/登录,好像它是一个非常糟糕的东西, 每个人都应该知道它。 但是,搜索在这个问题上没有多少。

它可能是Linux专家所熟知的,但我真的不知道为什么。 我记得几年前我第一次尝试Linux时(Redhat和Mandrake)一直以root身份运行,并且不记得因此而遇到任何问题。

实际上有一些发行版有一个明亮的红色背景,上面有警示标志作为root用户的壁纸(SuSe?)。 我仍然使用“管理员”帐户在我的Windows安装上经常使用,并且在那里也没有遇到任何问题。

它击败了多年来一直存在的安全模型。 应用程序旨在与非管理安全性(或仅仅是凡人)一起运行,因此您必须提升其权限才能修改底层系统。 例如,您不希望Rhythmbox最近崩溃由于错误而消灭整个/usr目录。 或者刚刚在ProFTPD中发布的漏洞允许攻击者获得ROOT shell。

在任何操作系统上,只需在用户级别运行应用程序并将管理任务留给root用户,并且仅在每个需要的基础上进行操作。

只有一个字:安全。

  1. 您以root身份登录=所有应用程序都以root权限运行 – Firefox,Flash,OpenOffice等中的每个漏洞现在都可以破坏您的系统,因为可能的病毒现在可以随处访问。 是的,Ubuntu / Linux只有很少的病毒,但它也是因为良好的安全性和默认的非特权用户。
  2. 这不仅仅是病毒 – 应用程序中的小错误可能会删除一些系统文件或…
  3. 当您以root身份登录时,您可以执行所有操作 – 系统不会询问! 你想格式化这个磁盘吗? 好的,只需点击一下就可以了,因为你是root用户,你知道你在做什么……

以root身份运行很糟糕,因为:

  1. 愚蠢:没有什么可以阻止你做一些愚蠢的事情。 如果您尝试更改系统可能有害,则需要执行sudo,这几乎可以确保在您输入密码时暂停,以便您意识到您将要做出可能的重大/代价高昂的变更。
  2. 安全性:在这个问题中已经提到了很多次,但基本上它是一样的,如果你不知道管理员用户的登录帐户,就更难破解。 root表示您已经拥有管理凭据的一半工作集。
  3. 你真的不需要它:如果你需要以root用户身份运行多个命令,而且当sudo过期时你必须多次输入密码而烦恼,你需要做的就是sudo -i而你现在已经是root了。 想用管道运行一些命令吗? 然后使用sudo sh -c "comand1 | command2"
  4. 您总是可以在恢复控制台中使用它:恢复控制台允许您尝试从执行愚蠢的事情或修复由应用程序引起的问题(您仍然必须以sudo运行:)来恢复。)Ubuntu没有密码对于这种情况下的root帐户,但您可以在线搜索更改它,这将使任何对您的盒子具有物理访问权限的人更难以造成伤害。

你无法找到有关它为什么不好的信息的原因是因为,互联网上的数据太多了:)并且许多长期使用Linux的人都像你一样思考。 这种思考root帐户的方式是相当新的(可能是十年?),很多人仍然因为不得不使用sudo而烦恼。 特别是如果他们在服务器上工作,这意味着他们进入了进行系统更改的意图。 可能是从以前的糟糕体验和安全标准中带来的,大多数系统管理员都知道的更好,但他们仍然不喜欢它:)。

这是一个很好的问题。 我认为答案略有不同,具体取决于您是在谈论服务器还是桌面安装。

在桌面上,使用root帐户并不常见。 实际上,Ubuntu禁用了root访问权限。 所有需要超级用户权限的更改都是通过sudo及其图形同源gksudokdesudo 。 但是,鉴于设置root密码很容易,为什么人们不这样做呢?

一个原因是它为您提供了额外的安全层。 如果以root身份运行程序并且利用了安全漏洞,则攻击者可以访问所有数据并可以直接控制硬件。 例如,它可能会在您的内核中安装木马或密钥记录器。 但实际上,即使没有超级用户权限,攻击也可能造成大量破坏。 毕竟,无需root访问权限即可访问所有用户数据(包括文档和存储的密码)。

在单用户系统上更有效的一点是,防止用户意外地使系统无法使用。 如果用户无意中发出删除所有文件的命令,即使数据丢失,他们仍然可以启动系统。

此外,如今大多数面向用户的(X11)应用程序都是基于它们作为常规用户帐户运行且没有管理员权限的假设而构建的。 因此,某些程序在以root身份运行时可能会出错。

在仅具有非图形shell访问权限的多用户系统上,其中许多原因不适用。 但是,Ubuntu仍然合理地默认为无法访问的root帐户。 首先,通过安全漏洞访问用户帐户(使用sudo权限)和获取root权限之间存在真正的区别,因为在第一种情况下,破坏其他用户将需要运行sudo并仍然会提示输入帐户密码作为额外的安全步骤。 另一方面,从用户帐户执行许多管理任务并且仅在绝对需要超级用户权限时才调用sudo是很有用的。 因此,从源代码安装程序时,建议在用户目录中构建源 – 运行configuremake – 并在最后一步中仅使用sudo make install 。 同样,这使得在脚中拍摄自己(以及多用户系统的其他用户)变得更加困难,并且降低了构建脚本对系统造成严重破坏的可能性。 因此,即使在服务器上,坚持使用Ubuntu 基于sudo的管理也是一个好建议。

没有(到目前为止)已被其他答案识别的以root身份运行的一个原因是可追溯性。 在主要是单用户计算机(您的台式机或笔记本电脑)的计算机上,它可能更少,但在服务器计算机上,如果有人以root身份登录,则您不知道应该对所采取的操作负责。 因此,具有多个系统和多个需要root权限的管理员的大多数专业组织都要求人们使用他们自己的用户ID(和密码)登录,然后在必要时使用sudo或类似程序以root权限运行。

否则,不以root身份运行的主要原因是:

  • 尽量减少事故造成的损害风险。 如果你以root身份运行rm -fr / home/me/my-subdir ,那么你就可以大大地从你的机器中消除所有重要性因为(第一个)斜杠之后的那个空间 – 因为首先出现的东西是东西首先添加 – 像内核, /bin/etc目录这样的小东西。 如果你失败了,Unix会感到沮丧。

  • 最大限度地降低恶意外部网站造成损害的风险。 如果您以root身份浏览,则更容易受到恶意材料的下载。

我比使用Ubuntu更多地使用MacOS X,但是默认情况下root被禁用,它仍然在我的机器上。 我经常升级内核和其他类似的操作 – 使用sudo (幕后)。 类似的技术通常适用于Linux。

基本上,您应该只使用root的全权特权来缩短工作时间,以避免出错的风险。

TL; DR:只在必要时以root身份执行操作。 sudo让这很容易。 如果启用root登录,您仍然可以遵循此规则,您只需要小心这样做。 虽然如果正确启用root登录实际上并不安全,但您不需要启用root登录,因为您有sudo

这里确实有两个相关的问题。

  • 为什么以root身份登录日常的计算机使用(网页浏览,电子邮件,文字处理,游戏等)是不是很糟糕?
  • 为什么Ubuntu默认完全禁用root登录并使用sudo和polkit使管理员能够以root身份运行特定命令?

为什么不一直以root身份运行所有东西?

大多数其他答案都涵盖了这一点。 它归结为:

  1. 如果您将root权限用于不需要它们的任务,并且您最终做了一些您不想做的事情,那么您可能会以您不想要的方式更改或损害您的系统。
  2. 如果您在不需要的时候以root身份运行程序,并且最终做了一些您不想做的事情 – 例如,由于安全漏洞或其他错误 – 它可能会改变或伤害你的系统以你不想要的方式。

确实,即使不以root身份做事,也会造成伤害。 例如,您可以删除自己主目录中的所有文件,这些文件通常包含所有文档,而不以root身份运行! (希望你有备份。)

当然,作为root,还有其他方法可以意外地破坏这些相同的数据。 例如,您可以为dd命令指定错误of=参数,并在您的文件上写入原始数据(这使得它们更难以恢复,而不是仅仅删除它们)。

如果您是唯一使用计算机的人,那么您只能以root用户身份造成的伤害可能并不会高于您使用常规用户权限所造成的伤害。 但是,这仍然没有理由扩大您的风险,包括其他破坏Ubuntu系统的方法。

如果使用非root用户帐户运行阻止您控制自己的计算机,那么这当然是一个不好的权衡。 但它不是 – 任何时候你真的希望以root身份执行动作,你可以使用sudo和其他方法

为什么不能以root用户身份登录?

以root身份登录的能力本身就是不安全的想法是一个神话。 某些系统默认启用root帐户; 其他系统默认使用sudo ,有些配置为两者。

  • 例如,广泛且合理地被认为是世界上最安全的通用操作系统的OpenBSD附带了root帐户,用于本地的基于密码的登录。
  • 其他备受推崇的操作系统包括RHEL , CentOS和Fedora 。
  • Debian ( Ubuntu派生出来 )让用户决定在系统安装期间配置哪种方法。

如果启用了root帐户,那么拥有一个系统并不是客观错误的

  1. 你仍然只在你真正需要的时候使用它, 并且
  2. 您可以适当地限制对它的访问。

通常新手会问如何在Ubuntu中启用root帐户。 我们不应该向他们隐瞒这些信息,但通常当人们提出这个问题时,因为他们错误地认为他们需要启用root帐户。 事实上,这几乎是不必要的,所以在回答这些问题时,我们必须解释这一点。 启用root帐户还可以轻松自满,并以root身份执行不需要root权限的操作。 但这并不意味着启用root帐户本身就是不安全的。

sudo鼓励并帮助用户仅在需要时以root身份运行命令。 要以root用户身份运行命令,请键入sudo ,space,然后键入命令。 这非常方便,并且所有技能水平的许多用户都喜欢这种方法。

简而言之,您不需要启用root登录,因为您有sudo 。 但是只要你只将它用于需要它的管理任务,那么以root身份启用和登录也同样安全,只要它只是以这些方式

  • 本地,来自非图形虚拟控制台 。
  • 使用su命令,从其他帐户登录时。

但是,如果以这些方式以root身份登录,则会出现大量增加的安全风险:

  • 图形。 当您以图形方式登录时,会运行大量内容来提供图形界面,并且您最终将以root身份运行更多应用程序以使用该界面进行任何操作。 这违反了仅以root身份运行程序的原则,这些程序确实需要root权限。 其中一些程序可能包含错误,包括安全漏洞。

    此外,还有一个非安全理由可以避免这种情况。 以root用户身份以图形方式登录并未得到很好的支持 – 正如loevborg所提到的 ,桌面环境和图形应用程序的开发人员通常不会以root身份对其进行测试。 即使他们这样做,以root身份登录到图形桌面环境也不会得到用户的真实世界alpha和beta测试,因为几乎没有人尝试过它(出于上面解释的安全原因)。

    如果您需要以root身份运行特定的图形应用程序,则可以使用gksudosudo -H 。 与root用户实际以图形方式登录相比,以root身份运行的程序要少得多。

  • 远程。 root帐户实际上可以做任何事情,它几乎在每个类Unix系统上都有相同的名称。 通过ssh或其他远程机制以root身份ssh ,或者甚至通过配置远程服务来允许它 ,使入侵者(包括自动脚本和僵尸网络上运行的恶意软件)更容易通过powershell攻击,字典攻击(以及可能是一些安全漏洞)。

    可以说,如果您只允许基于密钥而不是基于密码的根登录,则风险不会非常高。

默认情况下,在Ubuntu中, 即使您以root身份启用登录无法启用图形根登录或通过SSH进行远程登录。 也就是说,即使您启用root登录,它仍然只能以相当安全的方式启用。

  • 如果您在Ubuntu上运行ssh服务器并且未更改/etc/sshd/ssh_config ,则它将包含PermitRootLogin without-passwordPermitRootLogin without-password 。 这会禁用基于密码的root登录,但允许基于密钥的登录。 但是,默认情况下没有配置任何键,因此除非你设置了一个键,否则它也不起作用。 此外,基于密钥的远程root登录远不如基于密码的远程root登录,这部分是因为它不会产生暴力破解和字典攻击的风险。
  • 即使默认值应该保护您,我认为如果要启用root帐户,检查ssh配置仍然是个好主意。 如果你正在运行提供远程登录的其他服务,比如f​​tp,你也应该检查它们。

结论:

  • 只在你需要的时候以root身份做事; sudo可以帮助你做到这一点,同时在你想要的时候仍然可以为你提供root的全部function。
  • 如果您了解root如何工作以及过度使用它的危险,从安全角度来看,启用root帐户并不是真正的问题。
  • 但是,如果您了解这一点,您也知道您几乎肯定不需要启用root帐户

有关root和sudo更多信息,包括我在这里没有介绍的sudo一些额外好处,我强烈推荐在Ubuntu帮助wiki中使用RootSudo 。

默认情况下禁用Root帐户 – 这意味着它存在但不可用(恢复模式除外)。 这意味着攻击者知道您的root帐户,但即使他/她拥有root密码也无法使用它。 因此,攻击者必须猜测具有管理员权限的用户名和该用户的密码(这比仅仅尝试计算root密码要困难得多)。在XP中,如果安装了故障恢复控制台,那么任何人有物理访问你的盒子可以启动它(RC) – 无需密码。 与Ubuntu中的恢复模式相同。

在Ubuntu中,当他们说root被禁用时 – 真正的意思是该帐户被锁定。 通过将密码更改为与可能的加密值不匹配的值来锁定帐户。 这有效地阻止了任何人以root用户身份登录 – 因为他们无法输入密码。 由于仍然需要root访问权限 – Ubuntu内核已被修改为仅允许在单用户模式下进行root本地登录。

另见本页

它就像用AK47武装一个小孩,而他可以愉快地玩他的彩弹枪。 ;)

我的意思是它错了,因为你和你的应用程序将拥有他们需要的更多特权,那就是事情可以而且有时会出错:(

非常好的问题……让我从实际的角度回答这个问题:

当我开始使用Linux(十多年前)时,主要发行版并没有像今天那样使用非root帐户进行广告宣传。 由于我习惯使用Windows,因此我也没有看到使用受限用户帐户的重点。 特别是因为我不得不经常输入“su” – 当时sudo并不那么受欢迎。 ;-)所以我总是以root身份登录,因为我需要做很多维护才能使我的系统配置得很好。 但是猜猜看,任何新安装的系统都很快变得非常不稳定。

例如,一个具体的问题:我没有为Linux保留那么多的硬盘空间,所以在我的分区上剩下0字节的情况下发生了几次。 也许我不完全准确,因为我不知道确切的机制,但是当你用非root帐户填满磁盘时,总会留下几千字节。 但是如果你真的剩下0个字节,那么你的系统会出现奇怪的错误,你可能最终会在系统中遇到一些难以修复的问题,因为后台运行了很多系统软件……

另一件事是:root和non-root之间的划分可以使你的系统井井有条。 作为root用户,您可能不愿意干净地安装新的应用程序,这会使您的系统变脏,难以维护。

但好处是:现代发行版为您完成大部分管理任务,因此很少您必须使用root帐户来控制Linux系统的内容。 不时输入密码就足够了,剩下的就是经销商的脚本。

但我怀疑你的Windows系统上没有问题,如果你使用95或98.(至少我有问题…)由于管理员和普通用户之间缺乏明确的分离“传统“Windows应用程序假设他们可以做任何事情,例如安装间谍软件,如果他们喜欢它,即使没有告诉你。 微软在发布Vista时就遇到了这个问题。 (有效地实施了一个sudo机制。)所以人们得到了非常烦人的对话,说“你不能那样做”。 对于一些非Vista兼容的软件,你需要一些脏的黑客来安装它,即使是管理员……

这种方法背后有很多方面。 他们之中有一些是:

  • Root是强大的。
  • 在Unix和类Unix系统中,系统管理权限是全部或全部。 用户是否具有root访问权限,root访问权限意味着完全控制计算机。 如果有问题的计算机由多个人使用,或者root可以访问其他系统或用户文件,则为某些用户提供部分root权限更为可接受。

  • root用户可以隐藏他们的所有操作。
  • sudo记录通过sudo运行的每个命令。 记录sudo所做的工作有助于我们诊断单个系统/流程和一般配置问题的问题,并帮助我们确定所需的改进。

  • root密码使您可以访问系统上的任何命令。
  • 通过其配置文件,sudo可以为用户提供特定命令集的root访问权限。 这也避免了“全有或全无”的影响,使我们能够让个人用户更好地控制他们的机器并帮助他们摆脱常见问题。

    这是一篇很好的文章: http : //cf.stanford.edu/policy/root

     rm /* 

    让我们说你一直在清理行政区域。 你厌倦了密码,所以你sudo su 。 你只是第二次分心,忘了你去/ 。 那你就是rm * 。 我做到了 你可以把它全部拿回来,但它是一个PITA。 哦,它也进入了/media

    为什么不登录root?

    虽然您可以为超级用户帐户创建密码,允许您以root身份登录,但值得一提的是,这不是“Ubuntu”的处理方式。 出于某种原因,Ubuntu默认选择提供root登录名和密码。 相反,默认的Ubuntu安装将使用sudo

    Sudo是为人们提供root密码以执行超级用户职责的替代方法。 在默认的Ubuntu安装中,默认情况下,安装操作系统的人员将获得“sudo”权限。

    任何拥有“sudo”权限的人都可以通过预先挂起的sudo对其命令执行“作为超级用户”的操作。 例如,要以超级用户身份运行apt-get dist-upgrade ,您可以使用:

     sudo apt-get dist-upgrade 

    sudo方法的好处

    • 使用sudo,您可以提前选择哪些用户具有sudo访问权限。 他们不需要记住root密码,因为他们使用自己的密码。

    • 如果您有多个用户,则可以通过删除其sudo权限来撤消一个用户的超级用户访问权限,而无需更改root密码并通知每个人新密码。

    • 您甚至可以选择允许用户使用sudo执行哪些命令,以及禁止该用户使用哪些命令。

    • 最后,如果存在安全漏洞,它可以在某些情况下留下更好的审计跟踪,显示哪些用户帐户遭到入侵。

    Sudo makes it easier to perform a single command with superuser privileges. With a root login, you permanently remain in a superuser shell which must be exited using exit or logout . This can lead to people staying in the superuser shell for longer than necessary just because it’s more convenient than logging out and in again later.

    With sudo, you still have the option of opening a permanent (interactive) superuser shell with the command:

     sudo su 

    … and this can still be done without any root password, because sudo gives superuser privileges to the su command.

    And similarly, instead of su - for a login shell you can use sudo su - or even sudo -i .

    However when doing so you just need to be aware that you are acting as a superuser for every command. It’s a good security principle not to stay as a superuser for longer than necessary, just to lessen the possibility of accidentally causing some damage to the system (without it, you can only damage files your user owns).

    Just to clarify, you can , if you choose, give the root user a password allowing logins as root, if you specifically want to do things this way instead. I just wanted to let you know about the Ubuntu convention of preferring sudo instead and try and explain some of the reasoning why Ubuntu favors that approach as a default.

    Why not allow root login over SSH?

    Even if your root user does have a password enabling you to log in as root, it is still a good security practice to disable direct root login from outside, such as in SSH. It is reasonable for users to have to su - or sudo after the initial login.

    The potential benefits to this are mostly security-related:

    • It reduces the attack vector by removing the possibility of brute-forcing the root password remotely. It is typical for a server on the internet to be constantly barraged by attempts to brute-force the root password via SSH.

    • It creates a better audit trail so that even in the event of a breach where the attacker does obtain superuser privileges later, you can see whose user account was used to gain access.

    When logged in as root it makes it possible for applications, scripts or commandline commands to access sensitive parts of software which can damage the system. This can be the result of inexperience on the user or programmer’s part or due to malicous hidden code.

    It’s just too easy mess up when operating as root. You can clobber the entire system in like one command …

    I can add that there is a difference between Administrator in Windows and root in Unix. Administrator still have some restrictions in systems, where root does not have any restriction. The correct analog of root in Windows is System user.

    The bad thing to use PC under root/System is that you can accidentally destroy anything without any warning from OS.

    If applications are run as root, there is no guarantee that none of them would execute

     rm -rf / 

    (This is an example of a command that should not be run.)

    Given a knowledgeable and careful user, I’m not sure that a right answer exists. I hadn’t seen this answer, so I thought I’d chime in.

    What I don’t like is unintentional changes of permissions on multi-user systems that I need to chmod later. Fixing via chmod after-the-fact is much more irritating than needing sudo, but it depends on what I have planned.

    There is no danger in logging as root if used carefully.

    Although I think that disabling root is preferable solution, because attacker could not brute force it.

    One solution is to create user in sudo group with obscure name, like gamer and use sudo to perform administrative tasks.

    Hence attacker must not only guess password of that administrative user but his login name too. Which is not obvious if user using sudo has login name like kitty or gamer or something similar.

    Software is based on shared libraries, dependencies, configuration files, etc.
    Most of the times, a single click in an application invokes a “chain reaction” of multiple changes, not only where you think it would probably.
    When these changes are about to affect system-critical settings, it’s good for you – as a user – to know.
    That’s why root access is a good security model:
    If something crucial is about to happen to your system, you’ll be notified by being asked for privilege elevation.

    Reasons against using root:

    • Could accidentally destroy system files
    • Could get an infection
    • Doesn’t log actions

    Reasons FOR using root:

    • Access to everything, no typing passwords
    • GUI, no using terminals for managing system files/directories

    Seems to me that a non-root account could still fall victim of those reasons against using root, the most it adds is a confirmation for your actions. I think that as long as you know what you’re doing, you’re perfectly safe using root. There, I said it.

    It’s a two-faced problem with more than one answer.

    For some reality check on the ever-same-but-oh-so-awful answers to this:

    desktop installations :

    • use your own user and sudo if need be, otherwise one successfully used attack vector because you don’t really know what you’re doing and your system is compromised
    • in larger companies chances are, you might not even have root privileges on your own workstation, even if you’re an admin, depending on the amount of tin-foil hats being present.

    server installations :

    • there is a vast difference between doing your short work sessions legit as root (provided you have passwordless logins, proper ssh key management for all servers – and fail2ban configured for all password logins while you’re at it anyway) and having every daemon/service running with its own user (which is a must) – most people seem to not realize the difference
    • for fun: try using your version-controlled configuration management tools (ansible/puppet/salt/whatever with files from a git server) only without root access. (you do have some form of AAA in place for these special systems, as well as for your monitoring and backup systems, don’t you?)
    • also: default rm -rf / doesnt work in most mainstream distros IIRC
    • any serious workplace has a jumphost/bastion-host for accessing the server fleet which logs anything you do anyway, which likely is further protected by 2FA
    • if you have sudo and no jumphost you can fix up the hosts logs to end up however you want them to anyway, if they are not mirrored in realtime, that is.
    • when also the ssh logs are ‘cleaned’, you can’t even be proved to have been on the host, if there is no further network monitoring system in place

    For any company size (read: most likely SOHO with a static ip) in between these two extremes that lacks decent monitoring/backup/automation/logging measures, it may be useful to enforce usage of sudo on servers. (Which gets circumvented by people doing sudo su - ASAP after connecting, letting all your intentions of logging what happened go to waste even without malicious intents as soon as more than one root user is logged in. Good luck changing this through forced procedures and treatening people with draconian measures for failing to obey the rules. Life always finds a way.)

    But if you dont have at least fail2ban to secure your password logins (if there are any present, especially on internet facing systems), plus do mind about proper password handling (password management tools, retention policies, no master passwords, handling these upon employee fluctuations…) and have some form of proper update management for the server fleet in place so all the servers are patched regularily, you likely will be hacked some day anyway, be it from within or from the outside.

    And always having used sudo religiously and having enforced its usage among all people will not change your probability for getting owned much in that case.