Tôi đã nghĩ rằng có thể có lợi khi có người dùng có quyền cao hơn người dùng root.

Bạn thấy đấy, tôi muốn giữ tất cả các hoạt động và gần như tất cả các đặc quyền người dùng root hiện có chính xác như hiện tại.

Tuy nhiên, tôi muốn khả năng từ chối các đặc quyền để root trên một trường hợp cực kỳ cô lập theo từng trường hợp.

Một trong những lợi thế của điều này sẽ cho phép tôi ngăn chặn một số tệp không mong muốn được cài đặt trong quá trình cập nhật. Đây chỉ là một ví dụ về một lợi thế có thể.

Vì các bản cập nhật apt-get được chạy bởi root hoặc với các đặc quyền sudo, apt-get có khả năng thay thế một số tệp không mong muốn trong quá trình cập nhật.

Nếu tôi có thể từ chối các đặc quyền này đối với các tệp riêng lẻ này, tôi có thể đặt chúng dưới dạng simlink /dev/nullhoặc có thể có tệp giữ chỗ trống có thể có quyền từ chối thay thế tệp trong quá trình cập nhật.

Ngoài ra, tôi không thể không nhắc về một dòng được nói trong một cuộc phỏng vấn với một trong những người tạo Ubuntu khi anh chàng nói điều gì đó về cách người dùng tin tưởng tốt hơn "chúng tôi" (đề cập đến các nhà phát triển Ubuntu) "vì chúng tôi đã root "Đó là một tham chiếu về cách cập nhật hệ thống được thực hiện với sự cho phép root.

Đơn giản chỉ cần thay đổi quy trình cài đặt để nói rằng công việc xung quanh vấn đề này hoàn toàn không phải là điều tôi quan tâm ở đây. Bây giờ tâm trí của tôi có một ý tưởng cho ý tưởng có sức mạnh để từ chối quyền truy cập root, tôi muốn tìm ra một cách để làm cho điều này xảy ra chỉ vì lợi ích của nó.

Tôi chỉ nghĩ về điều này và đã không dành thời gian cho ý tưởng cho đến nay và tôi khá tự tin rằng điều này có thể được tìm ra. Tuy nhiên, tôi tò mò muốn biết liệu điều này đã được thực hiện chưa hay đây có thể không phải là một ý tưởng hay khái niệm mới.

Về cơ bản, có vẻ như nên có một số siêu người dùng có thể được phép vượt ra ngoài hệ thống chỉ một độ.

Lưu ý: Mặc dù tôi cảm thấy câu trả lời được chấp nhận phù hợp với tiêu chí nhất, tôi thực sự thích câu trả lời của @CR. cũng thế.

Tôi muốn tạo một người dùng thực tế cao hơn trên cây (tôi) nhưng tôi đoán tôi sẽ phải ngồi xuống một ngày khi tôi có thời gian để tìm ra nó.

Ngoài ra, tôi không cố gắng chọn Ubuntu ở đây; Tôi sẽ không sử dụng nó như là bản phân phối chính của mình nếu tôi cảm thấy tiêu cực về nó.

"Người dùng" bạn muốn được gọi là mô-đun bảo mật LSM: Linux. Được biết đến nhiều nhất là SELinux và AppArmor.

Bằng cách này, bạn có thể ngăn các nhị phân nhất định (và các tiến trình con của chúng) thực hiện một số nội dung nhất định (ngay cả khi UID của chúng là root). Nhưng bạn có thể cho phép các hoạt động này gettyvà các quy trình con của nó để bạn có thể thực hiện thủ công.

Bạn đang hiểu nhầm khái niệm của rootngười dùng.

Nói một cách dễ hiểu, rootlà "ngọn cây".

Sẽ thế nào nếu bạn quyết định một ngày nào đó sẽ có một "siêu người dùng siêu hạng", và rồi tháng sau, một "siêu người dùng siêu siêu" (!). Cây bạn muốn đi bao xa? Làm thế nào bạn có thể xáo trộn tất cả các quyền và phân cấp để làm cho công việc đó? Ai luôn đứng đầu? Ai đó phải ở trên đỉnh, và nó root. Kết thúc câu chuyện.

