GAC 제한 사항

GAC 구현은 특히 파일 액세스가 초당 수백 번 시도되는 경우 매우 효과적이지만 다음과 같은 제한 사항을 가지고 있습니다.
cminderpim14kr
GAC 구현은 특히 파일 액세스가 초당 수백 번 시도되는 경우 매우 효과적이지만 다음과 같은 제한 사항을 가지고 있습니다.
  • 기본적으로 GAC 규칙은 root 사용자(대개 ADMIN)에게 적용할 수 없습니다. 루트에 적용할 수 있는 규칙을 만들려면 seos.ini 파일의 [SEOS_syscall] 섹션에서 다음 토큰을 설정합니다.
    GAC_root=1
    토큰의 기본값은 0입니다. 기본값을 복원하려면 토큰을 0으로 설정하거나 토큰을 제거합니다.
  • 조건적으로 보호된 파일 규칙(예: 일 또는 시간 제한 사항, 프로그램 경로 등)을 테이블에 포함하지 않아야 합니다. 이러한 파일 규칙을 GAC.init 파일에 지정하면 일 또는 시간 제한 사항과 다른 제한 사항이 더 이상 적용되지 않습니다.
  • 감사(ALL) 또는 감사(success) 특성이 있는 파일 규칙을 GAC.init 파일에 포함하지 않아야 합니다. 이러한 파일 규칙을 GAC.init 파일에 지정하면 성공적인 액세스의 감사가 기록되지 않습니다.
  • 필터링 프로세스는 실제(현재) UID를 사용하며 이 UID는 실행 시 프로세스와 연결됩니다. 이로 인해 현재 UID가 아니라 원래 UID(사용자가 처음 로그인할 때 사용한 UID)를 추적하는 CA ControlMinder에 루프홀이 발생합니다. CA ControlMinder는 좀 더 신뢰성 있는 보안을 제공하기 위해 UID 사용에 대한 추적을 구현합니다.
    사용자가 이러한 루프홀을 활용하는 방식에 대해 예를 들어 살펴 보겠습니다. 사용자 Tony는 Accounts/tmp 파일에 액세스할 권한이 없습니다. 따라서 Tony는 Accounts/tmp에 액세스할 권한이
    있는
    사용자 Sandra를 /bin/su를 통해 대리합니다. Sandra가 Accounts/tmp 파일에 이미 액세스한 경우 이 파일은 Sandra UID를 통해 do-not-call-me 테이블에 나타납니다. Tony는 Sandra의 UID를 사용하여 이 파일에 대한 액세스 권한을 부여받습니다. 이는 커널 코드가 UID의 기록을 유지 관리하지 않기 때문에 가능합니다.
    그러나 Sandra가 이전에 이 파일에 액세스하지 않은 경우 seosd를 사용하여 일반적인 방식으로 액세스 권한을 검사하고 Tony는 파일에 대한 액세스가 거부됩니다. 이 루프홀을 종료하려면 ADMIN 사용자가 데이터베이스의 SURROGATE 개체를 보호해야 합니다. 예를 들어, ADMIN 사용자는 다음 규칙을 데이터베이스에 추가할 수 있습니다.
    newres SURROGATE USER.Sandra default(N) owner(nobody)
    이 명령은 Tony가 su 명령을 사용하여 Sandra의 액세스 권한을 가져올 수 없도록 합니다.
  • 접근자가 root이면 캐싱 시스템에 아무런 영향이 없습니다. 이는 데이터베이스를 반드시 참조하는 경우에만 root에 대한 액세스 권한이 부여되기 때문입니다.