가정 setuid/ setgid비트는 중요하지 않습니다. 별도의 실행 권한이 필요한 이유는 무엇입니까?
철학적으로 말하면 쓰기 권한에는 읽기 권한이 포함되고 읽기 권한에는 실행 권한이 포함된다고 생각합니다. 물론 Linux에서는 그렇지 않습니다. 때로는 유용하지만 제 생각에는 거의 없습니다. 예를 들어, 프로세스가 실행할 수 없는 파일을 읽을 수 있는 경우 프로세스가 디렉터리에 쓸 수 있는 한 간단히 파일을 디렉터리에 복사하고 실행 비트를 설정한 다음 프로그램을 실행할 수 있습니다. 실제로 읽기에는 간단한 사례 실행이 포함됩니다. 분명히 이것은 소스 파일에 setuid 비트가 있거나 프로세스가 noexec 마운트 지점에만 쓸 수 있는 경우 제대로 작동하지 않습니다.
내가 이 질문을 하는 이유는 프로세스가 exec임의의 메모리 블록에 액세스할 수 있도록 하는 Linux 시스템 호출을 구현하고 있기 때문입니다. (구체적인 사용 사례는 주 프로그램에 완전한 프로그램이 번들로 포함되어 있고 호출하기 위해 디스크에 쓰고 싶지 않다는 것입니다 execve.) 이와 같은 시스템 호출에 심각한 문제가 있습니까? 인식?
답변1
짐작할 수 있듯이 실행 권한은 권한만큼 유용하지 않습니다. 파일의 속성이 아닌 권한으로 갖는 것은 약간의 역사적 사고입니다. 그러나 한번 존재하면 사라지지 않습니다. 두 경우 모두 읽기 권한과 다른 실행 권한을 갖는 것이 중요합니다.
- 파일을 실행하면 추가 권한이 부여되는 경우 해당 특정 파일을 실행할 수 있는 사람이 중요합니다. setuid, setgid 또는 setcap 실행 파일은 누구나 읽을 수 있지만 누구나 실행할 수는 없습니다(많은 배포판에서는 setxid 파일이 기밀이 아니기 때문에 누구나 읽을 수 있습니다. 누구나 배포판에서 파일을 다운로드할 수 있습니다).
- 일부 계정은 제한되어 실행 파일에 아무것도 쓸 수 없습니다. 예를 들어, 계정은 다음에만 액세스할 수 있습니다.제한된 껍질없음
chmod또는 를 사용하여 마운트된 파일 시스템의 디렉토리에만 쓸 수 있습니다noexec. 이러한 사용자는 기존 실행 파일만 사용할 수 있습니다.
메모리에서 exec에 시스템 호출을 추가하면 제한된 계정이 임의 코드를 실행할 수 있습니다. 이는 제한된 계정을 포함하여 어디에서나 액세스할 수 있는 기본 코드 해석기를 갖는 것과 같습니다. 이는 보안 제한 사항을 위반하므로 주류 커널에서는 허용되지 않습니다. 자신의 컴퓨터에 배포할 수 있지만 그 의미를 염두에 두어야 합니다.
그러나 이미 존재하는 기능에는 많은 작업과 보안 수하물이 필요합니다. 디스크에 쓰지 않고도 코드를 실행할 수 있습니다. 디스크가 아닌 파일 시스템(예: tmpfs)의 파일에 코드를 작성하면 됩니다.
답변2
목적 중 하나인
setuid/ 무시setgid실행 비트예:- 패턴이 있는 파일 허용실행만-구현하다읽을 수 없는 파일에 액세스합니다.
귀하의 질문의 두 번째 부분과 관련하여 -
linux syscall귀하의 구현과 관련하여 :
이는 새로운 공격 소스를 생성하는 것으로 보입니다.
진지한 답변을 원할 경우 세부 정보를 제공해야 합니다(가급적이면 새 질문에).
- 어떤 종류의 논리를 구현할 것인가?
- 데이터는 RAM에 어떻게 복사되나요?
- RAM에서 코드를 실행하기 전에 API는 어떤 검사를 수행합니까?
- API도 실행될지 여부
root(따라서 잠재적으로 허용됨)권한 승격)