루트보다 높은 권한을 가진 사용자가 있는 것이 유리할 수도 있다고 생각합니다.
알다시피, 나는 모든 활동을 유지하고 싶습니다.거의기존의 모든 루트 사용자 권한은 현재와 동일하게 유지됩니다.
그러나 극도로 고립된 상황에서는 루트 권한을 거부할 수 있었으면 좋겠습니다.
이렇게 하면 업데이트 프로세스 중에 원치 않는 특정 파일이 설치되는 것을 방지할 수 있다는 장점이 있습니다. 이는 가능한 장점의 한 예일 뿐입니다.
apt-get 업데이트는 루트 또는 sudo 권한으로 실행되므로 apt-get은 업데이트 중에 원치 않는 일부 파일을 대체할 수 있습니다.
이러한 개별 특정 파일에 대해 이러한 권한을 거부할 수 있는 경우 해당 파일을 simlink로 설정하거나 /dev/null업데이트 중에 대체되는 파일을 거부하는 권한이 있을 수 있는 빈 자리 표시자 파일이 있을 수 있습니다.
또한 Ubuntu 제작자 중 한 명과의 인터뷰에서 "우리가 루트 액세스 권한을 갖고 있기 때문에" 사용자가 "우리"(Ubuntu 개발자를 지칭)를 더 잘 신뢰할 수 있는 방법에 대해 이야기한 인용문이 생각납니다. 루트 권한으로 시스템 업데이트를 수행하는 방법에 대해 알아보세요.
이 문제를 해결하기 위해 단순히 설치 프로세스를 변경하는 것은 내가 관심 있는 것이 아닙니다. 이제 루트 액세스를 거부해야 한다는 생각이 마음에 들었으므로 이를 구현하기 위한 방법을 찾고 싶습니다.
저는 이 문제에 대해서만 생각했고 지금까지 아이디어에 대해 시간을 투자하지 않았으며 이 문제를 해결할 수 있다고 확신합니다. 그런데 이런 일이 이전에도 있었던 일인지, 아니면 새로운 아이디어나 개념이 아닐 수도 있는지 궁금합니다.
기본적으로 시스템 수준 이상의 권한만 갖는 슈퍼 슈퍼유저를 보유할 수 있는 방법이 있어야 할 것 같습니다.
참고: @CR의 답변이 정말 마음에 들지만 허용되는 답변이 가장 표준에 맞는 것 같습니다. 반품.
실제 사용자(나)를 위해 트리 상위에 하나 만들어 주고 싶은데, 언젠가 시간이 나면 이 부분을 정리해야 할 것 같습니다.
또한 여기서는 우분투를 선택하려는 것이 아닙니다. 여기서는 우분투를 선택하려고 합니다. 그것에 대해 부정적인 느낌이 든다면 그것을 주요 배포판으로 사용하지 않을 것입니다.
답변1
원하는 "사용자"는 LSM: Linux Security Module입니다. 가장 잘 알려진 것은 SELinux와 AppArmor입니다.
이렇게 하면 특정 바이너리(및 해당 하위 프로세스)가 특정 작업을 수행하는 것을 방지할 수 있습니다(UID가 root). 그러나 이러한 작업 getty과 해당 하위 프로세스를 허용하여 수동으로 수행할 수 있습니다.
답변2
사용자 개념을 잘못 이해하셨습니다 root.
일반 영어로 root"나무 꼭대기"에 있습니다.
어느 날 "슈퍼슈퍼유저"를 갖기로 결정하고 다음 달에 "슈퍼슈퍼유저"(!)를 갖기로 결정했다면 어떻게 될까요? 나무 위로 얼마나 올라가고 싶나요? 모든 권한과 계층 구조를 어떻게 조정하여 작동하게 하시겠습니까? 항상 상위권에 있는 사람은 누구인가? 누군가는 꼭대기에 있어야 하고, 그게 전부입니다 root. 이야기의 끝.
AppArmor 및 SELinux를 포함하여 여기에 제시된 솔루션은 실제로 이를 바꾸지 않습니다. root권한과 프로세스를 보다 세부적으로 제어 할 수 있습니다 .
귀하의 업데이트 프로세스가 예상 결과에 적합하지 않은 것 같습니다. 하지만 이는 root전혀 사용자의 잘못이 아닙니다. 일을 지나치게 복잡하게 만들지 말고 root최고 수준의 권한이 있는 사용자로 생각한 다음 작업해야 하는 다른 모든 것에 대해 생각해 보세요.
일부 사람들은 이를 표시할 것이지만 사용자 계층 구조에는 더 높은 수준이 없으며 다른 모든 솔루션은 root권한 작동 방식에 대해 약간 다른 제어 기능을 제공할 뿐입니다. 하지만 그들은 그렇지 않아만들다더 높은 권한을 가진 새로운 사용자입니다.
가능한 가장 높은 권한 수준을 나타내므로 root사용자 에게 "추가 권한"을 부여할 수 없습니다 . root"루트보다 더 많은 제어"와 같은 문구를 사용하는 것은 모순입니다. 즉, root완전한 제어와 가능한 모든 권한을 가지므로 그 위에서는 아무것도 할 수 없습니다.
답변3
파일이나 디렉터리가 변경/삭제되는 것을 막고 싶다면 해당 파일이나 디렉터리에 불변 플래그를 설정하면 됩니다.
chattr +i <file>
이 플래그를 제거하지 않으면 루트라도 해당 항목에 대해 어떤 작업도 수행할 수 없습니다. 루트 액세스를 방지하기 위해 컨테이너/네임스페이스 시스템을 사용하는 것도 가능하지만 이는 사용자의 요구에 비해 다소 과도한 것 같습니다.
답변4
이와 같은 소프트웨어의 경우쉬운,정상 작동 중에 거의 모든 시스템에 액세스해야 하며, 제한 사항이 문제가 됩니다. 시스템의 특정 부분에 대한 액세스를 차단하더라도 악의적인 배포자가 문제를 해결할 가능성이 충분히 있습니다. 예를 들어 라이브러리나 바이너리만 교체하거나 결국 무제한 루트에서 사용하게 될 악의적인 구성 변경 사항을 추가하는 등의 작업을 수행할 수 있습니다.
얼마나 제한적으로 설정했는지에 따라 일부 설치 스크립트가 손상될 수 있습니다.
애플리케이션과 사용자를 제한하는 방법으로 AppArmor 또는 SELinux 정책을 작성할 수 있습니다. 이러한 정책이 더 많이 지원되는지 여부는 배포판에 따라 다릅니다. Debian 기반 배포판은 AppArmor에 대한 더 나은 지원을 제공하는 반면 Fedora/RHEL 기반 배포판은 기본적으로 SELinux를 활성화합니다.
AppArmor와 SELinux를 모두 사용할 수 있습니다.화이트리스트특정 작업을 허용(또는 거부)하는 규칙이 포함된 정책입니다. 프로세스에 적용되는 전략구현하다마찬가지로, 로그인 시 사용자의 프로세스에 정책이 적용되면 사용자를 제한할 수 있습니다. (커널 버그를 고려하지 않는 경우) 잘 생각한 전략으로는 이를 해결할 방법이 없습니다. 루트(uid 0)로 실행되는 제한된 프로세스에는 구성된 정책이 적용되며 정책에서 명시적으로 허용되지 않는 한 변경할 수 없습니다.
AppArmor 정책 언어는 다음을 정의합니다.규칙을 거부하다, 이는블랙리스트 정책. AppArmor는 AppArmor 사용을 시작하기에 좋은 곳입니다.매뉴얼 페이지,위키피디아배포판에서 기존 구성을 찾으십시오 /etc/apparmor.d/.
풍부한 SELinux 관리 및 개발 자료 제공SELinux 위키. SELinux참고정책github에서 호스팅됩니다.