是否担心以root用户身份高估登录?


16

对于个人笔记本电脑上的个人linux,我通常将环境设置即使在X或更低的运行级别下也以root用户身份自动登录。我发现我的工作流程是非常愉快的和快速的,无需任何繁琐无需键入susudo或钥匙圈或AUTH或东西被要求。

到目前为止,我从未遇到过任何问题,那么为什么大多数人对此感到恐惧?担心被高估了吗?当然,这是假定用户知道他们在做什么并且并不真正在乎系统可靠性和安全性问题。


4
为什么以root身份运行?如果您真的只是不想输入,sudo我建议您编辑/etc/sudoers并添加一些命令作为nopasswd(不是全部命令),然后在您~/.bashrc(或别名文件)中将aliases 添加到sudo command。这可能仍然不是一个好主意,但是它将限制您可能造成的损害或已经造成的损害。
xenoterracide 2010年

11
该线程中的敌对程度令人担忧。这是一个合理的问题。是的,一直以root身份运行是一个坏主意,但没有必要
彻底改变

5
@Mrozek:同意。现在,我永远不会将OP的root密码提供给我可以控制的任何系统,但是通过输入错误的内容来破坏系统是非常有教育意义的。也许OP撰写的“到目前为止,我从来没有遇到过任何问题”将学到一些有用的东西,例如第一次可以发生的事实。
David Thornley,2010年

2
我想这概括了为什么不:unix.stackexchange.com/questions/502/...
亚历克斯·B

3
打个比喻:就像没有安全带开车。可能,但可能致命。
反转

Answers:


33

出于同样的原因,每个守护程序都应具有最小权限。Apache可以root身份运行。它旨在执行一项任务,并且肯定不会发生不好的事情吗?

但是假设apache不是没有错误的。错误不时被发现。有时甚至可以执行任意代码或类似代码。现在,以root用户身份运行apache,它可以访问任何内容-例如,可以将rootkit加载到内核中并隐藏自身。

另一方面,编写用户级别的rootkit非常困难。它必须覆盖ps内部的其他程序(例如)/home,由于使用了额外的磁盘空间,因此可能引起怀疑。它可能不知道确切的配置,而忘记包含例如gnome-system-monitor因此公开本身。它必须覆盖bashtcsh以及您碰巧要使用的任何shell(以自我启动)。它必须使用不同的配置,而不是“简单地”覆盖一堆回调。

考虑一下不久之前在Adobe Reader中发现了任意代码执行。

另一个原因是用户错误。最好在通过一条命令擦除整个磁盘之前发出警告。

第三个原因是壳的不同。/如果需要对系统进行救援,则应安装根壳。用户的shell可以安装在/usr(例如,用户可以使用zsh)上。

究其原因,是因为不同的程序不能以root用户身份运行。他们特别知道不应该这样做,因此您需要打补丁系统。

第五个原因是,/root/home可以(并且应该)的同时,不应将其放在单独的分区上。拥有/home独立帮助因各种原因。

:为什么不以普通用户身份使用。您通常不需要拥有根权限。安全成本很小。


3
作为root用户,dd可以对系统中的任何块设备执行任何操作的事实,再加上root有可能对/ dev和/ proc中的内核和系统内容进行很多有意和无意的干预,足以说服任何人除非需要,否则不要以root用户身份运行。
LawrenceC

29

您也可以裸体骑摩托车,什么也不会发生。但是我敢打赌,如果你撞自行车的话会更好。


7
也许吧,但是想想剩下的时间你会得到的感觉!
Sirex

12

除了明显的安全性外,很明显,您从来没有通过在shell或lapsus中弄错命令来使系统崩溃。如果发生这种情况,您将理解为什么人们对此大吃一惊。然后,您会惊恐地哭泣,并意识到这是一种极富教育意义的体验,但是无论如何您都无法恢复系统。

一个想法:如果在正常使用系统时要求您输入root密码(即未安装软件包或执行其他系统管理任务),则说明您做错了


+1让我想起了一些旧的经历。还是应该使它们恢复为-1?
David Thornley,2010年

5
我从来不明白为什么人们相信使用sudo可以防止错误输入命令。我几年前使用的最后一个系统是sudo rm -rf / dir / job。
Sirex

4

不,它没有被高估。实际上,它是最被低估的。:-)

例如,我的小团队正在共享一台RHEL机器来进行开发工作:构建资料,测试等。每个人都使用单独的用户帐户,但是我们也共享根密码,因为人们不时需要此密码来执行快速的sysadmin任务。这也导致我们在较短的使用寿命内设法使该操作系统多次崩溃。有人在构建某个特定版本的libc时愚蠢地删除了系统libcrm调用。在另一个奇怪的事件中,分区表丢失了。(好吧,这与特权无关。)团队的其他成员将被阻止,直到修复破损为止。一种解决方案是让某人自愿承担sysadmin任务。到目前为止,除了让人们学习课程外,我们还不太在意:我们所有人的后端都需要一些齿痕,而这些齿痕相对便宜。