Các giải pháp được đưa ra ở đây - bao gồm AppArmor và SELinux - không thực sự thay đổi điều này. Họ chỉ đơn giản cho phép kiểm soát hạt tốt hơn đối với các rootquyền và quy trình.

Tôi nghe có vẻ như quá trình cập nhật của bạn không phù hợp với kết quả mong muốn. Nhưng đó không phải là lỗi của rootngười dùng. Thay vì làm quá nhiều thứ, hãy nghĩ đến rootnhư người dùng cấp phép cao nhất, và sau đó là mọi thứ khác, bạn phải làm việc xuống dưới.

Tôi biết một số người sẽ đánh dấu điều này xuống, nhưng không có cấp độ cao hơn trong hệ thống phân cấp người dùng và tất cả các giải pháp khác chỉ đơn giản cung cấp quyền kiểm soát hơi khác nhau về cách thức roothoạt động của quyền. Nhưng họ không tạo người dùng mới, với quyền cao hơn.

Bạn không thể có một người dùng có "nhiều quyền hơn" rootvì rootđại diện cho mức cấp phép cao nhất có thể. Sử dụng một cụm từ như "nhiều quyền kiểm soát hơn root" là một mâu thuẫn - rootcó toàn quyền kiểm soát và tất cả các quyền có thể, vì vậy không có gì có thể được thực hiện ở trên nó.

Nếu bạn chỉ muốn ngăn chặn các tập tin hoặc thư mục bị thay đổi / xóa thì chỉ cần đặt cờ bất biến trên chúng.

chattr +i <file>

Thậm chí root sẽ không thể làm bất cứ điều gì cho họ trừ khi cờ bị xóa. Cũng có thể sử dụng hệ thống vùng chứa / không gian tên để ngăn chặn quyền truy cập root nhưng có vẻ như quá mức cho những gì bạn cần.

• Thay vì có một siêu người dùng, bạn có thể giới hạn root. xem các cách khác nhau để đặt quyền truy cập tệp, v.v. trên gnu / linux

• Ngoài ra còn có AppArmor và SELinux.

• Và / Hoặc cấu hình sudo, để bạn không cung cấp đặc quyền gốc đầy đủ. Bạn có thể thiết lập nó để người dùng chỉ có thể chạy các lệnh đã được thỏa thuận trước, với các đối số được thỏa thuận trước.

• Bạn cũng có thể sử dụng ảo hóa để hạn chế root:

  • cgroups, không gian tên, chroot vv (docker làm điều này)
  • Xen
  • Hộp ảo

• Xem thêm etckeeper: sửa đổi công cụ này kiểm soát /etcthư mục và đồng bộ hóa với apt. Theo mặc định, nó không an toàn, một cài đặt độc hại có thể phá hoại nó, nhưng bạn cũng có thể khiến nó đẩy các thay đổi sang kho lưu trữ sao lưu tường lửa.

• Sử dụng kiểm soát sửa đổi nói chung, với một kho lưu trữ sao lưu tường lửa. Điều này giúp với vô tình, cố ý tham nhũng và lỗi phần cứng.

Các kho lưu trữ sao lưu có tường lửa có thể nằm trên một máy khác, trên internet hoặc một máy ảo khác (hoặc máy chủ của máy ảo).

Đối với phần mềm như APT , trong hoạt động bình thường đòi hỏi quyền truy cập vào hầu hết tất cả hệ thống, việc hạn chế là có vấn đề. Ngay cả khi bạn ngăn không cho nó truy cập vào một số phần nhất định của hệ thống, rất có thể có quá nhiều khả năng để nhà phân phối độc hại làm việc xung quanh. Ví dụ: bằng cách thay thế một thư viện hoặc chỉ là một nhị phân hoặc thêm một thay đổi cấu hình độc hại, mà root không bị hạn chế sẽ sử dụng cuối cùng.

Tùy thuộc vào mức độ bạn sẽ đặt các hạn chế, một số tập lệnh cài đặt có thể bị hỏng.

