MAC인가요, DAC인가요?

LSM 속성/상한 구현의 유틸리티나 사용법을 보는 데 문제가 있습니다.

나는 내 우려 사항과 질문을 표현하기 위해 몇 가지 유사 코드 조각을 함께 모았습니다. (p 3)의 다이어그램에 따라 모델링됩니다. https://www.kernel.org/doc/ols/2002/ols2002-pages-604-617.pdf

커널 액세스 확인(대략) 및 LSM 호출:

DAC
op:__?   // ? what operation would pass a DAC check yet not the LSM hook ?
file:___
perms:  u.. g.. o.. 
euid:100
egid:500


OK  ----> LSM hook ( args ) 

        1) I don't know the args here, 

        2) Regardless of the args I can't make out what operation would pass a DAC check
           and be restricted here and why? 

           ? read file ?      allready handled by DAC

           ? network device ? allready handled by DAC, it's a file.

           ? execution ?      x bit , allready handled

           ? executing a specific function ? no function call references here

           ? executing a specific syscall ? would be handled on exec on the target (read, write etc..)

           ?  
           **What exactly can the LSM hook accomplish here that DAC hasn't allready addressed ??**


            Answers are welcome.
            sp

나는 코더가 setuid 루트를 사용하지 않고 일부 CAP 속성을 사용하여 보다 안전한 권한 상승을 위해 이 작업을 수행하도록 하는 것에 대한 토론을 읽었지만 개인적으로 동작 변경에 의존하거나 권한 확인을 후킹하는 전문가는 아닙니다. 기계 보안 내가 실행 중인 코드의 무결성을 고려하면 나 혼자인 것 같습니다.

또한 이는 LSM의 의도가 아니라는 내용도 읽었습니다.여기

설계 문제는 해결되지만 현재 DAC 권한 확인의 정확한 목적은 여전히 ​​불분명합니다. 후크가 있는 이유는 설명하지만 DAC보다 더 중요한 작업을 수행하기 위해 후크를 효과적으로 사용하는 방법은 설명하지 않습니다.