Những quyền truy cập nào siêu người dùng có thể vi phạm?

Cha Br. George nói trong một trong những bài giảng của mình (bằng tiếng Nga) rằng có một số quyền truy cập mà siêu người dùng không thể vi phạm. Đó là một số quyền truy cập có thể cấm siêu người dùng làm điều gì đó.

Tôi không thể tìm thấy thông tin này trên Internet và tôi tò mò không biết chúng là gì. Đây có lẽ là một cái gì đó liên quan đến thực thi cốt lõi của hệ thống, phải không? Có lẽ anh ta không thể dừng một số quy trình hệ thống? Hoặc có thể anh ta không thể chạy một quá trình trong chế độ thực?

Câu hỏi này không liên quan đến SELinux (George đã nói về nó ngay trước câu hỏi).

acess từ chối root :

rootcó thể bị từ chối truy cập mạng trực tiếp. Đây là hữu ích trên các host kết nối internet, vì nó đòi hỏi bạn phải đăng nhập như smith, sau đó sudo.

một số công cụ root không thể làm :

Điều này KHÔNG dành cho việc thiếu đặc quyền. Tôi không thể thấy bất cứ điều gì root không thể làm, tuy nhiên một số vấn đề kỹ thuật có thể gặp phải là "bị cấm".

Tôi là root, tại sao tôi không thể tạo / xóa tệp này, trong khi người dùng bình thường có thể?

Bạn đang chia sẻ NFS / samba và bạn không cấp phép cụ thể ( access=). Người dùng thông thường không theo luật chung. (xem địa phương và root từ xa bên dưới)

Tôi là root, tại sao tôi không thể giết quá trình này?

Có một I / O đang chờ xử lý và ổ đĩa vật lý / LUN từ xa đã bị ngắt kết nối, quá trình chỉ có thể bị hủy bằng cách khởi động lại.

Tôi đã root, làm cách nào để lấy mật khẩu của Archemar?

Bạn hoàn toàn có thể su - archemar, hoặc thay đổi mật khẩu của archemar mà không cần biết mật khẩu trước đó, nhưng bạn không thể đọc nó (viết tắt của logger), vì mật khẩu được lưu trữ bằng cách sử dụng hàm băm một chiều.

cục bộ vs root từ xa

• Bạn có thể root trên trạm / PC của bạn và sử dụng chia sẻ NFS của công ty / trường đại học / trường đại học / nhà cung cấp.
• Tiếp theo, bạn chỉ có thể đăng nhập không root trên máy tính xuất NFS.

Hiện nay

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

chỉ cần đăng nhập vào máy chủ NFS, chạy ./bashvà bạn đã root trên máy chủ của công ty / trường đại học.

Trong trường hợp thông thường, điều này không chính xác - siêu người dùng có các đặc quyền / quyền đối với bất kỳ chức năng nào mà hệ thống cung cấp (1). Trường hợp quy tắc này bị phá vỡ là khi bạn ném SELinux vào hỗn hợp. Với SELinux, có thể hạn chế các đặc quyền của root thậm chí không cho phép một số hành động nhất định. Tuy nhiên, các hành động cụ thể không được phép phụ thuộc rất nhiều vào cấu hình SELinux của máy cục bộ, do đó, ngay cả với SELinux, câu hỏi này không thể được trả lời theo nghĩa chung.

(1) - nếu một hệ thống không cung cấp một tính năng nhất định, ví dụ như không có chức năng nhân thời gian thực, thì tôi đang xem câu lệnh "root không có quyền truy cập vào chức năng này" là sai, vì câu lệnh đó dựa vào một giả định sai (cụ thể là tính năng đã cho có sẵn cho bất kỳ ai trên hệ thống đó)

Một mặt, có những điều mà không người dùng nào có thể làm, chẳng hạn như

• thư mục liên kết cứng (vì giới hạn hệ thống tệp)
• ghi vào đĩa CD-ROM đã bị cháy (vì vật lý)

Nhưng đó không phải là đặc quyền, bởi vì chúng không thể được cấp, chúng chỉ là không thể đối với bất kỳ ai.

Sau đó, có những hạn chế cho toàn bộ hệ thống hoặc các bộ phận của nó có thể được bật hoặc tắt.
Ví dụ: trên OS X có một tùy chọn chỉ cho phép mã chạy nếu nó đã được Apple ký.

Tôi cũng không coi đây là một đặc quyền thực sự, bởi vì không người dùng nào có thể có nó nếu siêu người dùng không thể. Bạn chỉ có thể vô hiệu hóa nó trên toàn cầu.