Để biết cách hạn chế ứng dụng và người dùng, bạn có thể viết chính sách AppArmor hoặc chính sách SELinux. Chính sách như vậy sẽ được hỗ trợ nhiều hơn tùy thuộc vào bản phân phối của bạn: Dựa trên Debian có hỗ trợ tốt hơn cho AppArmor trong khi các bản phân phối dựa trên Fedora / RHEL cho phép Selinux theo mặc định.

Cả AppArmor và SELinux đều hoạt động trên các chính sách danh sách trắng , trong đó có các quy tắc cho phép (hoặc từ chối) các hành động cụ thể. Các chính sách được áp dụng cho một quy trình tại exec , tương tự người dùng có thể bị hạn chế khi một chính sách được áp dụng cho các quy trình của họ khi đăng nhập. Một chính sách suy nghĩ tốt không thể bị phá vỡ (nếu lỗi kernel không được xem xét). Quá trình hạn chế chạy dưới quyền root (uid 0) bị hạn chế bởi chính sách được định cấu hình và không thể thay đổi nó trừ khi được cho phép rõ ràng trong chính sách.

Ngôn ngữ chính sách AppArmor xác định quy tắc từ chối , có thể được sử dụng để xây dựng chính sách danh sách đen . Một nơi tốt để bắt đầu với AppArmor là các trang người dùng AppArmor , wiki và tìm kiếm cấu hình hiện có trên bản phân phối của bạn /etc/apparmor.d/.

Rất nhiều tài liệu quản trị và phát triển của Selinux được cung cấp trong wiki Selinux . Chính sách tham chiếu của Selinux được lưu trữ trên github.

Tôi không thể tin rằng không ai đã đề cập đến ghim apt ...

Một vài năm trước, Microsoft đã phát hành một bản vá phá vỡ các máy Windows 10 để nói chuyện với Bộ kiểm soát miền Samba NT4 cũ của chúng tôi. Khi sự cố được tìm thấy, chúng tôi đã ghim gói Samba ở phiên bản hiện tại và aptvẫn hoạt động chính xác.

Hướng dẫn đầy đủ về Debian giải thích quy trình tốt:

Trong /etc/apt/preferences(hoặc một tệp mới bên dưới /etc/apt/preferences.d/), thêm một số văn bản để chỉ định gói và phiên bản nào:

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

Kiểm tra tài liệu cho cú pháp chính xác, nhưng đây là cách nhanh và bẩn mà chúng tôi ghim một phiên bản gói. Root có thể bỏ qua nó, vì root luôn có thể làm được, nhưng điều này giải quyết vấn đề của các nhà quản lý gói đang cố gắng tự động nâng cấp các gói trên bạn.

LƯU Ý: Câu trả lời này giả sử bạn có vấn đề XY

Nó thực sự khá đơn giản.

Root là "siêu người dùng" của bạn

Tạo một tài khoản gọi là "quản trị viên" và cung cấp cho anh ta tất cả các quyền của root trừ tài khoản bạn không muốn.

Sau đó, tạo một người dùng được gọi là bob và để anh ta "trở thành quản trị viên". Bằng cách sử dụng su hoặc thậm chí sudo.

Bây giờ bạn có một người dùng bình thường (bob) một siêu người dùng có thể làm công cụ quản trị (quản trị viên) và một siêu người dùng (root).

Nếu bạn muốn thay đổi tên "root" thành tên khác, bạn thậm chí có thể làm điều đó. Về mặt kỹ thuật chỉ có id người dùng (0).

Nếu những gì bạn muốn chỉ đơn giản là để ngăn chặn các tệp cụ thể được cài đặt, thì việc hạn chế quyền root không phải là cách để thực hiện việc này. Điều đáng chú ý là các câu trả lời thông thường (tệp bất biến hoặc LSM) sẽ không hoạt động cho trường hợp sử dụng cụ thể của bạn, vì APT (và hầu hết các trình quản lý gói khác), sẽ bảo lãnh nếu họ không thể cài đặt tệp.

Câu hỏi thực sự bạn muốn hỏi là:

