sandbox: Spit out some info when unsharing userns gets EPERM

[bjackman]

To try and minimise the pain of this issue
(#3265), dump some info that might help users resolve it.

I had a quick look around expecting to find a document from Red Hat discussing this topic much like the Ubuntu one I've linked here, but I didn't find it. Hopefully if it exists someone else can add it later.

[DaanDeMeyer]

The check should be done in become_user(), not in unshare(). You can catch the exception there and handle it in the same way.

[bjackman]

The check should be done in become_user(), not in unshare(). You can catch the exception there and handle it in the same way.

Ah sorry didn't see this - see my other comment thread: #3266 (comment)

I haven't bothered to comprehend the Ubuntu/AppArmor details here but the high level (which I am already appraised of due due to my day job) is: creating user namespaces itself is harmless. The issue is that then you have CAP_SYS_ADMIN and that gives you access to buggy kernel code in resources that are within other namespaces. So, we only actually need to prevent the next step where you access that buggy code. So I guess Ubuntu is doing something like "you can create the userns, but you can't create the mount/net ns inside it". Ideally it would go more like "you can create the mount ns too, but you can't mount a block filesystem/create a netfilter rule", but AFAIK that's just not really possible with the kernel's namespace/capability infra.

I think there's some risk that on some system this issue might not manifest in unshare at all, but I would say it's better to wait and address that issue if it actually arises.

but you can't mount a block filesystem

(Oh actually I think that specific case might already be true - block fs maintainers are under no illusion that their code is safe against arbitrary fs images!)

[DaanDeMeyer]

What I'm saying is that unshare() is a generic function and shouldn't contain such specific error handling. So please move the error handling to the call of unshare() that actually fails. Whether that's the initial user namespace unsharing of something after that (or both).

[bjackman]

So please move the error handling to the call of unshare() that actually fails.

Sure, done

[DaanDeMeyer]

Is this really the only one that can fail due to permission issues? Or is this only when apparmor fails? What about if the sysctls are enabled?

[bjackman]

Just noticed my Ubuntu system has the kernel.unprivileged_userns_clone patch, so I tried that out. And indeed if I set that to 0 the failure happens in become_user. So I've just duplicated the logic there.

I think this could easily happen in a third place too, we probably can't make this foolproof, even if we just do it inside unshare. (E.g. I know of a certain Linux version that "solves" this problem in a third way that is neither kernel.unprivileged_userns_clone nor an LSM policy, I dunno where mkosi would fail on that system, I can't easily test it or share the details either).

[bjackman]

Been a long time since I did any real work in the GitHub UI, it's got fancy new features (they still haven't fixed isaacs/github#386 though??), LMK if I'm doing anything stupid here.