LWN: Comments on "Anatomy of a user namespaces vulnerability"

Setting protected *links

mathstuf — 2013-04-05T21:11:17+00:00

You could also drop a file in /etc/sysctl.d/99-jed.conf file instead of conflicting with package manager-controlled files.

Setting protected *links

Duncan — 2013-04-02T06:23:49+00:00

> # cat /proc/sys/fs/protected_hardlinks
> 0
>
> Where to enable this option permanently?

Assuming fedora has the common sysctrl initscript/unitfile, along with the associated /etc/sysctrl.d/* and/or /etc/syctrl.conf, you'd set it there (omitting the /proc/sys bit as that's the normal working dir for this unit/script).

As I follow upstream kernel development reasonably closely on both LWN and independently (running a custom configured Linus git kernel), I saw the feature introduced for kernel 3.7, and added entries to my sysctrl.conf file appropriately (JED are my initials, used to distinguish my own modifications, $>> is the non-root version of the last line of my custom-set $PS1 bash prompt (#>> would indicate root, appearing as green on red so there's no mistaking it):

$>>grep protected /etc/sysctl.conf
# JED: protected sticky/tempdir symlinks/hardlinks (kernel 3.7+)
fs.protected_symlinks = 1
fs.protected_hardlinks = 1

Duncan

Complexity

luto — 2013-03-25T18:46:32+00:00

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.)

Complexity

talex — 2013-03-25T11:00:27+00:00

> 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

dlang — 2013-03-25T10:17:29+00:00

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

talex — 2013-03-25T09:42:03+00:00

> 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:
http://thread.gmane.org/gmane.comp.file-systems.zero-inst... )

> 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.

Anatomy of a user namespaces vulnerability

rahulsundaram — 2013-03-24T17:47:47+00:00

It is enabled in Fedora 19 by default and I am not sure there is a list of options documented that can be enabled in general. If they were, they probably would be there by default anyway.

Anatomy of a user namespaces vulnerability

meyert — 2013-03-24T16:40:18+00:00

Is there actually a list of options that better where enabled in Fedora, from a security point of view? like this other one I know about:
https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace

Anatomy of a user namespaces vulnerability

meyert — 2013-03-24T16:38:08+00:00

So, why isn't this set to "enabled" on current Fedora 18?

# cat /proc/sys/fs/protected_hardlinks
0

Where to enable this option permanently?

Anatomy of a user namespaces vulnerability

kleptog — 2013-03-24T11:36:16+00:00

Given the complexity of the feature, it's unfortunate no-one specialising in making such exploits offered to test or tested the code prior to it being shipped.

It would of course be cynical to suggest that it's because finding exploits in released kernels gets more credits that finding exploits in code under development.

Complexity

dlang — 2013-03-22T18:41:34+00:00

> 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

jezuch — 2013-03-22T08:48:44+00:00

> 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

dlang — 2013-03-21T22:58:27+00:00

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

wahern — 2013-03-21T22:49:22+00:00

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

dgc — 2013-03-21T21:05:04+00:00

> 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

butlerm — 2013-03-21T16:52:34+00:00

> 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

dpquigl — 2013-03-21T14:36:45+00:00

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

Tobu — 2013-03-21T10:48:51+00:00

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

lkundrak — 2013-03-21T07:42:47+00:00

I'm curious, which ones they are?

Typos and such

epa — 2013-03-21T05:41:16+00:00

The comment form lets you choose plain text or HTML. It should also let you choose 'comment' or 'correction'. If a correction is posted when the LWN staff are not around it can be displayed with the comments until an editor has the chance to act on it.

Complexity

dgc — 2013-03-21T05:33:08+00:00

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.

Anatomy of a user namespaces vulnerability

dlang — 2013-03-21T00:57:55+00:00

I also wonder about these 'odd' combinations.

One thing I've found is that any time I tend to think "there's no reason for anyone to use _that_ combination", someone ends up running into a case where it's exactly the right thing to use.

You almost need these things to be configurable. The problem is in figuring out how to do that without imposing unacceptable overhead in every fork() call.

I wonder if the 'traditional' flags and combinations could be whitelisted into a very fast special case, and combinations that use the new flags/features branch off to a more flexible/detailed set of checks that may be a bit slower.

Anatomy of a user namespaces vulnerability

butlerm — 2013-03-21T00:13:19+00:00

Wouldn't the combination of CLONE_NEWUSER and about half of the other CLONE_xxx options lead to potential security risks as well? After all one may request that processes in two completely different security contexts should share things they probably shouldn't - signal handlers, thread groups, memory spaces, SYS V semaphores, and so on.

It is hard to see how most of that could possibly be useful in such a combination, and some of it looks positively dangerous. And if that is the case, wouldn't the conservative option be to disable the combination of CLONE_NEWUSER with everything that isn't recognized as necessary and/or useful?

Perhaps it might also be worthwhile to consider renaming the CLONE_xxx options to clearly indicate which options actually clone things, which ones share things, and which ones create new things. With aliases for backward compatibility of course.

Typos and such

corbet — 2013-03-20T23:05:32+00:00

It's been a while since we've needed to remind folks of the line of text right above the comment box:

Please do NOT post typos in the article as comments, send them to lwn@lwn.net instead.

The alternative is to clutter the comment stream with stuff that persists long after the error is fixed and benefits nobody.

Anatomy of a user namespaces vulnerability

adler187 — 2013-03-20T22:57:06+00:00

Also, grammar issue in the last sentence before "The Fix" section:

"... user namespaces are unlikely to enable user namespaces in the kernels that they ship."

Anatomy of a user namespaces vulnerability

Celest — 2013-03-20T22:51:36+00:00

Typo: user namespaces are unlikely to enable user namespaces -> the first "user namespaces" should be replaced by "distributors" I suppose.

Great article. I really enjoy reading exploit walkthrough especially this one since it relates to namespace. Thanks!

Complexity

smurf — 2013-03-20T22:35:43+00:00

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.

Anatomy of a user namespaces vulnerability

mkerrisk — 2013-03-20T21:48:48+00:00

> Typo in the first sentence: March 13th, not Feb 13th.

Fixed.

Anatomy of a user namespaces vulnerability

luto — 2013-03-20T21:45:12+00:00

If you enjoy thinking about security, please look at this stuff. It's really neat, but there is certainly lots of room for bugs.

(I'll publicly post at least two more of varying severities once there are patches.)

Anatomy of a user namespaces vulnerability

spender — 2013-03-20T21:28:02+00:00

Typo in the first sentence: March 13th, not Feb 13th.

-Brad