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

strace在可执行文件上使用时，我在Ubuntu 14.04上发现了一些令人惊讶的行为，但我没有读取权限。我想知道这是否是错误，还是某些标准规定了这种晦涩的行为。

首先，让我们看看当我在后台启动普通可执行文件并将其附加时会发生什么。正如预期的那样：

$ /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

这对我来说是意外的。这是安全漏洞，还是标准规定的功能？

permissions strace

— 卡巴斯德
source

@StéphaneChazelas：关键是他可以通过简单地将其用作strace的参数来跟踪它。根本原因似乎是在execve调用过程中，如果已经跟踪了该过程，则不会再次检查执行文件的读取权限。他的问题是这是安全性漏洞还是强制性功能（如果是后者，我仍将其视为安全性漏洞，只是规范的安全性漏洞）。

— celtschk 2014年

@celtschk，对不起，我读得太快了。

— 斯特凡Chazelas

在EPERM似乎是来自get_dumpable()（也用于检查核是否倾销是允许的，因此“dumpable”）从所谓__ptrace_may_access()的叫ptrace_attach()上kernel/ptrace.c。

— ninjalj 2014年

当程序运行时，调试器将获得足够的信息来生成包含其代码的可运行可执行文件，还是程序加载器丢弃诸如使程序实际运行所需的重定位修正之类的东西？

— supercat 2014年

@supercat据我所知，调试器可以通过所有正在执行的用户模式代码（包括重定位代码）访问单个步骤。有了这种访问级别，就可以很容易地再现正常工作的可执行文件。

— kasperd 2014年

这不是答案，而是其他人也想学习的联系和思想的集合。因为这是一件很有趣的事情。

在Unix＆Linux上的相关答案提到，有可能（或者现在无法使用香草内核进行测试）以这种方式转储只读二进制文件。

Grsecurity正在尝试修复此配置选项和补丁本身（尽管此后可能已更改）

这种提交确实使内核开发人员似乎只关心转储suid二进制文件。

但是实际上从这一行我猜想内核希望防止转储SUID状态的不可读二进制文件。此行表明不可转储的二进制文件不可追溯。

因此，乍一看，您似乎已经发现了内核中涉及安全性的错误。但是我不是内核开发人员，所以我不能肯定地说。我会问LKML。

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

— 狐狸
source