루트 사용자보다 권한이 높은 사용자를 갖는 것이 유리할 수 있다고 생각했습니다.

알다시피, 나는 모든 활동과 거의 모든 기존 루트 사용자 권한을 지금 그대로 유지하고 싶습니다 .

그러나 저는 사례별로 극히 고립 된 권한을 거부 할 수있는 기능을 원합니다.

이것의 장점 중 하나는 업데이트 중에 원하지 않는 특정 파일이 설치되는 것을 방지 할 수 있습니다. 이것은 한 가지 가능한 장점의 예일뿐입니다.

apt-get 업데이트는 root 또는 sudo 권한으로 실행되므로 apt-get은 업데이트 중에 원하지 않는 특정 파일을 대체 할 수 있습니다.

이러한 개별 특정 파일에 대한 이러한 권한을 거부 /dev/null할 수있는 경우 파일을 업데이트 중에 파일 교체를 거부 할 수있는 권한이있는 빈 자리 표시 자 파일에 대한 단순 링크로 설정 하거나 가능할 수 있습니다.

또한 우분투 제작자 중 한 사람과의 인터뷰에서 사용자가 "우리"(우분투 개발자에게 언급)를 더 잘 신뢰하는 방법에 대해 말한 줄에 대해 도움을 줄 수는 없습니다. "는 루트 권한으로 시스템 업데이트를 수행하는 방법에 대한 참조입니다.

이 문제를 해결하기 위해 설치 절차를 변경하는 것만으로도 제가 관심있는 것은 아닙니다. 이제 내 마음은 루트 액세스를 거부 할 수있는 힘을 가졌다는 생각을 가지게되었으므로,이를 위해이를 실현할 수있는 방법을 찾고 싶습니다.

방금 이것에 대해 생각하고 지금까지 아이디어에 시간을 보냈지 않으며 이것이 알아낼 수 있다고 확신합니다. 그러나 이것이 이미 수행되었는지 또는 이것이 새로운 아이디어 나 개념이 아닌지 알고 싶습니다.

기본적으로 시스템의 권한을 한 단계 만 넘어서는 슈퍼 수퍼 유저를 가질 수있는 방법이 있어야합니다.

참고 : 허용 된 답변이 기준에 가장 적합하다고 생각하지만 @CR의 답변을 정말로 좋아합니다. 또한.

나는 나무 (me)에서 더 높은 실제 사용자를 만들고 싶지만, 그것을 알아낼 시간이있을 때 하루 만 앉아 있어야한다고 생각합니다.

또한 우분투를 선택하려고하지 않습니다. 내가 부정적인 느낌이 든다면 나는 그것을 주요 배포판으로 사용하지 않을 것입니다.

원하는 "사용자"를 LSM : Linux 보안 모듈이라고합니다. 가장 잘 알려진 것은 SELinux와 AppArmor입니다.

이를 통해 특정 바이너리 (및 자식 프로세스)가 특정 작업을 수행하지 못하게 할 수 있습니다 (UID가 인 경우에도 root). 그러나 이러한 작업 getty과 해당 하위 프로세스에 대해 수동으로 수행 할 수 있도록 허용 할 수 있습니다.

사용자의 개념을 오해하고 root있습니다.

평범한 영어로 root"나무 꼭대기"에 있습니다.

언젠가 "슈퍼 수퍼 유저"를 갖고 다음 달에 "슈퍼 수퍼 유저"(!)를 결정하면 어떻게 될까요? 나무가 얼마나 "위"에 가고 싶습니까? 모든 권한과 계층 구조를 어떻게 섞어 작동하게 하시겠습니까? 누가 항상 정상에 있습니까? 누군가가 맨 위에 있어야합니다 root. 이야기의 끝.

AppArmor 및 SELinux를 포함하여 여기에 제공된 솔루션은 실제로이를 변경하지 않습니다. root권한과 프로세스를 보다 세밀하게 제어 할 수 있습니다.

업데이트 프로세스가 원하는 결과에 적합하지 않은 것 같습니다. 그러나 그것은 root사용자 의 잘못이 아닙니다 . 복잡한 작업을 수행하는 대신 root최고 수준의 권한 사용자로 생각한 다음 그 밖의 모든 작업을 수행해야합니다.

일부 사람들은 이것을 표시하지 않지만 사용자 계층에는 더 높은 수준이 없으며 다른 모든 솔루션은 단순히 root사용 권한 작동 방식에 약간 다른 제어를 제공합니다 . 그러나 더 높은 권한으로 새로운 사용자를 만들지 는 않습니다 .

"더 많은 권한"을 가진 사용자는 가능한 최고 수준의 권한을 나타 내기 root때문에 가질 수 없습니다 root. "루트보다 더 많은 제어"와 같은 문구를 사용하는 것은 모순입니다. root모든 권한과 모든 가능한 권한이 있으므로 그 위에 할 수있는 것은 없습니다.

