Cơ chế System Integrity Protection (SIP) trên OS X El Capitan 10.11 là gì?

14/03/2017

TIPS-TRICKS

0 0

Bài viết mang tính chất phân tích và tham khảo cho cả người dùng Hack và Mac, nhưng các thay đổi về bảo mật trên Mac thật diễn ra dễ dàng hơn nhờ có công cụ được hỗ trợ bởi Apple. Nếu không am hiểu về hệ thống, cũng như bảo mật, tôi không khuyến cáo người dùng Mac thật áp dụng kiến thức bài viết này.
Nếu các bạn đã ngồi xem đi xem lại WWDC 2015, chắc hẳn thấy rõ Apple nhấn mạnh về cơ chế bảo mới cho hệ điều hành OS X 10.11 El Capitan.

Cụ thể Apple sẽ sử dụng hệ thống phòng thủ đa tầng và khắc phục tối đa các điểm yếu của hệ điều hành, VD: trước đây chỉ cần người dùng nắm được quyền Root của máy thì có thể vô hiệu hoá hoàn toàn hệ thống an ninh của hệ điều hành và Apple thấy điều này nên tương lai sẽ rất khó làm được….

Để làm được điều này, Apple tăng cường mức độ xác nhận tin cậy và an toàn của hệ thống. Với SIP, Apple có thể:
+ Hạn chế tối đa quyền của của root-a
+ Bảo vệ sự toàn vẹn của hệ thống, phân vùng và bộ nhớ.

Việc bảo vệ hệ thống tập tin
Thư mục, được điều khiển bởi SIP
/System
/Bin
/Usr
/Sbin
Các thư mục này giờ đây không thể dễ dàng sửa đổi thông qua quyền root nữa, nó chỉ được cập nhật với các thay đổi do Apple tiến hành thông qua Sofware Update của hệ thống. Các tập tin của hệ điều hành điều được gắn cờ đặc biệt.
Cơ chế bảo mật được áp dụng lên vùng hệ thống và cả Recovery. Nếu muốn vô hiệu hoá được( như bên dưới sẽ trình bày) SIP yêu cầu bạn phải vô hiệu hoá nó từ ngoài Recovery HD, restart lại nó sẽ áp dụng thay đổi lên phân vùng hệ thống.

Tuy là vậy, Apple cũng tính toán khả năng làm việc cho các nhà phát triển( developer) bằng cách thiết kế cơ chế bảo mật thấp hơn ở các vị trí đặc biệt như:
~ / Library
/Library
/Usr/local
/Applications

Việc bảo vệ Kernel Extensions( kext)
Trong /System/Library/Extensions mai mốt đây chỉ còn các kext do chính Apple xây dựng và có liên can trong quá trình đưa vào đó, không có tuỳ tiện cài vào được nữa.
Riêng đối với các developer, ngoài việc đăng kí với Apple, họ chỉ có thể cài đặt kext do mình xây dựng và /Library/Extensions.

Key kext-dev-mode( cho phép sign tắt chế độ kiểm duyệt kext sẽ cài đặt vào /S/L/E) đã không còn tác dụng như Apple từng nói sẽ xoá đi trong WWDC đoạn Security & Your app của mình.

Việc tắt chế độ SIP
Làm thì căng thế thôi, chứ Apple vẫn cho phép người dùng, nếu muốn, vẫn có thể tắt SIP đi( dù không được khuyến cáo vì lí do bảo mật và an toàn hệ thống).
Đội ngủ phát triển của Apple, hỗ trợ bạn nốt việc này bằng công cụ System Configuration do họ phát hành. Dù vậy quyền root vẫn được yêu cầu? Tại sao? Vì SIP được cấu hình và lưu lại trong NVRAM, nhưng nếu phát hiện bất kỳ truy cập nào để thay đổi mà không được cấp phép, nó sẽ tự bật mã hoá và đóng kín cửa theo một cơ chế mà chỉ có ông làm ra nó mới biết.

Bây giờ, chúng ta sẽ nói về các OS X El Capitan Developer Beta và SIP
Trong bản beta 1 hay dev 1, SIP được kích hoạt mặc định khi cài đặt.
Ứng dụng chính thức như trên đã nói có thể vô hiệu hoá SIP đi, chỉ dành cho các máy Mac thật và yêu cầu quyền root.
Với Hackintosh, SIP-Recovery HD không thể nào vô hiệu hoá được( do SIP giờ ko còn được lưu ở NVRAM), mà thực ra nhiều máy Hack làm gì có Recovery để thực hiện, SIP mặc nhiên áp dụng lên phân vùng hệ thống và ngang cấp với quyền root-a.

Các Hackintosher nhanh chóng phát hiện điều này, họ đã tìm ra được cách vô hiệu hoá SIP khi khởi động bằng tham số truyền vào rootless=1.
Nhưng đấy chỉ còn tác dụng tới Beta 3 thôi, nó miễn nhiễm với các phiên bản update tiếp theo từ Apple. Đâu có dễ ăn vậy được chứ

Đây là kĩ thuật của SIP để các bạn hiểu rõ:
Khi bắt đầu tiến hành cài đặt OS X, các tập tin được ghi vào phân vùng hệ thống, các tập tin quan trọng sẽ được gắn cờ đặc biệt – hạn chế quyền can thiệp.

