跟踪没有读取权限的可执行文件

跟踪没有读取权限的可执行文件

当我在 Ubuntu 14.04strace上使用可执行文件时,我发现了一些令人惊讶的行为,而我没有对该可执行文件的读取权限。我想知道这是否是一个错误,或者是否某些标准强制要求这种模糊的行为。

首先让我们看看当我在后台启动一个普通的可执行文件并附加到它时会发生什么。正如预期的那样,这有效:

$ /bin/sleep 100 &
[2] 8078
$ strace -p 8078
Process 8078 attached
restart_syscall(<... resuming interrupted call ...>

接下来我尝试使用一个可执行文件,但我没有读取权限:

---x--x--x 1 root root 26280 Sep  3 09:37 sleep*

不允许附加到此正在运行的进程:

$ ./sleep 100 &
[1] 8089
$ strace -p 8089
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

这也是我所期待的。如果我可以简单地将调试器附加到进程并以这种方式有效地拥有可执行文件的读取权限,那么在没有读取权限的情况下授予执行权限不会有太大作用。

但是,如果我在已跟踪的进程下启动可执行文件,我可以这样做:

$ strace ./sleep 100
execve("./sleep", ["./sleep", "100"], [/* 69 vars */]) = 0
brk(0)                                  = 0x9b7a000

这对我来说是出乎意料的。这是一个安全错误,还是标准强制要求的功能?

答案1

这不是一个答案,而是链接和想法的集合,以防其他人也想学习。因为这是一件非常有趣的事情。

Unix&Linux 上的相关答案提到它(或者曾经是,现在无法使用普通内核进行测试)可以通过这种方式转储只读二进制文件。

Grsecurity 正在尝试解决此问题配置选项补丁本身(尽管此后可能有所改变)

这次提交确实让人觉得内核开发人员真的只关心转储 suid 二进制文件。

但其实从这线我猜测内核想要阻止转储不可读的二进制文件,无论 SUID 状态如何。和这个线建议不可转储的二进制文件不应被追踪。

因此乍一看,您似乎发现了内核中存在安全隐患的错误。但我不是内核开发人员,所以我不能肯定地说。我想在 LKML 上问。

编辑:关于调试器的另一个发现,在原始帖子的评论中提到 - 从快速跟踪(再次)在我看来,gdb 使用跟踪的二进制文件和/proc/<pid>/mem.一旦运行的二进制文件不可读,cat /proc/<pid>/mem则返回EPERM。如果二进制文件可读,则返回EIO。 (在 Ubuntu 14.10 上进行了测试,它运行多个安全补丁,因此这可能与普通内核不同。同样,我没有在任何方便的地方运行普通内核:()

相关内容