파일이나 디렉토리가 변경 / 삭제되는 것을 막으려면 불변 플래그를 설정하십시오.

chattr +i <file>

플래그를 제거하지 않으면 루트조차도 그들에게 아무것도 할 수 없습니다. 컨테이너 / 네임 스페이스 시스템을 사용하여 루트 액세스를 방지 할 수도 있지만 필요한 것보다 과도하게 보입니다.

• 슈퍼 수퍼 유저 대신 루트를 제한 할 수 있습니다. gnu / linux에서 파일 권한 등을 설정하는 다른 방법 은 무엇입니까?를 참조하십시오.

• AppArmor 및 SELinux도 있습니다.

• 및 / 또는 configure sudo를 사용하여 전체 루트 권한을 부여하지 마십시오. 사용자가 사전 동의 인수와 함께 사전 동의 명령 만 실행할 수 있도록 설정할 수 있습니다.

• 가상화를 사용하여 루트를 제한 할 수도 있습니다.

  • cgroups, 네임 스페이스, chroot 등 (docker가 수행함)
  • 젠
  • 버추얼 박스

• 참고 etckeeper:이 도구 버전은 제어 /etc디렉터리를 경향과 동기화. 기본적으로 보안이 유지되지 않고 악의적 인 설치로 인해 시스템이 손상 될 수 있지만 변경 사항을 방화벽이있는 백업 리포지토리로 푸시 할 수도 있습니다.

• 방화벽 백업 저장소와 함께 일반적으로 개정 제어 사용. 우발적, 의도적 손상 및 하드웨어 고장에 도움이됩니다.

방화벽 백업 저장소는 다른 머신, 인터넷 또는 다른 가상 머신 (또는 가상 머신의 호스트)에있을 수 있습니다.

정상 작동시 거의 모든 시스템에 액세스해야하는 APT 와 같은 소프트웨어 의 경우 제한이 문제가됩니다. 시스템의 특정 부분에 액세스하지 못하더라도 악의적 인 배포자가 문제를 해결할 가능성이 충분할 가능성이 높습니다. 예를 들어 라이브러리 또는 바이너리 만 교체하거나 악의적 인 구성 변경을 추가하면 무제한 루트가 결국에 사용됩니다.

제한을 두는 정도에 따라 일부 설치 스크립트가 중단 될 수 있습니다.

응용 프로그램 및 사용자를 제한하는 방법으로 AppArmor 또는 SELinux 정책을 작성할 수 있습니다. 보다 지원되는 정책은 배포판에 따라 다릅니다. 데비안 기반은 AppArmor를 더 잘 지원하는 반면 Fedora / RHEL 기반 배포는 기본적으로 SELinux를 활성화합니다.

AppArmor와 SELinux는 화이트리스트 정책에서 작동 하며 여기에는 특정 작업을 허용 (또는 거부)하는 규칙이 포함되어 있습니다. 정책은 exec 의 프로세스에 적용되며, 정책이 로그인시 프로세스에 적용될 때 사용자도 제한 될 수 있습니다. 잘 생각한 정책은 우회 할 수 없습니다 (커널 버그가 고려되지 않은 경우). 루트 (uid 0)로 실행중인 제한된 프로세스는 구성된 정책에 의해 제한되며 정책에서 명시 적으로 허용되지 않으면 변경할 수 없습니다.

AppArmor 정책 언어는 블랙리스트 정책을 작성 하는 데 사용할 수 있는 거부 규칙을 정의합니다 . AppArmor를 시작하기에 좋은 곳은 AppArmor 매뉴얼 페이지 , Wiki 및 배포판의 기존 구성을 보는 것입니다 ./etc/apparmor.d/

SELinux 위키 에는 많은 SELinux 관리 및 개발 자료가 제공됩니다 . SELinux 참조 정책 은 github에서 호스팅됩니다.

나는 아무도 고정 피닝을 언급하지 않았다는 것을 믿을 수 없다 ...

몇 년 전에 Microsoft는 Windows 10 컴퓨터가 기존 Samba NT4 도메인 컨트롤러와 통신하지 못하게하는 패치를 발표했습니다. 문제가 발견되면 Samba 패키지를 고정하여 현재 버전을 유지하면서도 apt올바르게 작동했습니다.

전체 데비안 연습 은 프로세스를 잘 설명합니다 :

에서 /etc/apt/preferences(또는 새 파일에서 /etc/apt/preferences.d/) 어떤 패키지와 버전을 지정하는 텍스트를 추가합니다 :

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

정확한 구문은 설명서를 확인하십시오. 그러나 이것은 패키지 버전을 고정시키는 빠르고 더러운 방법입니다. 루트 는 항상 그렇듯이 루트 는 우회 할 수 있지만 패키지 관리자가 자동으로 패키지를 업그레이드하려고하는 문제를 해결합니다.

참고 :이 답변은 XY 문제 가 있다고 가정합니다.

실제로는 매우 간단합니다.

