TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Is chroot a security feature?

88 点作者 katzeilla超过 5 年前

20 条评论

jedberg超过 5 年前
So the basic argument is that if you can become root you can escape the jail. So if you have access to a vulnerable program you can become root and escape.<p>This might be true, but it&#x27;s still a good practice for defense in depth and <i>does</i> offer a security benefit. It helps protect you when there are non-root flaws in software. For example a web server that lets clients get to directories with &#x27;..&#x27; notation. Even with that compromised software, they wouldn&#x27;t be able to get to &#x2F;etc or &#x2F;home if they are in a proper chroot.
评论 #20969606 未加载
asadjb超过 5 年前
Many comments in this thread are bashing the article for saying that <i>chroot</i> is useless or shouldn&#x27;t be used. However the article itself takes a more nuanced approach.<p>From the conclusion:<p>&gt;It is not hard to consider the chroot() system call a security feature. In theory, it sounds great, but if you really take the time to understand what is going on, it is not really a security feature, it is closer to what we would call a hardening feature. It might slow down an attacker, but in most situations it is not going to stop them. We are dealing with a situation where calling this a security feature is likely more damaging than not because it creates a false sense of security. It is human nature to let our guard down if we believe we are safe. Using chroot is no safer than not using a chroot. You would be far better off investing your resources into a custom SELinux policy and ensuring your system is properly hardened. Good security has no shortcuts.<p>I think the point is that you shouldn&#x27;t consider <i>chroot</i> the only or best option for securing your system. It&#x27;s just one tool in the toolbox and needs to be understood properly and not trusted blindly as the solution for all security vulnerabilities.
评论 #20970067 未加载
评论 #20971697 未加载
评论 #20971425 未加载
phkamp超过 5 年前
How can this even be a question 20 years after FreeBSD Jails ?<p><a href="https:&#x2F;&#x2F;papers.freebsd.org&#x2F;2000&#x2F;phk-jails&#x2F;" rel="nofollow">https:&#x2F;&#x2F;papers.freebsd.org&#x2F;2000&#x2F;phk-jails&#x2F;</a>
tptacek超过 5 年前
<i>Nothing would prevent root from just modifying the process memory directly to change the chroot() location back to &#x27;&#x2F;&#x27;.</i><p>Huh? The chroot root directory is stored in the kernel, in the task structure, not in process memory. For that matter, every process can modify its own memory, not just root.<p>It is in fact a bug, or at least a design flaw, that root can break out of chroot. For instance, the Unix filesystem, historically, at the VFS layer (or whatever Linux calls it), has a simple tree structure, Unix allows nested chroots, and chroot(2) doesn&#x27;t chdir(2) you into the new root. If you chroot to a subdirectory of your root and don&#x27;t chdir into it, Unix is too dumb to know you&#x27;re &quot;above&quot; your current root.
评论 #20971893 未加载
tus88超过 5 年前
I can&#x27;t believe this guy works for redhat.<p>&gt; you are no safer inside a chroot than relying on system permissions to keep a user in check<p>But how may systems lock down every executable in &#x2F;bin and &#x2F;usr&#x2F;bin?<p>Chroot is about denying an attacker a hackers toolkit when they get access.<p>It&#x27;s not just about hacking the current system, but the network.<p>No gcc? No netcat or ssh or netstat? Or even bash? The first thing hackers look for is what tools are available on the system, and denying them any is a form of security. This had been known for <i>decades</i>.
rascul超过 5 年前
chroot() started out as just a chdir() operating on root directory instead of current directory.<p><a href="https:&#x2F;&#x2F;utcc.utoronto.ca&#x2F;~cks&#x2F;space&#x2F;blog&#x2F;unix&#x2F;ChrootHistory" rel="nofollow">https:&#x2F;&#x2F;utcc.utoronto.ca&#x2F;~cks&#x2F;space&#x2F;blog&#x2F;unix&#x2F;ChrootHistory</a>
xorcist超过 5 年前
&gt; Using chroot is no safer than not using a chroot.<p>This is terrible advice. Software should drop privileges early, and chroot is as important as it has ever been. Other useful things include seccomp-bpf and pledge.<p>OpenSSH and Postfix is absolutely safer because they drop privileges after reading configuration and binding ports.
评论 #20969729 未加载
nickcw超过 5 年前
chroot is a layer in the security onion.<p>Like every other layer it adds security but isn&#x27;t perfect. Security will never be 100%. If you want more security, then likely you want another layer in the onion.
评论 #20969714 未加载
johnklos超过 5 年前
This article is entirely FUD.<p>chroots are useful when running software which we don&#x27;t necessarily know is secure. It reduces the impact of flaws in software we don&#x27;t control.<p>The point is taken that proper permissions would effectively be no different from a chroot, but this is disingenuous, particularly if considered with the statement, &quot;but note that setting up a chroot can be far more complex than configuring a system&quot;.<p>This is pure hyperbole and deserves to be called ridiculous. Compare configuring a chroot, which is easy, straightforward, common and well understood with configuring a user to exclude access to everything in a system except what the chroot would allow, and try to reasonably suggest that the chroot is more complex.<p>You can do lots with login.conf, but hang on - systemd does things differently. So instead of decades of well understood chroot history, now you have to figure out how login.conf works with systemd. Then you have to figure out what version of systemd it is, and whether behavior has changed, and whether documentation even matches your system&#x27;s systemd...<p>In other words, this whole article has no purpose aside from trying to disparage chroot without any actual, meaningful information.<p>So how does Red Hat benefit? Of course Red Hat doesn&#x27;t want people running lots of processes in a single installation. They want people to run a ton of system images in huge VM environments and have people become accustomed to needing lots of resources to do the simplest of things. This makes paying Red Hat for &quot;support&quot; easier to swallow. One instance with lots of tasks? Insecure, according to them. A separate VM for each program? Much better, if you believe them :P
评论 #20974291 未加载
pmorici超过 5 年前
&quot;it is not really a security feature, it is closer to what we would call a hardening feature. It might slow down an attacker, but in most situations it is not going to stop them.&quot;<p>Does his argument boil down to this? If so this seems like a silly argument over semantics. Is there anything in existence that can &quot;stop&quot; an attack?
z3t4超过 5 年前
If you forget to setuid after chroot it&#x27;s much less secure :P I have a free online service where anyone can run any code on a fairly powerful dedicated server. And it uses chroot, setuid, iptables and Apparmor. It has not yet got pwned, knock on wood.
gpvos超过 5 年前
I don&#x27;t understand why the article recommends pivot_root. Its man page says that it <i>may or may not change the current root and the current working directory of any processes or threads which use the old root directory,</i> which means it can change the root <i>of other processes!</i> Also, it says that its typical use is for switching from the boot RAM disk to the actual root filesystem. This is an entirely different use case than chroot, and doesn&#x27;t seem to have any security benefits either.
takeda超过 5 年前
That&#x27;s why FreeBSD created jails, the idea was to actually make a secure chroot.<p>The original purpose of chroot was nothing more than control where an installer installs its files.
agapon超过 5 年前
IMO, chroot is good for changing root :) but not for security. Example: zfs clone your current root, chroot there, experiment &#x2F; test &#x2F;etc.
loeg超过 5 年前
&gt; Putting a regular user in a chroot() will prevent them from having access to the rest of the system. This means using a chroot is not less secure, but it is not more secure either. If you have proper permissions configured on your system, you are no safer inside a chroot than relying on system permissions to keep a user in check<p>Lol. So, all security mitigations ever are pointless.
aloknnikhil超过 5 年前
Wait, are there people who really think chroot offers security?<p>I mean, at least read the man page before making assumptions?<p><a href="http:&#x2F;&#x2F;man7.org&#x2F;linux&#x2F;man-pages&#x2F;man2&#x2F;chroot.2.html" rel="nofollow">http:&#x2F;&#x2F;man7.org&#x2F;linux&#x2F;man-pages&#x2F;man2&#x2F;chroot.2.html</a><p>&gt; This call changes an ingredient in the pathname resolution process and does nothing else.<p>&gt; It is not intended to be used for any kind of security purpose, neither to fully sandbox a process nor to restrict filesystem system calls.<p>&gt; In particular, the superuser can escape from a &quot;chroot jail&quot; by doing: mkdir foo; chroot foo; cd ..<p>&gt; However, if a folder is moved out of the chroot directory, an attacker can exploit that to get out of the chroot directory as well. The easiest way to do that is to chdir(2) to the to-be-moved directory, wait for it to be moved out, then open a path like ..&#x2F;..&#x2F;..&#x2F;etc&#x2F;passwd.<p>EDIT: Fixed link to a more up-to-date man page. They explicitly call this out as not being a security feature in the updated man page.
评论 #20969602 未加载
评论 #20969593 未加载
评论 #20970461 未加载
评论 #20969587 未加载
评论 #20969615 未加载
Tepix超过 5 年前
If an unprivileged process can gain super user privileges, you have a problem. This applies to both situations with chroot and those without chroot.
darren0超过 5 年前
To understand just how trivial it is to escape a chroot with root, just run &quot;nsenter -m -t $$&quot; and your out.
评论 #20972824 未加载
naranha超过 5 年前
Is systemd-nspawn more secure?
评论 #20972379 未加载
test124超过 5 年前
Not really.