Tính năng gốc rootless của El trong El Capitan là gì?

Tôi vừa tìm hiểu về tính năng "Rootless" trong El Capitan và tôi đang nghe những điều như "Không có người dùng root", "Không có gì có thể sửa đổi /System" và "Thế giới sẽ kết thúc vì chúng ta không thể root được".

Tính năng "Rootless" của El Capitan ở cấp độ kỹ thuật là gì? Điều đó thực sự có ý nghĩa gì đối với trải nghiệm người dùng và trải nghiệm của nhà phát triển? sudo -sVẫn sẽ hoạt động, và, nếu vậy, trải nghiệm sử dụng shell như thế nào sẽ rootthay đổi?

Thứ nhất: tên "rootless" là sai lệch, vì vẫn còn tài khoản root và bạn vẫn có thể truy cập nó (tên chính thức, "Bảo vệ toàn vẹn hệ thống", chính xác hơn). Những gì nó thực sự làm là giới hạn sức mạnh của tài khoản root, do đó ngay cả khi bạn trở thành root, bạn không có toàn quyền kiểm soát hệ thống. Về cơ bản, ý tưởng là phần mềm độc hại quá dễ dàng để có quyền truy cập root (ví dụ: bằng cách hiển thị hộp thoại xác thực cho người dùng, điều này sẽ khiến người dùng theo phản xạ nhập mật khẩu quản trị viên). SIP thêm một lớp bảo vệ khác, phần mềm độc hại không thể xâm nhập ngay cả khi nó bị root. Tất nhiên, phần tồi tệ của điều này là nó cũng phải áp dụng cho những việc bạn đang cố tình làm. Nhưng những hạn chế mà nó đặt trên root không phải là xấu; họ không ngăn cản hầu hết "bình thường"