루트는 "슈퍼 수퍼 유저"입니다

"admin"이라는 계정을 만들고 원하지 않는 것을 제외한 모든 루트 권한을 부여하십시오.

그런 다음 bob이라는 사용자를 작성하고 "관리자"가되도록하십시오. su 또는 sudo를 사용하여.

이제 일반 사용자 (bob)가 관리자 작업 (admin)과 수퍼 슈퍼 사용자 (root)를 수행 할 수있는 슈퍼 사용자입니다.

"root"라는 이름을 다른 것으로 바꾸려면 그렇게 할 수도 있습니다. 기술적으로 사용자 ID (0) 만 중요합니다.

원하는 것이 단순히 특정 파일이 설치되는 것을 막는 것이라면 루트 권한을 제한하는 것이 그렇게하는 방법이 아닙니다. APT (및 대부분의 다른 패키지 관리자)가 파일을 설치할 수 없으면 구제 될 수 있기 때문에 일반적인 응답 (불변 파일 또는 LSM)이 특정 유스 케이스에 대해 작동하지 않는다는 점도 주목할 가치가 있습니다.

당신이 묻는 실제 질문은 다음과 같습니다.

APT가 특정 파일을 설치하지 못하게하는 방법이 있습니까?

그것은 당신이 여러 수준에서 요구하는 것과 완전히 다른 것입니다.

그 질문에 관해서는, 나는 100 % 확신하지 않지만, 다른 많은 패키지 관리자가 특정 파일이 설치되는 것을 막는 옵션이 있다는 것을 알고 있습니다 (예 : Gentoo 's Portage 시스템에는 INSTALL_MASK=실제로 쉘을 허용 하는 옵션이 있습니다 ) 설치하지 않는 것의 스타일 일치 패턴). 나는 그러한 옵션이 APT (또는 아마도 dpkg 자체)에 존재한다고 기꺼이 생각합니다.

백업 사본을 안전한 곳에 보관하십시오. 설치 / 업데이트 후 즉시 해당 백업에서 특정 파일을 교체하십시오. 따라서 설치를 망치는 오류는 없지만 계속 유지하려는 파일을 다시 가져옵니다.

마운트 된 드라이브에서 작업

이것은 주로 개념적인 대답이지만, 나는 그것이 당신이 달성하고자하는 것과 효과가 있고 정신적이어야한다고 생각합니다.

시스템 X를 작업 시스템으로, 시스템 Y를 다른 시스템으로 제어하십시오.

1. Y에서 디렉토리를 X의 드라이브로 마운트
2. X의 루트 사용자가이 마운트 된 드라이브의 모든 것에 대한 권한을 가지도록 권한을 설정하십시오.

이제 거의 모든 작업을 수행 할 수있는 '작업 루트'가 있고 실제로 모든 작업을 수행 할 수있는 시스템 Y의 실제 루트 계정 인 '수퍼 루트'가 있습니다.

Xen 하이퍼 바이저와 같은 유형 1 하이퍼 바이저를 실행하고 일반 게스트를 가상화 게스트로 호스팅 할 수 있습니다. 하이퍼 바이저는 게스트 OS가 실행되는 (가상) 하드웨어를 제어하기 때문에 루트보다 "깊게"레벨에서 가상 게스트 OS를 제어합니다.

권한 변경, 백업 생성 및 적용, 게스트 OS에서 특정 변경 사항 또는 지침을 연결하여 추가 기능, 유효성 검사 등을 주입하는 등 다양한 방법으로 게스트 OS를 조작하도록 하이퍼 바이저를 프로그래밍 할 수 있습니다. "루트조차 할 수없는 일을하기" "사용자"(실제로는 하이퍼 바이저의 기능)로 유닉스 타입 시스템을 구현

이 접근법은 아마도 과잉 일 것입니다.

Docker 및 lxd 와 같은 도구를 비롯하여 이러한 유형의 목표를 달성하기위한 대체 방법으로 cgroup 및 Linux 네임 스페이스 를 살펴 보십시오 .

이러한 도구를 사용하면 무엇보다도 "루트"로 실행중인 프로세스가 볼 수있는 파일 시스템의 어떤 부분을 볼 수 있는지, 볼 수있는 프로세스를 제한 하고 "루트"사용자에게 특정 기능 만 제공 할 수 있습니다 .

제거 sudo

제거 sudo및 심볼릭 링크 /bin/su는 /bin/false어떻습니까? root로그인 할 수없고 ssh시스템을 잠그는 것을 확인하십시오 .

그것은 root슈퍼 * 슈퍼 유저가되며 다른 모든 사람들은 그것에 종속됩니다.

업데이트 중에 교체 된 파일의 경우 업데이트를 수행하지 마십시오. 더 현실적으로에 파일의 권한을 변경 440또는 444그들이 쓸 수 없습니다 수 있습니다. 또는 자식 저장소에 넣으면 덮어 쓰면 되돌릴 수 있습니다.