nmkhoi$ ls -lO /System/Library/
total 0
drwxr-xr-x    4 root  wheel  restricted  136  20 Aug 09:26 Accessibility
drwxr-xr-x    7 root  wheel  restricted  238  20 Aug 09:25 Accounts
drwxr-xr-x    8 root  wheel  restricted  272  20 Aug 09:23 Address Book Plug-Ins
drwxr-xr-x    3 root  wheel  restricted  102 15 May 23:19 Assistant
drwxr-xr-x  293 root  wheel  restricted  9962  20 Aug 09:30 Automator
drwxr-xr-x    5 root  wheel  restricted  170  20 Aug 09:24 BridgeSupport
drwxr-xr-x    9 root  wheel  restricted  306  20 Aug 09:33 CacheDelete
drwxr-xr-x   14 root  wheel  -          476 20 Aug 12:44 Caches
drwxr-xr-x    4 root  wheel  restricted  136  20 Aug 09:26 ColorSync
drwxr-xr-x    6 root  wheel  restricted  204  20 Aug 08:35 Colors

Nếu SIP bị vô hiệu hoá thì bạn hoàn toàn có thể thay đổi cách gắn cờ cho bất kỳ tập tin hệ thống nào, kèm theo đó là quyền có thể thay đổi các cài đặt có liên quan và ngược lại. VD: khi tắt SIP tôi có thể gắn một cờ khác cho AppleHDA.kext

Mã:

sudo chflags -R norestricted /System/Library/Extensions/AppleHDA.kext

Nơi cất giữ bí mật của SIP
Tất cả các quy định về hệ thống tập tin được bảo vệ, ngoại lệ, có thể bổ sung ngoại lệ…của SIP điều được lưu trữ tại /System/Library/Sandbox/rootless.conf
Tập tin rootless.conf hạn chế quyền chính sửa hay thay đổi, theo đó nội dung bên trong sẽ được Apple cập nhật thông qua các bản update tung ra định kỳ hoặc khi cần thiết.

        
           /System
*         /System/Library/Caches
*         /System/Library/Extensions
                    /System/Library/Extensions/*
...

– Các đường dẫn như / : là nơi sẽ được bảo vệ nghiêm ngặt. Không thể làm gì tác động khi SIP bật.
– Các đường dẫn có đánh * phía trước: các tập tin bên trong đó không được bảo vệ, đây là ngoại lệ.
– Các đường dẫn có đánh * phía sau: các tập tin bên trong được bảo vệ.

Cụ thể:

+ /System: đường dẫn hệ thống tất cả sẽ được bảo vệ
+ * /System/Library/Caches: ngoại lệ không được bảo vệ.
+ * /System/Library/Extensions/: Ngoại lệ không được bảo vệ. (1)
+ /System/Library/Extensions/*: được bảo vệ(2)
Cái quy tắc (1) và (2) bạn sẽ thấy mẫu thuẫn đúng ko? Nhưng ý Apple là: vẫn có thể cài kext vào bên trong /S/L/E nhưng các kext của Apple sẽ được bảo vệ nghiêm ngặt và không thể tác động( patch, mod). Trường hợp này chỉ xuất hiện trên bản El Capitan Dev beta 1-3 thôi, giờ thì không còn nữa. /S/L/E đã được bảo vệ nghiêm ngặt.

Vậy Hackintosh trên OS X 10.11 chết rồi, vì không thể cài kext?
Hiện giờ thì vẫn chưa có câu trả lời chính xác về vấn đề này, vì khi Apple chính thức công bố OS X El Capitan 10.11 vào tháng 9-10 tới đây sẽ bao gồm những thay đổi lớn gì? Bên cạnh đó “vỏ quýt dày thì có móng tay nhọn”, các dev Clover vẫn đang chiến đấu với từng khe hỡ của SIP và tung ra bản cập nhật với binary mới có tác dụng vô hiệu hoá SIP.

Hiện giờ phương pháp cài Kext và modify kext( patch) trên OS X 10.11 chỉ có thể thực hiện bằng cách:
– Cập nhật lên Clover r3251 hoặc mới hơn
– Add tham số sau vào Clover Config:

<key>RtVariables</key>
    <dict>
        <key>CsrActiveConfig</key>
        <string>0x67</string>
    </dict>

– Bật rootless=1
– kext-dev-mode=0 không còn quan trọng nữa.
– Đặt kext đã qua modify và /Clover/Extensions/xxx

Các lưu ý:
+ Disk Utility luôn hiển thị kết quả về bảo mật là có nhưng quan trong là chúng ta có tác động được hay ko vào file.
+ Disk Repair Permissions không có bất kỳ liên quan nào đến việc thay đổi cơ chế bảo mật của hệ thống, nó được sinh ra trong quá trình cài đặt hoặc update. Vì vậy đừng dùng nó để hy vọng thay đổi quyền thực thi read/write.

Lưu ý cần đọc

Thắc mắc và lỗi tham gia MacLife Group. Cộng đồng sẽ HỖ TRỢ RẤT NHANH
Để cài được ứng dụng ngoài App Store bạn cần phải tắt Gatekeeper theo hướng dẫn ở đây.
Một số Apps (rất ít, nếu có sẽ ghi chú ở cuối post) yêu cầu thêm tắt SIP cách SIP tham khảo ở đây