나는 다음 질문을 읽었습니다 (쉘 스크립트 mktemp, 임시 명명된 파이프를 만드는 가장 좋은 방법은 무엇입니까?) 하지만 프로그램 간에 민감한 데이터를 전송하기 위해 임시 명명된 파이프를 사용하는 것이 명명되지 않은/익명 쉘 파이프를 사용하는 것보다 나은지 궁금합니다.
특히 저는 이런 유형의 접근 방식에 관심이 있습니다.http://blog.kdecherf.com/2012/11/06/mount-a-luks-partition-with-a-password-protected-gpg-encrypted-key-using-systemd/) 는 안전하다:
# Open the encrypted block device
gpg --batch --decrypt $key_file 2>/dev/null | sudo $CRYPTSETUP -d - luksOpen $mount_device $key >& /dev/null || exit 3
어떤 상황에서 Luks 키 파일이 하이재킹될 수 있나요?
답변1
제안한 명령줄은 안전합니다.
다른 모든 조건이 동일할 경우 "일반적인" 익명 파이프(시스템 pipe(2)호출 또는 셸의 친숙한 |구문을 사용하여 생성됨)는 항상 명명된 파이프보다 안전합니다. 시스템 외부의 다른 항목이 파이프의 끝에 도달할 수 있는 방법이 적기 때문입니다. 일반 익명 파이프를 사용하면 파이프의 파일 설명자를 이미 소유한 경우에만 파이프에서 읽거나 쓸 수 있습니다. 즉, 파이프를 생성한 프로세스이거나 해당 파이프에서 파이프를 (직접 또는 간접적으로) 상속해야 함을 의미합니다. 프로세스 또는 파일 설명자가 있는 일부 프로세스가 의도적으로 소켓을 통해 이를 보냅니다. 명명된 파이프의 경우 파이프의 파일 설명자가 아직 없으면 이름으로 열어 파이프의 파일 설명자를 가져올 수 있습니다.
Linux와 같은 운영 체제에서는 /proc다른 프로세스가 다른 프로세스에 속한 액세스된 파일 설명자를 엿볼 수 있는 가능성이 항상 있지만 /proc/pid/fd이는 파이프(모든 유형)에 고유하지 않으며 해당 지점까지 엿볼 수 있습니다. 공간도 그렇고. Peeper는 테마 또는 루트와 동일한 사용자로 실행되어야 하므로 이는 보안 문제가 아닙니다.
답변2
Linux의 파이프는 /proc/$pid/fd/$thePipeFd마치 파이프 작성자가 생성한 연결 해제된 fifo인 것처럼 가로챌 수 있습니다(umask가 적용된 것 같은데요?).
루트가 아닌 쉘에서 실행하는 경우 파이프의 읽기 끝에서 fd를 찾아 데이터를 얻은 다음 데이터를 다시 작성하여 엿보는 눈으로부터 숨길 수 있습니다.
/proc/sys/kernel/yama/ptrace_scope프로세스가 개인 데이터를 저장하기 위해 파일 시스템을 사용하지 않는 경우에도 프로세스는 동일한 uid를 가진 프로세스로부터 개인 정보 보호를 기대합니다(관련 없는 프로세스에서 허용하는 ptrace 첨부 파일을 전달하지 않는 한).
불행하게도 Linux의 파이프는 링크되지 않은 파일이 있는 파일 시스템을 사용하는 것과 동일해 보입니다.
socketpair나는 더 안전한 대안이 있어야 한다고 믿습니다 pipe(). 노출되기는 하지만 파일에 /proc/$pid/fd/$sockeFd액세스하는 것은 파일을 통해 작동하지만 소켓을 사용할 수 없습니다(다시 생성된 연결되지 않은 이름의 unix 소켓을 통해 연결하면 연결되지 않은 소켓 연결에 대한 바인더가 제공되지 않습니다)./proc/$pid/fd/openopen
(보안을 강화하려면 socketpair메시지와 함께 pid를 보조 자격 증명으로 보내 부모와 자식 간의 통신을 더욱 강화해야 하지만 이는 필수 사항이 아닙니다. IMO입니다.)
또는 공유 익명 메모리도 작동해야 하지만 이는 쉘에 잘 매핑되지 않습니다(이를 수행할 수 있는 바이너리를 만들 수 있습니다 ./socketline 'command0 ...' \| 'command1 ...' \| 'command 2...').