nosuid가 VPN 도우미의 root 전환을 막는 이유

디스크 암호화와 nosuid 마운트는 같은 발상의 변형처럼 들리지만 서로 아무런 관련이 없습니다. 하나는 저장 상태의 데이터를 보호하고, 다른 하나는 프로그램이 시작되는 순간 커널이 권한 비트를 존중할지 결정합니다. 기대하는 정체성에 도달하지 못하는 도우미는 두 번째 문제를 호소하는 것입니다. 첫 번째가 원인이라는 가정이 사람들을 고장 난 적도 없는 클라이언트를 다시 설치하러 보냅니다.

서로 무관한 두 속성

디스크 암호화는 기계가 꺼져 있을 때 누가 블록을 읽을 수 있는지에 답합니다. 마운트 옵션은 누군가 파일을 실행할 때 커널이 그 모드 비트로 무엇을 할지에 답합니다. 첫 번째는 두 번째를 전혀 제약하지 않으며, 완전히 암호화된 노트북도 모든 제한이 걸린 파일 시스템을 마운트할 수 있습니다.

둘을 하나의 속성으로 읽는 것이 암호화된 홈이 root 접근을 막는다는 이론을 만들어 냅니다. 그 이론이 살아남는 이유는 두 증상이 같은 기계에서 나타나기 때문이며, 원인을 공유하기 때문은 아닙니다.

실제로 전환을 억제하는 것

execve 문서는 set-user-ID 실행 파일이 새 프로세스의 유효 정체성을 파일 소유자로 바꾸는 방식을 설명합니다. 같은 페이지에는 그 전환을 억제하는 조건과 그룹 ID에 대한 동등한 조건, 즉 no_new_privs 설정, nosuid로 마운트된 파일 시스템, 추적 중인 프로세스가 나열되어 있습니다. 파일 기능도 같은 조건에서 무시됩니다. 이 네 가지 규칙이 이런 종류의 보고 대부분을 설명합니다.

그 목록은 ls가 출력하는 모드가 결코 권한 부여의 전부가 아닌 이유를 설명합니다. 어느 조건이 특정 실패 메시지를 일으켰는지는 알려 주지 않으며, 애플리케이션이 같은 문구로 무관한 자격 증명 작업을 보고하고 있을 수도 있습니다. 결론을 내리기 전에 정확한 프로그램, 실행기, 오류 순서를 기록하십시오.

지원 패키지가 설치한 실행 파일, 그 소유자, 실제 경로, 그리고 그것을 담고 있는 파일 시스템의 정책을 확인하십시오. 다운로드 폴더에 있는 사본은 모드가 무엇이라 하든 설치된 도우미가 아닙니다.

하지 말아야 할 일

검증되지 않은 바이너리에 set-user-ID 비트를 붙이고 제한이 사라질 때까지 옮겨 다니는 것은 수리가 아닙니다. 이해하지 못한 정책을 감사할 수 없는 권한으로 바꾸는 것이며, 도우미에 같은 수법을 쓰는 것은 잘 알려진 권한 상승 경로입니다. 마운트에서 nosuid를 제거하는 것은 그 파일 시스템의 모든 프로그램에 영향을 주며 하나에만 그치지 않기 때문에 더 나쁩니다.

지원되는 방법은 관리자가 수행하는 클라이언트의 문서화된 도우미 또는 서비스 설치이며, 정책이 기대하는 위치에 바이너리를 둡니다. 이렇게 하면 권한 메커니즘이 둘이 아니라 하나로 유지됩니다.

실제 실행 컨텍스트 확인

승인된 수정 후에는 root 셸이 아니라 제품이 실행하는 방식으로 도우미를 실행하십시오. root로서의 성공은 일반 사용자가 지나는 경로에 대해 아무것도 증명하지 않으며, 이 두 컨텍스트의 차이가 바로 실패의 주제였습니다.

그다음 도우미가 존재하는 이유인 네트워크 작업을 확인하십시오. 시작되지만 인터페이스를 구성할 수 없는 도우미는 문제를 한 단계 뒤로 미뤘을 뿐 해결하지 못했습니다.

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

마운트 옵션과 도우미의 소유권을 같은 메모에 기록하십시오. 그렇지 않으면 이 일을 디버깅할 다음 사람이 암호화 이론을 처음부터 다시 반복하게 됩니다.