Đâ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 /System, /bin, /sbin, hoặc /usr(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ý. Nhưng vì các tùy chỉnh kiểu OS X thông thường đi vào /Library(hoặc ~/Library, hoặc /Applications) và các tùy chỉnh kiểu unix (ví dụ Homebrew) đi vào /usr/local(hoặc đôi khi /etchoặc /opt), nên điều này không phải là vấn đề lớn. Nó cũng ngăn việc ghi cấp khối vào đĩa khởi động, vì vậy bạn không thể bỏ qua nó theo cách đó.

  Danh sách đầy đủ các thư mục bị hạn chế (và ngoại lệ như /usr/localvà một vài thư mục khác) nằm trong /System/Library/Sandbox/rootless.conf. Tất nhiên, tập tin này là chính nó trong một khu vực hạn chế.

  Khi bạn nâng cấp lên El Capitan, nó sẽ di chuyển mọi tệp "trái phép" từ các khu vực bị hạn chế sang /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• Bạn không thể đính kèm vào các quy trình hệ thống (ví dụ: các quy trình chạy từ các vị trí hệ thống đó) cho những thứ như gỡ lỗi (hoặc thay đổi thư viện động mà chúng tải hoặc một số thứ khác). Một lần nữa, không quá nhiều của một vấn đề lớn; nhà phát triển vẫn có thể gỡ lỗi chương trình của riêng họ.

  Điều này không chặn một số thứ quan trọng như tiêm mã vào các ứng dụng tích hợp của Apple (đáng chú ý là Finder). Điều đó cũng có nghĩa là dtracecác công cụ dựa trên cơ sở để giám sát hệ thống (ví dụ opensnoop) sẽ không thể giám sát và báo cáo về nhiều quy trình hệ thống.

• Bạn không thể tải các phần mở rộng kernel (kexts) trừ khi chúng được ký hợp lệ (tức là bởi Apple hoặc nhà phát triển được Apple chấp thuận). Lưu ý rằng điều này thay thế hệ thống cũ để thực thi ký kext (và các cách cũ để bỏ qua nó). Nhưng kể từ phiên bản v10.10.4, Apple đã có cách kích hoạt hỗ trợ cắt xén cho SSD của bên thứ ba , lý do số 1 để sử dụng kexts không dấu đã biến mất.

• Bắt đầu từ Sierra (10.12), một số cài đặt cấu hình launchd không thể thay đổi (ví dụ: một số trình nền khởi chạy không thể được tải).

• Bắt đầu từ Mojave (10.14), quyền truy cập vào thông tin cá nhân của người dùng (email, danh bạ, v.v.) bị hạn chế đối với các ứng dụng mà người dùng đã chấp thuận để truy cập thông tin đó. Đây thường được coi là một tính năng riêng biệt (được gọi là Bảo vệ thông tin cá nhân hoặc TCC), nhưng nó dựa trên SIP và vô hiệu hóa SIP cũng vô hiệu hóa nó. Xem: "MacOS Mojave thực hiện những gì và làm thế nào để hạn chế các ứng dụng truy cập vào dữ liệu cá nhân?"

Nếu bạn không muốn những hạn chế này - vì bạn muốn sửa đổi hệ thống của mình vượt quá những gì điều này cho phép hoặc vì bạn đang phát triển và gỡ lỗi một cái gì đó như kexts không thực tế theo những hạn chế này, bạn có thể tắt SIP. Hiện tại điều này yêu cầu khởi động lại vào chế độ phục hồi và chạy lệnh csrutil disable(và bạn có thể kích hoạt lại tương tự với nó csrutil enable).

Bạn cũng có thể vô hiệu hóa có chọn lọc các phần của SIP. Ví dụ: csrutil enable --without kextsẽ vô hiệu hóa hạn chế mở rộng kernel của SIP, nhưng để lại các biện pháp bảo vệ khác.

Nhưng vui lòng dừng lại và suy nghĩ trước khi vô hiệu hóa SIP, thậm chí tạm thời hoặc một phần: bạn có thực sự cần phải vô hiệu hóa nó không, hoặc có cách nào tốt hơn (tuân thủ SIP) để làm những gì bạn muốn không? Bạn có thực sự cần phải sửa đổi một cái gì đó trong /System/Libraryhoặc /binbất cứ điều gì, hoặc nó có thể đi ở một nơi tốt hơn như /Libraryhoặc /usr/local/binvv? SIP có thể "cảm thấy" bị ràng buộc nếu bạn không quen với nó, và có một số lý do chính đáng để vô hiệu hóa nó, nhưng rất nhiều điều mà nó thực thi nó thực sự chỉ là cách thực hành tốt nhất.

Để nhấn mạnh tầm quan trọng của việc để lại càng nhiều SIP được kích hoạt càng nhiều càng tốt, hãy xem xét các sự kiện vào ngày 23 tháng 9 năm 2019. Google đã phát hành bản cập nhật cho Chrome đã cố gắng thay thế liên kết tượng trưng từ /varđến /private/var. Trên hầu hết các hệ thống, SIP đã chặn điều này và không có tác động xấu. Trên các hệ thống có SIP bị vô hiệu hóa, nó khiến macOS bị hỏng và không thể khởi động. Lý do phổ biến nhất để vô hiệu hóa SIP là tải các phần mở rộng kernel không được phê duyệt (/ ký không đúng) (cụ thể là trình điều khiển video); nếu họ chỉ vô hiệu hóa hạn chế kext, họ sẽ không bị ảnh hưởng. Xem chủ đề hỗ trợ chính thức của Google , hỏi đáp siêu người dùng trên đó và bài viết của Ars Technica .

Tài liệu tham khảo và thông tin thêm: Bài thuyết trình của WWDC về "Bảo mật và ứng dụng của bạn" , một lời giải thích hay của Eldad Eilam trên quora.com , bài đánh giá của Ars Technica về El Capitan và bài viết hỗ trợ của Apple về SIP và bài viết sâu sắc của Rich Trouton ( ai cũng đăng một câu trả lời cho câu hỏi này ).

Đối với tôi, nó có nghĩa là DTrace không còn hoạt động.

DTrace tương tự như ptrace / strace trong Linux, ở chỗ nó cho phép bạn xem một quy trình đang nói gì với kernel. Mỗi khi một quá trình muốn mở một tệp, viết một tệp hoặc mở một cổng, v.v., nó cần phải hỏi kernel. Trong Linux, quy trình giám sát này xảy ra bên ngoài hạt nhân trong "vùng người dùng" và do đó, các quyền là khá chi tiết. Một người dùng có thể giám sát các ứng dụng của riêng họ (để sửa lỗi, tìm rò rỉ bộ nhớ, v.v.) nhưng sẽ cần phải root để theo dõi quá trình của người dùng khác.

DTrace trên OSX tuy nhiên hoạt động ở cấp kernel, làm cho nó hiệu quả và mạnh mẽ hơn nhiều, tuy nhiên, nó yêu cầu quyền truy cập root để thêm các đầu dò của nó vào kernel và do đó làm bất cứ điều gì. Người dùng không thể theo dõi các quy trình của riêng mình mà không cần root, nhưng với quyền root, họ không chỉ có thể xem các quy trình của riêng mình mà trên thực tế TẤT CẢ các quy trình trên hệ thống. Ví dụ: bạn có thể xem một tệp (với iosnoop) và xem quá trình nào đọc nó. Đây là một trong những tính năng hữu ích nhất để phát hiện phần mềm độc hại. Bởi vì kernel cũng giao dịch với IO mạng, điều tương tự cũng đúng ở đó. Wireshark phát hiện hoạt động mạng bất thường, DTrace cho bạn biết quá trình gửi dữ liệu, ngay cả khi nó được nhúng vào hệ thống như chính hạt nhân.

Tuy nhiên, kể từ El Capitan, Apple đã cố tình ngăn DTrace hoạt động - vì trong đó, nó đã được nhắm mục tiêu cụ thể và được chỉ ra là một thứ mà SIP hạn chế. Tại sao họ làm điều đó? Chà, trước đây Apple đã sửa đổi kernel và DTrace của họ để cho phép một số quy trình từ chối theo dõi thông qua DTrace (điều này làm đảo lộn rất nhiều nhà nghiên cứu bảo mật tại thời điểm đó vì một số quy trình hiện đã vượt quá giới hạn ngay cả khi root - bao gồm phần mềm độc hại). Lý do của họ cho việc này là để bảo vệ DRM trong các ứng dụng như iTunes vì ​​về mặt lý thuyết, ai đó có thể DTrace và lấy dữ liệu không phải DRM ra khỏi bộ nhớ của các quy trình.

Tuy nhiên, có một công việc quan trọng cho phép các nhà nghiên cứu tiếp tục thực hiện công việc của họ và đó là sửa đổi kernel để bỏ qua cờ từ chối này, vì vậy DTrace vẫn có thể được sử dụng trên các quy trình này. Điều này thực sự tuyệt vời vì các chương trình đang cố gắng tránh sự phát hiện nơi hiện đang sáng lên với cờ không có DTrace này. Bất cứ điều gì Apple hay những kẻ xấu muốn che giấu giờ đây đều hiện rõ ...

Nhưng hiện tại nó không hoạt động, vậy điều này ảnh hưởng đến bạn như thế nào? Vâng, nó sẽ ảnh hưởng đến bạn cả trực tiếp và gián tiếp. Trực tiếp, nó sẽ hạn chế khả năng giám sát hệ thống của bạn. Một số lượng lớn các công cụ giám sát và quản trị hệ thống cấp thấp (mà các công cụ cấp cao hơn xây dựng) sẽ không còn hoạt động. Tuy nhiên, hiệu ứng gián tiếp sẽ lớn hơn nhiều - các chuyên gia bảo mật dựa vào quyền truy cập hệ thống sâu để phát hiện các loại mối đe dọa tồi tệ nhất. Chúng tôi chỉ đơn giản là không thể làm điều đó nữa. Điều quan trọng khi phân tích phần mềm độc hại là nó không biết nó đang chạy trong trình gỡ lỗi hoặc honeypot. Vô hiệu hóa SIP cho tất cả các phần mềm, từ cả kẻ xấu và Apple, rằng hệ thống này đang được theo dõi. Không còn xem những người theo dõi. Nếu SIP là về bảo mật, họ có thể đã giáo dục người dùng về root - thay vào đó họ đã gỡ bỏ nó. Cuối cùng, điều này có nghĩa là Apple đã thay thế hàng rào bảo mật 'là tất cả và chấm dứt tất cả' mật khẩu gốc, với cơ chế bảo vệ SIP là 'tất cả và kết thúc tất cả'. Hoặc nếu bạn giỏi về kỹ thuật xã hội, mật khẩu root với khởi động lại ...

Ngoài ra còn có điều này:

Bảo vệ toàn vẹn hệ thống (SIP) là một chính sách bảo mật tổng thể với mục tiêu ngăn chặn các tệp và quy trình hệ thống khỏi bị sửa đổi bởi các bên thứ ba. Để đạt được điều này, nó có các khái niệm sau:

• Bảo vệ hệ thống tập tin
• Bảo vệ mở rộng hạt nhân
• Bảo vệ thời gian chạy

Bảo vệ hệ thống tập tin

SIP ngăn các bên khác ngoài Apple thêm, xóa hoặc sửa đổi các thư mục và tệp được lưu trữ trong các thư mục nhất định:

/bin
/sbin
/usr
/System

Apple đã chỉ ra rằng các thư mục sau đây có sẵn để các nhà phát triển truy cập:

/usr/local
/Applications
/Library
~/Library

Tất cả các thư mục /usrngoại trừ /usr/localđược bảo vệ bởi SIP.

Có thể thêm, xóa hoặc thay đổi các tệp và thư mục được bảo vệ SIP thông qua gói cài đặt được ký bởi cơ quan chứng nhận của chính Apple. Điều này cho phép Apple thực hiện các thay đổi đối với các bộ phận được bảo vệ SIP của HĐH mà không cần thay đổi các biện pháp bảo vệ SIP hiện có.

Cơ quan cấp chứng chỉ trong câu hỏi được Apple dành riêng cho việc sử dụng riêng của họ; Các gói trình cài đặt có chữ ký của nhà phát triển không thể thay đổi các tệp hoặc thư mục được bảo vệ SIP.

Để xác định thư mục nào được bảo vệ, Apple hiện đã xác định hai tệp cấu hình trên hệ thống tệp. Cái chính được tìm thấy ở vị trí bên dưới:

/System/Library/Sandbox/rootless.conf

nơi rootless.confliệt kê tất cả các ứng dụng và cấp cao nhất của các thư mục mà SIP đang bảo vệ.

Các ứng dụng

SIP đang bảo vệ các ứng dụng cốt lõi mà OS X cài đặt vào Ứng dụng và Tiện ích ứng dụng. Điều này có nghĩa là sẽ không còn có thể xóa các ứng dụng mà OS X cài đặt, ngay cả từ dòng lệnh khi sử dụng quyền root.

Thư mục

SIP cũng đang bảo vệ một số thư mục và liên kết tượng trưng bên ngoài /Applicationsvà cấp cao nhất của các thư mục đó cũng được liệt kê trong rootless.conf.

Ngoài các biện pháp bảo vệ, Apple cũng đã xác định một số ngoại lệ đối với bảo vệ của SIP trong tệp rootless.conf và các ngoại lệ đó được đánh dấu bằng dấu hoa thị. Những miễn trừ từ bảo vệ của SIP có nghĩa là có thể thêm, xóa hoặc thay đổi các tệp và thư mục trong các vị trí đó.

Trong số các trường hợp ngoại lệ đó là:

• /System/Library/User Template - nơi OS X lưu trữ các thư mục mẫu mà nó sử dụng khi tạo thư mục gốc cho các tài khoản mới.
• /usr/libexec/cups - nơi OS X lưu trữ thông tin cấu hình máy in

Apple coi tập tin này là của họ và mọi thay đổi của bên thứ ba đối với nó sẽ bị Apple ghi đè.

Để xem tập tin nào đã được SIP bảo vệ, hãy sử dụng lslệnh có dấu gạch ngang O trong Terminal:

ls -O

Các tập tin được bảo vệ SIP sẽ được dán nhãn là hạn chế .

Một điều quan trọng cần biết là ngay cả khi một liên kết tượng trưng được bảo vệ bởi SIP, điều đó không nhất thiết có nghĩa là thư mục mà chúng liên kết đến đang được SIP bảo vệ. Ở cấp độ gốc của ổ đĩa khởi động OS X El Capitan, có một số liên kết tượng trưng được bảo vệ SIP trỏ đến các thư mục được lưu trữ bên trong thư mục cấp gốc có tên private.

Tuy nhiên, khi nội dung của privatethư mục được kiểm tra, các thư mục mà các liên kết tượng trưng đó không được bảo vệ bởi SIP và cả chúng và nội dung của chúng có thể được di chuyển, chỉnh sửa hoặc thay đổi bởi các quy trình sử dụng quyền root.

Ngoài danh sách các trường hợp ngoại lệ SIP mà Apple đã đặt rootless.conf, còn có một danh sách ngoại lệ SIP thứ hai. Danh sách này bao gồm một số thư mục và tên ứng dụng cho các sản phẩm của bên thứ ba. Tương tự như vậy rootless.conf, danh sách loại trừ này là của Apple và mọi thay đổi của bên thứ ba đối với danh sách này sẽ bị Apple ghi đè.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Bảo vệ thời gian chạy

Sự bảo vệ của SIP không giới hạn trong việc bảo vệ hệ thống khỏi những thay đổi của hệ thống tập tin. Ngoài ra còn có các cuộc gọi hệ thống hiện bị hạn chế trong chức năng của họ.

• task_for_pid () / bộ xử lý_set_t Nhiệm vụ () không thành công với EPERM
• Các cổng đặc biệt Mach được đặt lại trên exec (2)
• biến môi trường dyld bị bỏ qua
• Đầu dò DTrace không có sẵn

Tuy nhiên, SIP không chặn sự kiểm tra của nhà phát triển ứng dụng của chính họ khi chúng đang được phát triển. Các công cụ của Xcode sẽ tiếp tục cho phép các ứng dụng được kiểm tra và gỡ lỗi trong quá trình phát triển.

Để biết thêm chi tiết về điều này, tôi khuyên bạn nên xem tài liệu dành cho nhà phát triển của Apple cho SIP .

Bảo vệ mở rộng hạt nhân

SIP chặn cài đặt các phần mở rộng kernel không dấu. Để cài đặt tiện ích mở rộng kernel trên OS X El Capitan có bật SIP, tiện ích mở rộng kernel phải:

1. Được ký với ID nhà phát triển để ký chứng chỉ Kexts
2. Cài đặt vào / Thư viện / Tiện ích mở rộng

Nếu cài đặt một phần mở rộng kernel không dấu, SIP sẽ cần phải bị vô hiệu hóa trước tiên.

Để biết thêm thông tin về việc quản lý SIP, vui lòng xem liên kết dưới đây:

Bảo vệ toàn vẹn hệ thống - Thêm một lớp khác vào mô hình bảo mật của Apple