Ubuntu 14.04 strace에서 실행 파일을 사용할 때 몇 가지 놀라운 동작을 발견했는데 실행 파일에 대한 읽기 권한이 없습니다. 이것이 버그인지 아니면 일부 표준에서 이러한 모호한 동작을 요구하는지 궁금합니다.
먼저 백그라운드에서 일반 실행 파일을 시작하고 이에 연결할 때 어떤 일이 발생하는지 살펴보겠습니다. 예상대로 작동합니다.
$ /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에서 테스트되었으므로 이는 기본 커널과 다를 수 있습니다. 다시 말하지만, 편리한 곳에서는 기본 커널을 실행하지 않습니다. :()