Có cách nào để ngăn APT cài đặt các tệp cụ thể không?

Đó là một cái gì đó hoàn toàn khác với những gì bạn yêu cầu ở nhiều cấp độ.

Bây giờ, với câu hỏi đó, bản thân tôi không chắc chắn 100%, nhưng tôi biết một số trình quản lý gói khác có các tùy chọn để ngăn chặn các tệp cụ thể được cài đặt (ví dụ: hệ thống Portage của Gentoo có tùy chọn INSTALL_MASK=, thực sự chấp nhận shell kiểu mẫu phù hợp với những thứ không cài đặt). Tôi sẵn sàng đặt cược rằng một tùy chọn như vậy tồn tại cho APT (hoặc có thể là dpkg).

Đặt một bản sao lưu ở một nơi an toàn. Sau khi cài đặt / cập nhật, hãy thay thế ngay các tệp cụ thể từ bản sao lưu đó. Do đó, không có lỗi nào để cài đặt nhưng bạn vẫn lấy lại được (các) tệp bạn muốn giữ.

Làm việc từ một ổ đĩa gắn kết

Lưu ý rằng đây chủ yếu là một câu trả lời theo khái niệm, nhưng tôi nghĩ nó nên hoạt động và có tinh thần với những gì bạn muốn đạt được.

Đặt hệ thống X là hệ thống làm việc của bạn và hệ thống Y là một hệ thống khác mà bạn điều khiển

1. Gắn một thư mục từ Y làm ổ đĩa trong X
2. Thiết lập quyền theo cách mà người dùng root X có quyền đối với mọi thứ trong ổ đĩa được gắn kết này, với một vài ngoại lệ

Giờ đây, bạn đã có 'root hoạt động', có thể thực hiện gần như mọi thứ và bạn có 'siêu root', tài khoản root thực sự của hệ thống Y, có thể thực sự làm mọi thứ.

Bạn có thể chạy một trình ảo hóa loại 1 như Xen hypanneror và lưu trữ hệ điều hành thông thường của bạn như một khách ảo. Trình ảo hóa điều khiển HĐH khách ảo ở mức "sâu" hơn root vì nó có quyền kiểm soát phần cứng (ảo) mà HĐH khách chạy trên đó.

Bạn có thể lập trình trình ảo hóa để điều khiển HĐH khách theo nhiều cách khác nhau, bao gồm thay đổi quyền, tạo và áp dụng sao lưu, nối các thay đổi hoặc hướng dẫn nhất định trong HĐH khách để thêm chức năng, xác thực, v.v. để thực hiện một hệ thống loại unix với một "người dùng" (thực sự là một chức năng của trình ảo hóa) để "làm những việc mà ngay cả root cũng không thể làm được"

Tôi cảm thấy rằng cách tiếp cận này có thể là quá mức cần thiết mặc dù

Hãy xem các nhóm và không gian tên Linux như một phương pháp thay thế để đạt được loại mục tiêu này, cũng như các công cụ dựa trên chúng như Docker và lxd .

Các công cụ này cho phép bạn, trong số những thứ khác, giới hạn những phần nào trong hệ thống tệp mà một quy trình đang chạy dưới dạng "root" có thể nhìn thấy, giới hạn các quy trình được hiển thị cho nó và chỉ cung cấp một số khả năng nhất định cho người dùng "root".

KHÔNG GIỚI HẠN sudo

Làm thế nào về việc gỡ cài đặt sudovà symlink /bin/suđến /bin/false? Kết hợp với việc đảm bảo rằng rootkhông thể đăng nhập qua sshvà bạn đã khóa hệ thống.

Điều đó làm cho rootSuper * Super User và mọi người khác phụ thuộc vào điều đó.

Đối với các tệp được thay thế trong quá trình cập nhật, chỉ cần không thực hiện bất kỳ cập nhật nào. Thực tế hơn, thay đổi quyền của các tệp thành 440hoặc 444để chúng không thể được viết. Hoặc đặt chúng vào kho lưu trữ git để nếu chúng bị ghi đè, nó có thể được hoàn nguyên.