| |||||||||||||
ComplexityComplexityPosted Mar 20, 2013 22:35 UTC (Wed) by smurf (subscriber, #17840)Parent article: Anatomy of a user namespaces vulnerability
Complexity is not the root problem.
The root problem is that previously, once you gained root you had the master keys to the whole system. Game over. Now, anybody can create their personal little sandbox and you need to vet *every* activity to make sure that it doesn't spill over. That's something that Linux historically didn't do (no need); no wonder that a few cases which fell through the cracks.
… and chroot() has a history of being a security loophole anyway.
(Log in to post comments)
Complexity Posted Mar 21, 2013 5:33 UTC (Thu) by dgc (subscriber, #6611) [Link]
Yup, consider that there are some filesystem APIs that allow root to have r/w access to all inodes and their attributes in a filesystem because they bypass the filesystem namespace altogether...
-Dave.
Complexity Posted Mar 21, 2013 7:42 UTC (Thu) by lkundrak (guest, #43452) [Link]
I'm curious, which ones they are?
Complexity Posted Mar 21, 2013 14:36 UTC (Thu) by dpquigl (subscriber, #52852) [Link]
I'm actually confused as to what his statement is to begin with. Root by virtue of having privileged access can do whatever it wants to any file assuming you don't bring capabilities or other access controls into the picture. Saying root has access to read/write to any inode or change any attributes is a vacuous statement since root can open any file in the filesystem read/write to begin with by virtue of being root. You don't need special APIs for that you just use open. Maybe he's talking about debug file systems or tools that are available for certain file systems like XFS that let you manipulate the inodes of a filesystem directly?
Complexity Posted Mar 21, 2013 16:52 UTC (Thu) by butlerm (subscriber, #13312) [Link]
> Root by virtue of having privileged access can do whatever it wants to any file
Isn't "root" now an ambiguous term? Don't we now have local root and global or system root? We certainly don't want local root to have privileges to do things like open arbitrary files by inode number. For filesystems the local root mounted or owns perhaps, but certainly not with regard to filesystems mounted by system root or other local root users.
Unless the idea is to adopt the convention that "root" always refers to system root, and never to local root without further qualification, any such reference is likely to lead to some considerable degree of confusion. This thread is a perfect example.
Complexity Posted Mar 21, 2013 21:05 UTC (Thu) by dgc (subscriber, #6611) [Link]
> Maybe he's talking about debug file systems or tools that are available
> for certain file systems like XFS that let you manipulate the inodes > of a filesystem directly?
File handles are the problem. And when combined with interfaces like bulkstat, you've got a capability to find, open and *invisibly modify* any file in the filesystem regardless of namespace restrictions...
http://oss.sgi.com/archives/xfs/2013-03/msg00382.html
-Dave
Complexity Posted Mar 21, 2013 10:48 UTC (Thu) by Tobu (subscriber, #24111) [Link] chroot doesn't reduce the attack surface much because there's still the whole kernel, but I wouldn't call it a loophole. It's just a user namespaces forerunner, which should be combined with seccomp or similar if one wants a strong security boundary. suid on the other hand is an attractive nuisance: a simple design, but every privileged process that uses it has to be paranoid about its entire environment.
Complexity Posted Mar 21, 2013 22:49 UTC (Thu) by wahern (subscriber, #37304) [Link]
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.
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.)
|
|||||||||||||