真正好奇的人可能希望遵循最小特权原则,并阅读Ken Thompson的论文“对信任信任的思考”。(“道德很明显。您不能相信您并未完全创造自己的代码。”)


3

收集您对另一个答案的评论

但是linux是关于自由的,包括自由销毁自己的数据,隐私和安全性

即使强迫人们通过sudo,Linux也提供了这种自由。您想要避开的整个安全论点就是保护您免受事物伤害(不是:恶意程序或由恶意人员控制的程序)。

将其视为安全带。需要花费一秒钟的时间。可以从其他白痴(以及您自己)中拯救您的生命。

如果您不想一直输入密码,sudoedit /etc/sudoers但是如果您始终以root用户身份运行,则有一天您可能会运行某种会破坏您的系统和所有数据的东西。

如果您很高兴地知道即使像Flash这样糟糕的东西也可以重新格式化您的计算机,那么这里没有人关心您的工作。以root身份运行。


2
不只是恶意程序,还有bug程序(例如,如果您将内核编译为root用户,则内核构建系统中的某个漏洞会破坏您的系统)
Spudd86

2

为什么不在时将Damn Vulnerable Linux作为主要系统运行。如果您要忽略系统安全性,则不妨全部忽略...


从技术上讲,以root用户为主用户的计算机在理论上可以得到保护...
Maciej Piechotka,2010年

3
@Maciej唯一安全的计算机已拔下,并用水泥固定在湖底。
xenoterracide

正如米特尼克(Mitnick)指出的那样,有人可以将其拿到湖外,打碎水泥并插入电源(哦,他只是说有人可以使用社会技术插入未插电的计算机,但原理是相同的)。我尝试谨慎使用“技术上”和“理论上”的方法-坏锁比没有锁好。例如,尽管缺少SELinux,我仍认为我当前的系统足够安全;)
Maciej Piechotka 2010年

@Marciej井的安全性完全与成本/风险分析有关。您对某事的重视永远不会超过那事值得。
xenoterracide

1
@Marciej,如果它一文不值,那么就没有必要对其施加任何安全性了,那时候,任何漏洞都无关紧要。
xenoterracide

1

您所说的操作系统是无数人的共同努力。如果您只运行稳定的软件,则可能安全了一段时间。

如前所述,您可能会惊讶于一件事情会破坏整个高清画质。在我的第一年中,我尝试完全以root身份运行,因为在Fedora-core 3时代,没有太多花哨的方法可以从用户管理系统。

当时,我进行了一个小的xorg编辑而不进行备份,因为我认为这样做不会造成伤害。桌面不见了。然后我尝试手动修复它,但无法确切地知道我做了什么。后来,我认为也许可以重新安装驱动程序和台式机,但无意间断开了我的以太网,因为它也是nvidia。

首次运行Arch时,我忽略了创建用户的警告,并以admin身份运行了一段时间。我从AUR安装了我需要的软件包,重新启动后,整个安装失败了。

自从我扎根以来,解决这些问题就变得比需要的要糟糕得多。

您可能会得出结论,我只是没有能力。但是,正如其他人提到的那样,...键入“ sudo”是一个小小的代价,可以让您高枕无忧。

编辑:哦……某些程序,例如WINE,显然不应该在根环境中运行。http://wiki.winehq.org/FAQ#head-96bebfa287b4288974de0df23351f278b0d41014


1

安全原因-针对Linux的守护程序或脚本漏洞将使Sysadmin拥有对系统的控制权。

以简单用户身份运行并使用sudo在安全性方面有很大不同。我的Firefox以我的用户身份运行,因此任何Firefox漏洞都只会影响我的帐户。没有其他的。


0

我同意Maciej对安全性和对某些权力的控制权。另外,由于您是系统的所有者,因此可以根据需要禁用此功能;)这是您的选择。


-4

只要您不做任何愚蠢的操作,以root用户身份登录普通会话就不会出现任何大问题。

我个人不这样做,因为偶尔我会做一些愚蠢的事情。我从来没有注意到我所做的任何愚蠢都可能会成为一个大问题,但是我并没有高傲地认为自己永远不会做任何真正的愚蠢的事情。


8
使用网络浏览器会构成愚蠢的行为吗?
xenoterracide

4
@xenoterracide:我说,如果您以root用户身份登录,这将构成愚蠢的事情。
David Thornley,2010年

2
@David我知道;)那就是重点
xenoterracide 2010年
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.