Chỉnh sửa:
Ý tưởng của bạn về một tệp không có bit thực thi cũng sẽ thuộc loại này, vì theo nghĩa đen là không ai có thể làm điều đó và không ai có thể được cấp quyền đó.
Và ngay cả khi cấp cho người dùng hoặc nhóm khác quyền thực thi tệp đó, nhưng không phải root hoặc root nhóm người dùng, root vẫn có thể thực thi tệp đó (được thử nghiệm trên máy chủ OS X 10.10, 10.11 và Ubuntu 15.04).

Ngoài những trường hợp đó, hầu như không có gì root không thể làm được.
Tuy nhiên, có một thứ gọi là chế độ kernel (trái ngược với chế độ người dùng).

Theo như tôi biết, trên một hệ thống lành mạnh, chỉ có kernel, phần mở rộng kernel và trình điều khiển chạy ở chế độ kernel và mọi thứ khác (bao gồm cả shell mà bạn đăng nhập với quyền root) chạy trong chế độ người dùng.
Do đó, bạn có thể lập luận rằng "là root là không đủ". Tuy nhiên, trên hầu hết các hệ thống, người dùng root có thể tải các mô-đun hạt nhân, lần lượt sẽ chạy trong chế độ kernel, mang lại hiệu quả cho root cách chạy mã trong chế độ kernel.

Tuy nhiên, có những hệ thống (như iOS) trong đó điều này là không thể (tùy tiện), ít nhất là không phải không khai thác các điểm an ninh. Điều này chủ yếu là do tăng cường bảo mật, như thực thi ký mã.
Ví dụ: có các khóa mã hóa AES được tích hợp trong bộ xử lý của iDevices, chỉ có thể được truy cập từ chế độ kernel. Các mô-đun hạt nhân có thể truy cập vào các mô-đun đó, nhưng mã trong các mô-đun hạt nhân đó cũng sẽ phải được Apple ký để hạt nhân chấp nhận chúng.

Trên OS X, kể từ phiên bản 10.11 (El Capitan) cũng có cái gọi là "chế độ không root" (mặc dù tên này gây hiểu nhầm vì root vẫn tồn tại), điều này có hiệu quả cấm root một số thứ mà trình cài đặt vẫn có thể thực hiện.
Trích dẫn từ câu trả lời tuyệt vời này trên AskDifferent :

Đây là những gì nó hạn chế, thậm chí từ root:

• Bạn không thể sửa đổi bất cứ điều gì trong / Hệ thống, / bin, / sbin hoặc / usr (ngoại trừ / usr / local); hoặc bất kỳ ứng dụng và tiện ích tích hợp nào. Chỉ Trình cài đặt và cập nhật phần mềm mới có thể sửa đổi các khu vực này và thậm chí chúng chỉ thực hiện khi cài đặt các gói do Apple ký.

"Thực thi lõi hệ thống" mà bạn đề cập nằm trong roottầm kiểm soát, ví dụ như thông qua các mô-đun hạt nhân có thể tải. Tất nhiên, điều này giả định việc tải các mô-đun hạt nhân được hỗ trợ bởi kernel, không ai có thể thực hiện các hành động không khả thi, thậm chí root.

Điều này cũng đúng với các quy trình hệ thống. rootđược phép giết bất kỳ tiến trình nào, nhưng không thể dừng một tiến trình đang chạy trong chế độ kernel mà không ảnh hưởng đến tính toàn vẹn của kernel, vì vậy đơn giản là không thể dừng xử lý như vậy ngay lập tức. Lưu ý rằng rootsẽ không bị từ chối để giết các quá trình đó, tự giết nó sẽ không có tác dụng.

Cuối cùng, chế độ thực: nhân Linux không hỗ trợ cho nó, vì vậy một lần nữa, không ai có thể làm điều không thể, thậm chí là không root.

@Siguza đã đề cập đến việc thực thi các tệp mà không có sự xcho phép, điều này hoàn toàn có thể đối với rootngười dùng:

/lib/ld-linux.so.2 /path/to/executable

Một ví dụ có thể là sửa đổi tệp bất biến: Bạn có thể đặt thuộc tính tệp ivới tệp chattrđó làm cho tệp bất biến ngay cả đối với root. Ví dụ:

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

Lưu ý rằng tệp xuất hiện dưới dạng tệp ghi thông thường trong ls -lđầu ra:

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

Để xem ithuộc tính, bạn phải sử dụng lsattr:

