사용자가 root커널의 기능 검사를 우회합니까, 아니면 rootLinux 2.2부터 사용자가 기능 검사를 받습니까?
root특정 기능이 해당 기능 세트에서 제거된 경우 애플리케이션이 사용자 액세스를 확인하고 거부할 수 있습니까?
기본적으로 루트 사용자는 모든 기능을 갖습니다.
제가 묻는 이유는 다음과 같습니다 man capabilities.
Privileged processes bypass all kernel permission checks
그러나 이 규칙이 Linux 2.2 릴리스 이후에도 여전히 유효한지는 명시되어 있지 않습니다.
추가의: Docker는 새 컨테이너를 시작할 때 루트 사용자로부터 일부 기능을 제거합니다. 그런데 Docker는 기본적으로 사용자 네임스페이스를 사용하지 않는데, root사용자의 능력은 어떻게 회복되나요?
man capabilities:
권한 확인을 수행하기 위해 기존 UNIX 구현에서는 권한이 있는 프로세스(유효 사용자 ID가 0이고 수퍼유저 또는 루트라고 함)와 권한이 없는 프로세스(유효 UID가 0이 아님)라는 두 가지 유형의 프로세스를 구별합니다. 권한이 있는 프로세스는 모든 커널 권한 검사를 우회하는 반면, 권한이 없는 프로세스는 프로세스 자격 증명(일반적으로 유효 UID, 유효 GID 및 보충 그룹 목록)을 기반으로 전체 권한 검사를 받습니다.
커널 2.2부터 Linux는 전통적으로 수퍼유저와 관련된 권한을 독립적으로 활성화 및 비활성화할 수 있는 기능이라는 여러 단위로 나눕니다. 기능은 각 스레드의 속성입니다.
답변1
사용자 root기능이 제한될 수 있습니다. 에서 capabilities(7):
유효 사용자 ID가 0이 아닌 값에서 0으로 변경되면 허용된 집합이 유효 집합에 복사됩니다.
즉, 기능 모델에서는 root기존 모델과 달리 사용자가 되어도 모든 권한이 부여되지는 않습니다. 기능 모델은 Linux 2.2 이상에서 사용됩니다.
프로세스의 경계 기능 세트는 상위 프로세스에서 상속됩니다. Docker가 컨테이너를 시작한 스레드의 경계 세트에서 기능을 제거하면 해당 기능도 컨테이너에서 제거되어 사용자 root또는 다른 프로세스에 관계없이 해당 컨테이너의 모든 프로세스에 영향을 미칩니다. root컨테이너 내부의 사용자가 사용자 ID 0(생성된 특정 네임스페이스에서)을 얻으면 컨테이너 내부의 사용자는 나머지 기능을 상속받습니다 clone(2).
이러한 기능의 범위는 clone(2)다양한 하위 시스템 및 AppArmor 또는 SELinux와 같은 기타 보안 하위 시스템을 생성하기 위해 전달된 매개 변수에 의해 제한됩니다.
답변2
첫 번째 문단 전체를 "옛 방식"에 대한 설명으로, 두 번째 문단을 현재 상황(지난 21년 정도)에 대한 설명으로 생각하면 될 것 같습니다.
권한 확인을 수행하기 위해기존 UNIX 구현두 가지 유형의 프로세스를 구별하십시오. [...] 권한이 있는 프로세스는 모든 커널 권한 확인을 우회합니다.
커널 2.2부터 시작Linux는 전통적으로 수퍼유저와 관련된 권한을 독립적으로 활성화 및 비활성화할 수 있는 기능이라는 별개의 단위로 나눕니다. 기능은 각 스레드의 속성입니다.