☰

보너스 휠

tag-icon • tag-icon security capabilities
보너스 휠

man 7 capabilities문서에는 Linux 시스템의 프로세스 기능이 세 가지 마스크로 기록되어 있음이 나와 있습니다.

  • 허용된
  • 효과적인
  • 상속 가능한

나는 아이디어가상속 가능한마스크는 작동하지만 허용된 기능과 유효한 기능을 분리해야 하는 필요성/사용 사례가 있는 것 같은 이유가 확실하지 않습니다.

허용된 기능 중 일부가 유효하지 않은 상황이 있습니까? 이 질문에 대한 답을 흥미롭게 만드는 것은 어느 것입니까?

보너스 휠

일부 기능이 유효하지 않지만 허용되는 경우 프로세스에서 해당 기능을 유효하게 설정하지 못하게 하는 것은 무엇입니까? 적어도 제가 보기에는 악성 프로세스가 모든 것이 유효하도록 설정하는 것을 주저하지 않고 종종 권한을 더 높이려고 시도하는 것 같습니다.

답변1

유효한/허용된 기능의 차이는 setuid 프로그램의 실제/유효 UID 간의 차이와 유사합니다. 아이디어는 악성 앱이 권한을 확대하는 것을 방지하는 것이 아니라(설정하지 않은 것처럼 처음에 권한을 부여하지 않음) 프로그램이 최소한의 권한으로 실행되고 필요한 경우에만 확대되도록 허용하는 것입니다. 이는 오류의 영향을 최소화하는 데 도움이 됩니다.

매우 인위적인 예: 사용자 소유 프로세스에 SIGHUP을 보낼 수 있는 프로그램을 원합니다.또는God 사용자가 SIGHUP을 에 보낼 수 있도록 허용합니다 init.

이 프로그램은 파일에 CAP_KILL 기능을 설정합니다.

의사 코드는 다음과 같습니다.

drop_effective CAP_KILL
repeat forever:
  get_process_id_from user
  if process_id==1 and user_is_God:
    set_effective CAP_KILL
    kill(-1,1)
    drop_effective CAP_KILL
 else:
   kill(-1,process_id)

여기서 명백한 실수는 사용자가 신호를 보낼 수 있는지 먼저 확인하지 않았다는 것입니다. 유효한 CAP_KILL 권한을 제거했기 때문에 사용자가 자신의 프로세스가 아닌 다른 프로세스를 종료하는 것을 허용하지 않습니다.

물론 매우 고안된 것입니다! 그러나 가능한 한 "최소 권한"으로 실행하고 필요한 경우에만 권한을 활성화하는 것이 좋습니다.

이제 주입된 코드가 허용된 권한을 활성화할 수 있으므로 이것이 버퍼 오버플로 공격을 반드시 방지하는 것은 아닙니다. 따라서 기능 인식 코드는 더 이상 필요하지 않은 경우 허용된 권한도 제거해야 합니다. 예를 들어 웹 서버는 포트 80 CAP_NET_BIND_SERVICE에 바인딩할 수 있습니다. 삭제됩니다. 허용되지 않는 콘텐츠는 활성화할 수 없습니다!

답변2

작동할 수 있다는 간단한 가설: 사용자가 시스템의 모든 파일을 복사(읽기)할 수 있지만 변경(쓰기)할 수 없기를 원합니다. .CAP_DAC_OVERRIDE​cp​CAP_DAC_OVERRIDE​

추가 질문에 관해서는 임의의 코드를 실행할 수 있는 경우 해당 코드가 다시 유효해지는 것을 막을 수 있는 방법이 없습니다. 그러나 다른 손상이 발생하는 경우에는 유용할 수 있습니다(예: 프로그램이 심볼릭 링크 공격을 통해 임의의 파일을 덮어쓰도록 유도하는 경우).

관련 정보