Created attachment 146831 [details] sandbox This behaviour is actually sort of convenient and maybe should come back in a different form but as of now is insecure. Suppose, a highly paranoid developer sets their process not dumpable because they are paranoid. Then suppose that they sandbox their process because they are even more paranoid. The two features are good but together their is a bug where the sandboxed process can be ptraced from processes outside of the sandbox. Attached is a program that sets itself nondumpable and sandboxes itself. You can verify for yourself that it is possible to ptrace it. Luckily, sandboxing is a fairly recent feature so this particular scenario probably hasn't happened out in the wild yet.
Preventing sandboxes being monitored from outside would prevent detection of attacks and the like. A sandbox does not protect you from outside the sandbox nor can it.
So packages like OpenSSH can't sandbox their networking facing code that faces a lot of attack and protect their important secrets at the same time? I see your reasoning about how this ability could let attackers defend themselves from monitoring programs though. However, I think that the power of defending against ptracing and such is a logically separate capability from CLONE_NEWUSER or CLONE_NEWPID. Regardless, even if this stays as WONT_FIX then this is still a documentation bug. There is nothing in the manpages suggesting that this weakness would happen when the sandboxing and dumpable bit features are combined.
If I am outside the sandbox then I can equally patch the kernel if I have all the rights I need. You either need everything sandboxed or you need a trusted element (TPM, smartcard etc) to do the crunching and keep the secrets. I don't think the docs are unclear but I'll move it to man pages
Actually, certain system configurations prevent patching the kernel as root. As well, most processes should not be run as root or with the system capabilities that allow one to patch the kernel. But the situation I am thinking of is that a normal user (let us call him "bob") connects to a remote server using private information. This private information is somehow protected (perhaps it is owned by a user or is stored on an external device). bob's SSH program has the capability or permissions to connect to or retrieve the protected secrets and once it has acquired the secrets sets itself nondumpable and then lowers it's capabilities to normal user permissions (to prevent a hacker infecting the process and gaining access to the secrets). This situation works fine but currently if the additional step of sandboxing subprograms of the SSH process is added in then normal processes of bob can ptrace and otherwise attack the sandboxed SSH processes and possibly gain access to the private secrets. From there, those normal bob owned processes can gain access to the server bob is connecting to.
This is documented. See user_namespaces.7: 3. When a user namespace is created, the kernel records the effective user ID of the creating process as being the "owner" of the namespace. A process that resides in the parent of the user namespace and whose effective user ID matches the owner of the namespace has all capabilities in the namespace. So, a process outside the namespace with the same EUID as the process that moved itself into a new namespace has CAP_SYS_PTRACE inside the namespace. And as capabilities.7 documents: CAP_SYS_PTRACE * Trace arbitrary processes using ptrace(2);
For a process that wants to drop privileges and enter a new user namespace for security, it might make sense to first set up the namespace as uid 0, with all UIDs mapped, and then drop privileges inside the user namespace.
Jann Horn doesn't that require root privileges or certain capabilities? My whole scenario starts from a nonroot application that sandboxes itself. I suppose one could argue that one should use a setuid shim or invoke a daemon that has root privileges such as systemd for these kinds of purposes though.
Right, that would require root privileges. Might be nice to have some new clone() flag to disable that or so - but that's not a man-pages bug.
Okay, so four things: - An unprivileged process that sandboxes itself can't also protect against ptrace. - For some reason, commenters here seem to feel that they don't want to support this use-case or feel that it isn't useful. - This annoyance was not documented at the time I made this bug report. - It appears to be documented now. If kernel coders really feel that this use-case isn't useful then I guess they should close this bug report then.
Closing this, as the behavior is documented in the man pages.