| |||||||||||||
ComplexityComplexityPosted Mar 21, 2013 22:49 UTC (Thu) by wahern (subscriber, #37304)In reply to: Complexity by Tobu Parent article: Anatomy of a user namespaces vulnerability
chroot does reduce the attack surface, considerably.
No more setuid issues.
No more /tmp race conditions.
No more /dev.
No more /proc.
No more /sys.
No more playing with named pipes or unix domain sockets owned by privileged processes.
I'll never understand the attitude of "chroot isn't enough; let's instead add a layer of incredibly complex policy, and tens of thousands of lines of new code to the kernel". Yeah.. that's much better....
It wasn't but a few years ago that one could confidently say that Linux shook the bugs out of simple stuff like file permissions, including setuid linker issues, and run-of-the-mill data races. Now we're adding a whole new set of incredibly complex subsystems and interfaces, and _willingly_ putting everybody through the grinder all over again.
(Log in to post comments)
Complexity Posted Mar 21, 2013 22:58 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the problem with chroot has been that it's not perfect.
Root can mount things inside the chroot, create device files, etc and so it's possible for someone to escape out of a chroot after they become root.
I've never bought into the 'this makes chroot worthless' mantra, it may only slow an attacker, but slowing an attacker can still be valuable.
If these namespaces could only be setup by root, we would not really be any worse off, but since people are so fascinated by the "my admin won't let me do X, so I'm going to figure out a way to do it anyway" problem that they are giving too much power to non-root users.
If you admin doesn't want to let you do something, go use a different box (including one where you are the admin), don't engineer a way around the admin's restrictions.
Complexity Posted Mar 22, 2013 8:48 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> the problem with chroot has been that it's not perfect.
The problem with chroot, as I was told, is that it is not and has never been a security mechanism.
Complexity Posted Mar 22, 2013 18:41 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> The problem with chroot, as I was told, is that it is not and has never been a security mechanism.
It depends on how you define 'security mechanism'
chroot has always provided security in that processes in a chroot in that it prevented that process from accessing any files outside that chroot.
This doesn't mean that this security couldn't be bypassed (if you could get root inside the chroot), but if you did not have root in the chroot, it helped.
for example, if a server had a vulerability that allowed it to access arbitrary files on the filesystem, putting it in a chroot can be very useful.
Complexity Posted Mar 25, 2013 9:42 UTC (Mon) by talex (subscriber, #19139) [Link]
> Root can mount things inside the chroot, create device files, etc and so it's possible for someone to escape out of a chroot after they become root.
As I understand it: with user namespaces, *anyone* can escape from a chroot. At least, that seemed to be the case when I tested it (I was experimenting with using namespaces to sandbox some aspects of 0install:
> If these namespaces could only be setup by root, we would not really be any worse off, but since people are so fascinated by the "my admin won't let me do X, so I'm going to figure out a way to do it anyway" problem that they are giving too much power to non-root users.
The problem with that (only making security features available to root) is that then prorgammers can't use them. For example, 0install needs to unpack archives it downloads. Since tar may contain bugs, we'd like to run tar in a restricted environment (e.g. a chroot where /home doesn't exist). If that requires root, then 0install itself has to be setuid, which is not good.
Complexity Posted Mar 25, 2013 10:17 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
why should you be able to install new software on the system without the permission of the admin of that system?
if 0install needs to run tar as root to install it's applications, and you don't want to trust tar as root, then you shouldn't trust it. untar the files as the user and then change their permissions afterwords.
And if you think that users should be able to change the ownership of files to be other users without requiring some sort of privilege, you just don't understand the concepts.
Namespaces makes it possible to escape from a chroot, because they let the user become root inside a changeroot.
But namespaces are intended to replace chroot, so you would not be likely to use chroot and namespaces together.
now, once distros start enabling all these namespaces by default, they end up weakening the security of anything that's using chroot, but if a distro is doing that, the distro should be changing the programs to be locked down via namespaces limitations instead
nobody should be using Fedora in production, it's bleeding edge, and exposing this sort of security problem where namespaces interact badly with each other and with other features is exactly the sort of bleeding that such a distro produces.
Complexity Posted Mar 25, 2013 11:00 UTC (Mon) by talex (subscriber, #19139) [Link]
> why should you be able to install new software on the system without the permission of the admin of that system?
That's just the way Linux works. Any user can cause executable files to be written to their home directory, and can then run them. But, like most people, I am the admin of my computer, so I don't need to ask anyone's permission to install software.
> if 0install needs to run tar as root to install it's applications, and you don't want to trust tar as root, then you shouldn't trust it. untar the files as the user and then change their permissions afterwords.
0install doesn't run tar as root. It runs it as my normal user. But that's still more privileges that I'd like to give it.
For example, let's say I'm installing OpenTTD. Currently, 0install downloads the archive as my user (talex), unpacks it, verifies it, and runs it. OpenTTD does not gain root privileges on my system, but it does run with my user privileges. I'd like to restrict it further so that, for example, it can't read or write to my home directory (or anywhere except it's own data directory).
> But namespaces are intended to replace chroot, so you would not be likely to use chroot and namespaces together.
So, what is the replacement for chroot in the new namespaces world then? Should I unmount all existing filesystems and mount something new over the real root? I'm not sure how to do that.
Complexity Posted Mar 25, 2013 18:46 UTC (Mon) by luto (subscriber, #39314) [Link] Chrooting to an empty, unwritable directory, closing fds and dropping privileges denies useful filesystem access. A kernel that suddenly changes that is not okay and should be fixed. (And that's one of the bugs I found. Guess I might as well make the whole thing public.)
|
|||||||||||||