내가 이해한 바에 따르면 LSM(Linux Security Module) 프레임워크에는 보안에 민감한 작업 전에 추가 보안 검사를 수행하는 기능을 등록하는 보안 모듈에 대한 콜백인 후크가 많이 있습니다.
대부분의 경우 이러한 후크는 file.
내가 이해하지 못하는 한 가지는 System V IPC API에는 후크가 있지만 해당 POSIX API에는 후크가 없는 이유입니다. 예를 들어, "모든 System V IPC 작업에 영향을 미치는" 것으로 security_ipc_permission설명되는 후크가 하나 있고 include/linux/lsm_hooks.h, 특히 각 API(예: 메시지 큐)에 대한 여러 후크가 있지만 POSIX API에 해당하는 후크는 없습니다. 수동 조사에 따르면 System V 후크는 POSIX 기능에서 사용되지 않은 것으로 나타났습니다(설명에 따르면 예상대로). 그러나 POSIX 메시지 대기열과 System V 메시지 대기열을 예로 들면, 동일한 인터페이스는 없지만 거의 동일한 기능을 제공합니다.
그래서 내 질문은: POSIX 함수에 LSM 후크를 넣지 않는 이유는 무엇입니까?
답변1
이 글을 더 빨리 게시했어야 했지만 2016년 7월 LSM 메일링 리스트 대화에서 SELinux 개발자이자 유지관리자인 Stephen Smalley로부터 몇 가지 답변을 받았습니다. 이 기간으로 인해 이 메일링 리스트에는 더 이상 아카이브가 없습니다. MARC는 메일링 리스트 보관을 중단했고 Gmane은 사업을 중단했지만 백업에서 다음 이메일을 찾을 수 있었습니다.
[로랑 조지:]
안녕하세요,
이 시리즈는 일부 시스템 호출에 LSM 후크를 추가합니다. 이러한 LSM 후크가 아직 존재하지 않는 이유를 이해할 수 없기 때문에 RFC로 만드는 것이 좋습니다. 그러나 아마도 합당한 이유가 있을 수 있으며 이에 대해 듣고 싶습니다.
첫 번째 패치는 mq_timedsend 및 mq_timedreceive에 후크를 추가합니다. mq_timedsend 및 mq_timedreceive는 POSIX 메시지 대기열을 작동하는 데 사용되는 두 가지 시스템 호출입니다. SysV 대응 msgrcv 및 msgsnd에는 LSM 후크가 있지만 mq_timedsend 및 mq_timedreceive에는 없습니다.
두 번째 패치는 시스템 호출 vmsplice, splice 및 tee의 security_file_permission에 대한 호출을 추가하고 새로운 LSM 후크 security_splice_pipe_to_pipe를 추가합니다. 이 세 가지 시스템 호출은 Linux 커널의 파이프 내부 구현을 활용하여 파이프 간 또는 파이프와 파일 간 무복사 데이터 전송을 수행합니다. 개념적으로 vmsplice, splice 또는 tee에 의해 수행되는 모든 작업은 LSM 후크가 있는 시퀀스를 읽고 쓰는 방식으로 수행될 수 있지만 이러한 세 가지 시스템 호출에는 LSM 후크에 대한 호출이 없습니다.
[스티븐 스몰리:]
나는 그것이 다음의 조합이라고 생각합니다 :
이러한 시스템 호출은 LSM 도입 이후에 추가되었으므로 원래 분석 및 계측의 일부가 아니었습니다.
POSIX mqueue는 의사 파일 시스템을 통해 구현되므로 기존 파일 기반 액세스 제어에 의해 적어도 부분적으로 재정의되므로 실제로 추가 후크가 필요한지 확실하지 않습니다.
splice() 중 비파이프라인 파일에 대한 액세스 유효성 재검사는 security_file_permission() IIUC를 호출하는 rw_verify_area()에 의해 처리됩니다. 재인증 지원은 주로 레이블 재지정 또는 정책 변경 시 파일에 대한 액세스 취소를 지원합니다.
새로운 후크를 생각해내는 것이 틀렸다는 것은 아니지만 위의 내용은 컨텍스트를 제공하는 데 도움이 될 수 있습니다.
재검증 부분에 관해서:
[로랑 조지:]
그렇다면 파이프는 일반 파일처럼 재검증이 필요하지 않으므로 성공적으로 열린 후에 검증이 필요하지 않다는 주장입니까? 당연한 말이지만, 이것이 보안 모듈 개발자들 사이의 일반적인 합의라면 LSM을 통해서는 정보 흐름 제어가 이루어질 것으로 기대하지 않는다는 뜻이다.
[스티븐 스몰리:]
아니요, 저는 일반적으로 그렇게 주장하지 않습니다. 지금까지는 이것이 큰 문제가 되지 않았습니다. 그래서 나는 후크를 추가하는 것에 반대하지는 않지만, 파일을 여는 것처럼 정보를 캐시할 수 있도록 파이프 생성을 위한 후크도 있어야 한다고 생각합니다. 파일의 경우에도 메모리 매핑 파일이나 비동기 I/O와 같은 다른 유효성 재검사 문제가 있습니다.
이것이 바로 POSIX 메시지 대기열에 후크가 없는 이유입니다(Stephen Smalley에 따르면).
LSM은 POSIX 메시지 대기열 이전에 구현되었습니다.
메시지 큐는 이미 inode 후크의 이점을 누리고 있습니다. 예를 들어 메시지 대기열을 열려면 후크를 전달해야 합니다
security_inode_open.read별도의 유사한 작업에 있는 후크는write재검증에만 사용되는 반면 재검증은 정보를 영구적으로 저장하는 일반 파일에 가장 유용합니다(이 매개변수는 메시지 큐 및 스플라이싱과 같은 기타 이상한 경우에 적용됩니다).