Arch Linux

You can set /proc/sys/kernel/yama/ptrace_scope to 0 if you don't want this security feature. SYS_CAP_PTRACE allows tracing arbitrary processes, which is totally unsafe.

Setting SYS_CAP_PTRACE does not allow tracing arbitrary processes, but only processes controlled by the user. If this goes to far, the proper way to close this is to drop reptyr from the repo, since it performs absolutely no function without the capability set.

Disabling ptrace_scope just for one package is not the right way to solve this. As it stands, anyone who ever installs this package will have to set SYS_CAP_PTRACE for the binary manually, and a package update will revert this; so the sensible thing to do is either package it with the cap. set, or else drop it from the repo.

I don't really see a point in having ptrace_scope set if we're just going to allow packages like reptyr (or gdb) to mess with the internals of arbitrary processes. Yes, the process has to be controlled by the user - just as it does *without* ptrace_scope, but it defeats enabling that security feature. Being able to intercept the streams between processes is not exactly harmless - what if one of these processes is a gnupg instance spawned by a mail client?

There’s a difference between setting a per file capability and disabling ptrace_scope globally. If it makes sense to have individual packages include setuid binaries owned by root, then so does packaging binaries with cap_ptrace set.

Whatever we do here, leaving the package as it is doesn’t make much sense. It would be analogous to packaging /sbin/passwd without setuid. We should either package it with the capability set, or drop it from the repo.

It also prevents attaching strace, gdb or perf-trace to a process. It certainly makes lots of things stop working, but they aren't tools I use every day. I also don't use reptyr every day, but it's convenient to have it around for a rare case without weakening overall security by letting any process intercept the stdout/stderr/stdin of another running as the same user. Lots of programs still rely on a chroot for security without making a process namespace, so this is a *real* security vulnerability.

The difference between reptyr and gdb/strace is that the latter can perform most of their functionality without requiring ptrace’ing non-child processes. Reptyr on the other hand performs absolutely no function without this capability. If there’s genuine concern that people might install the package without knowing what it entails, then we should remove the package. On the other hand, the same argument could be made against any setuid-root binary… You also have to trust that the “shadow” package doesn’t contain malicious code, but that wouldn’t lead you to remove the setuid from /sbin/passwd.

It's not about trusting that reptyr is sound. Consider a server with two web servers, each isolated in a chroot and running as the http user. Using reptyr, one web server would be able to grab the stderr/stdin/stdout of the other. It's true that a process namespace should be used with the chroots to prevent this, but few services take advantage of namespaces at the moment and it doesn't appear that systemd provides a way to unshare the process namespace from a unit file. It's also a mistake to run both servers as the same user, but that's *very* common and Arch does this with many web services.

The reptyr utility can still be used as a superuser without the capability set. It's not suddenly useless because non-root users can't use it. Perhaps it's less useful for your case, but you can disable ptrace_scope or set the capability yourself. It could even mention ptrace_scope in the install file.

> Consider a server with two web servers, each isolated in a chroot and running as the http user. Using reptyr, one web server would be able to grab the stderr/stdin/stdout of the other.

Ah, okay, I didn’t see that before. That’s a good point and this differs from the /sbin/passwd case.

> The reptyr utility can still be used as a superuser without the capability set.

True. Not ideal, but it’s certainly outweighed by your web server argument.