# lsattr god
----i----------- god

Các trang hướng dẫn của chattr tiểu bang sau đây về ithuộc tính:

Một tệp có thuộc tính `i 'không thể được sửa đổi: nó không thể bị xóa hoặc đổi tên, không có liên kết nào có thể được tạo ra cho tệp này và không có dữ liệu nào có thể được ghi vào tệp. Chỉ có siêu người dùng hoặc một quá trình sở hữu khả năng CAP_LINUX_IMMUTABLE mới có thể đặt hoặc xóa thuộc tính này.

Mặc dù, root có thể dễ dàng hoàn tác sự bất biến:

# chattr -i god
# rm -v god
removed ‘god’

Trên FreeBSD, bạn không thể sử dụng gmirrortrên một phân vùng đã được gắn, ngay cả khi root:

nhãn gmirror -v -b thích gm0s1 ad4s1
gmirror: Không thể lưu trữ siêu dữ liệu trên ad4s1: Không được phép thao tác.

Bạn phải đặt một sysctl( kern.geom.debugflags=16) để có thể làm điều đó.

rootlà một người dùng đặc quyền, nhưng các quyền này được cung cấp bởi kernel. Vì vậy, kernel đã có nhiều đặc quyền hơn root.

Giả sử sự hợp tác từ chính người dùng root, rootcó thể bị ngăn truy cập vào các gắn kết FUSE (với các tùy chọn allow_otherhoặc allow_roottùy chọn), nhưng điều này là do FUSE được thiết kế để hoạt động theo cách này. Vì FUSE nằm trên một lớp ảo, nó có thể trả về bất kỳ lỗi nào mà nó thích dựa trên logic, trái ngược với các mô-đun thiết bị khối thông thường cố gắng minh bạch và mỏng nhất có thể, ủy quyền cho lớp khác.

Điều này không ngăn người dùng root vô hiệu hóa tùy chọn hoặc thay thế mô-đun FUSE bằng mô-đun âm thầm loại bỏ tùy chọn, trừ khi bạn làm cho hệ thống tệp chỉ đọc. Tuy nhiên, điều này chỉ dẫn đến một tình huống "người theo dõi những người canh gác": làm thế nào bạn có thể xác nhận rằng hệ thống không nói dối? Shell của bạn thậm chí có thể đang ngồi trong một chroot cho bạn thấy một mô-đun FUSE hợp pháp, trong khi kernel thực sự đang chạy một phiên bản xấu của nó.

Tôi có thể nói rằng việc không thể thực thi các tệp không thể thực thi được là một hạn chế không đáng kể, vì nó phụ thuộc vào quyền của tệp. (Có thể khắc phục điều này bằng cách sử dụng /lib64/ld-linux-x86-64.so.2 cho một tệp không thể thực hiện được, nhưng không phải là tệp trên giá trị không thực thi)

Ngoài ra còn có vấn đề về khóa tệp bắt buộc, ngăn chặn chỉnh sửa tệp nếu một tệp hiện đang được sử dụng bởi một quy trình, mặc dù siêu người dùng có thể giết tiến trình.

Tại một thời điểm, siêu người dùng không thể ngắt kết nối thiết bị trong khi thiết bị đang bận, nhưng giờ đây điều này có thể được thực hiện bằng cách sử dụng một umount lười biếng.

Những hạn chế khác là:

không thể sửa đổi các tệp bất biến và chỉ có thể chắp thêm vào các tệp chỉ chắp thêm (linux cho phép siêu người dùng xóa các cờ bất biến và chỉ gắn các cờ ở bất kỳ cấp độ chạy nào, tuy nhiên, một phần đánh bại mục đích của chúng)

không thể ghi vào giá treo chỉ đọc hoặc thực hiện bất cứ điều gì trên giá treo không thực thi

không thể ràng buộc một gắn kết không thể chịu được

không thể kết nối một hệ thống tệp dưới dạng đọc-ghi nếu thiết bị khối của nó chỉ đọc

không thể thống kê bất cứ thứ gì trên ngàm cầu chì thuộc sở hữu của người dùng khác, trừ khi nó được gắn cho phép khác hoặc cho phép root

không thể vi phạm cài đặt SELinux

các hạn chế cố ý vốn có trong chính hệ thống, ảnh hưởng đến root:

không thể trực tiếp đặt thời gian c của tệp (hoặc thời gian sinh, nếu nó được thực hiện)

không thể xem mật khẩu dưới dạng văn bản thuần túy