UNIX 소켓에는 일반적으로 피어 프로세스를 인증하는 메커니즘이 있습니다. 하지만 오프핸드 공격을 혼동하지 않도록 주의하세요.
SO_PASSCRED예 를 들어 Linux에는 UNIX 소켓을 통해 자격 증명을 전달하는 두 가지 방법이 있습니다 SO_PEERCRED. SO_PEERCRED스트림 소켓만 지원되며 socketpair(2)사용자 ID는 유효한 자격 증명에서 파생되어 소켓을 연결하거나 소켓 쌍을 생성할 때 수정됩니다.
SO_PASSCRED반면에 각 메시지마다 다시 생성되며 기본적으로 실제 자격 증명에서 파생됩니다. FreeBSD에는 비슷한 API가 있지만 세부 사항은 다릅니다.
일반적으로 프로세스에서 사용하는 소켓은 프로세스에서 생성되거나 상위 프로세스에서 상속되거나 UNIX 소켓을 통해 전달됩니다. 소켓이 프로세스에 의해 생성된 경우 프로세스는 소켓을 안전하게 사용하는 책임을 명시적으로 맡을 수 있습니다. 상속되고 전달된 소켓의 경우 SO_PEERCRED자격 증명이 작성자로부터 파생되므로 특별한 문제가 발생하지 않습니다.
SO_PASSCREDwrite(2)프로세스 호출이 자신이 생성하거나 연결하지 않은 소켓을 통해 자신의 자격 증명을 실수로 전달할 수 있으며 작성된 메시지를 작성자가 제어할 수 있는 경우가 종종 있다는 문제가 있습니다 . 상속된 소켓의 경우 setuid/setgid 프로세스는 상위 프로세스와 다른 자격 증명을 가지지만 전달된 자격 증명은 프로세스의 실제 자격 증명을 기반으로 하므로 상위 프로세스는 승격된 프로세스의 자격 증명을 사용할 수 없습니다.
반면에 UNIX 소켓이 UNIX 소켓을 통해 전달되는 경우 수신자는 승격된 실제 자격 증명을 가질 수 있습니다. 이 경우, write(2)데몬이 피어를 인식하지 못하더라도 소켓을 수신하는 데몬이 속아 들어갈 수 있습니다.
자격 증명의 오용을 방지하려면 어떤 예방 조치를 취할 수 있습니까? 신뢰할 수 없는 소켓을 데몬에 안전하게 전달할 수 있습니까?
SO_PEERCRED서비스는 가능할 때마다 사용해야 합니다.- 데몬이 소켓을 수신하도록 의도되지 않은 경우
fstat(2)수신된 파일 설명자를 수신하고 유형을 확인해야 합니다. - 권한이 있는 데몬은
SCM_CREDENTIALS신뢰할 수 없는 소켓으로 보낼 때 명시적으로 메시지를 추가하고 권한이 없는 사용자 ID를 사용할 수 있습니다. - 서비스는
SO_PASSCRED단순write(2)자격 증명이 사용하기에 유효하지 않은지 확인하기 위해 인증합니다. 예를 들어, 보조 메시지가 필요할 수도 있고 혼란스러운 담당자가 따를 가능성이 적은 다중 왕복 프로토콜이 필요할 수도 있습니다.
일반적으로 사용되는 데몬은 이 문제를 어떻게 해결합니까?