Nondumpable processes that are sandboxed with CLONE_NEWUSER can be ptraced from outside.
https://bugzilla.kernel.org/show_bug.cgi?id=82531
Alan <alan-qBU/[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|Other |man-pages
Assignee|other_other-ztI5WcYan/[email protected] |documentation_man-pages@ker
|l.org |nel-bugs.osdl.org
Product|Other |Documentation--- Comment #3 from Alan <alan-qBU/[email protected]> --- 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
Signature · 6 lines
You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
https://bugzilla.kernel.org/show_bug.cgi?id=82531
--- Comment #4 from Steven Stewart-Gallus <[email protected]> --- 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.
Signature · 6 lines
You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
https://bugzilla.kernel.org/show_bug.cgi?id=82531
Jann Horn <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected] | |et
--- Comment #5 from Jann Horn <[email protected]> --- 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);
Signature · 6 lines
You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
https://bugzilla.kernel.org/show_bug.cgi?id=82531
--- Comment #6 from Jann Horn <[email protected]> --- 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.
Signature · 6 lines
You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
https://bugzilla.kernel.org/show_bug.cgi?id=82531
--- Comment #7 from Steven Stewart-Gallus <[email protected]> --- 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.
Signature · 6 lines
You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
https://bugzilla.kernel.org/show_bug.cgi?id=82531
--- Comment #8 from Jann Horn <[email protected]> --- 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.
Signature · 6 lines
You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
https://bugzilla.kernel.org/show_bug.cgi?id=82531
--- Comment #9 from Steven Stewart-Gallus <[email protected]> --- 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.
Signature · 6 lines
You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
https://bugzilla.kernel.org/show_bug.cgi?id=82531
Michael Kerrisk <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
CC| |[email protected]
Resolution|--- |PATCH_ALREADY_AVAILABLE--- Comment #10 from Michael Kerrisk <[email protected]> --- Closing this, as the behavior is documented in the man pages.
Signature · 6 lines
You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html