Triển khai bảo mật

Nhóm bảo mật Android thường xuyên nhận được yêu cầu cung cấp thông tin về cách ngăn chặn các sự cố bảo mật tiềm ẩn trên thiết bị Android. Đôi khi, chúng tôi cũng phát hiện các thiết bị kiểm tra và thông báo cho nhà sản xuất thiết bị cũng như đối tác bị ảnh hưởng biết về các sự cố tiềm ẩn.

Trang này cung cấp các phương pháp bảo mật tốt nhất dựa trên kinh nghiệm của chúng tôi, mở rộng tài liệu Thiết kế bảo mật mà chúng tôi đã cung cấp cho nhà phát triển và bao gồm các chi tiết riêng về xây dựng hoặc cài đặt phần mềm cấp hệ thống trên thiết bị.

Để tạo điều kiện thuận lợi cho việc áp dụng các phương pháp hay nhất này, nếu có thể, Nhóm bảo mật Android sẽ kết hợp các thử nghiệm vào Bộ kiểm tra khả năng tương thích của Android (CTS) và Android Lint . Chúng tôi khuyến khích những người triển khai thiết bị đóng góp các thử nghiệm có thể trợ giúp những người dùng Android khác (xem các thử nghiệm liên quan đến bảo mật tại root/cts/tests/tests/security/src/android/security/cts ).

Quá trình phát triển

Sử dụng các phương pháp hay nhất sau đây trong quy trình và môi trường phát triển của bạn.

Xem lại mã nguồn

Việc xem xét mã nguồn có thể phát hiện nhiều vấn đề bảo mật, bao gồm cả những vấn đề được xác định trong tài liệu này. Android đặc biệt khuyến khích việc xem xét mã nguồn thủ công và tự động. Thực hành tốt nhất:

• Chạy Android Lint trên tất cả mã ứng dụng bằng SDK Android và khắc phục mọi sự cố đã xác định.
• Mã gốc phải được phân tích bằng công cụ tự động có thể phát hiện các vấn đề về quản lý bộ nhớ như tràn bộ đệm và lỗi từng lỗi một.
• Hệ thống xây dựng Android có hỗ trợ cho nhiều công cụ khử trùng LLVM, chẳng hạn như Trình khử trùng địa chỉ và Trình khử trùng hành vi không xác định có thể được sử dụng cho mục đích này.

Sử dụng thử nghiệm tự động

Kiểm tra tự động có thể phát hiện nhiều vấn đề bảo mật, bao gồm một số vấn đề được thảo luận bên dưới. Thực hành tốt nhất:

• CTS được cập nhật thường xuyên với các bài kiểm tra bảo mật; chạy phiên bản CTS mới nhất để xác minh tính tương thích.
• Chạy CTS thường xuyên trong suốt quá trình phát triển để phát hiện sớm vấn đề và giảm thời gian khắc phục. Android sử dụng CTS như một phần của quá trình tích hợp liên tục trong quy trình xây dựng tự động của chúng tôi, quy trình này xây dựng nhiều lần mỗi ngày.
• Các nhà sản xuất thiết bị nên tự động hóa việc kiểm tra tính bảo mật của các giao diện, bao gồm cả việc kiểm tra các đầu vào không đúng định dạng (kiểm tra lông tơ).

Hình ảnh hệ thống chữ ký

Chữ ký của hình ảnh hệ thống rất quan trọng để xác định tính toàn vẹn của thiết bị. Thực hành tốt nhất:

• Thiết bị không được ký bằng khóa được công khai.
• Các khóa dùng để ký thiết bị phải được quản lý theo cách phù hợp với các thông lệ tiêu chuẩn ngành để xử lý các khóa nhạy cảm, bao gồm cả mô-đun bảo mật phần cứng (HSM) cung cấp quyền truy cập hạn chế, có thể kiểm tra được.

Ký ứng dụng (APK)

Chữ ký ứng dụng đóng vai trò quan trọng trong bảo mật thiết bị và được sử dụng để kiểm tra quyền cũng như cập nhật phần mềm. Khi chọn một khóa để sử dụng để ký ứng dụng, điều quan trọng là phải xem xét liệu một ứng dụng sẽ chỉ khả dụng trên một thiết bị hay dùng chung trên nhiều thiết bị. Thực hành tốt nhất:

• Các ứng dụng không được ký bằng một khóa được công khai.
• Các khóa dùng để ký ứng dụng phải được quản lý theo cách phù hợp với các thông lệ tiêu chuẩn ngành để xử lý các khóa nhạy cảm, bao gồm cả HSM cung cấp quyền truy cập hạn chế, có thể kiểm tra được.
• Các ứng dụng không nên được ký bằng khóa nền tảng.
• Các ứng dụng có cùng tên gói không được ký bằng các khóa khác nhau. Điều này thường xảy ra khi tạo ứng dụng cho các thiết bị khác nhau, đặc biệt là khi sử dụng phím nền tảng. Nếu ứng dụng độc lập với thiết bị, hãy sử dụng cùng một khóa trên các thiết bị. Nếu ứng dụng dành riêng cho thiết bị, hãy tạo tên gói duy nhất cho mỗi thiết bị và khóa.

Xuất bản ứng dụng

Google Play cung cấp cho nhà sản xuất thiết bị khả năng cập nhật ứng dụng mà không cần thực hiện cập nhật hệ thống hoàn chỉnh. Điều này có thể đẩy nhanh quá trình phản hồi các vấn đề bảo mật và cung cấp các tính năng mới, cũng như cung cấp cách đảm bảo ứng dụng của bạn có tên gói duy nhất. Thực hành tốt nhất:

• Tải ứng dụng của bạn lên Google Play để cho phép cập nhật tự động mà không yêu cầu cập nhật hoàn toàn qua mạng (OTA). Các ứng dụng đã được tải lên nhưng chưa được xuất bản thì người dùng không thể tải xuống trực tiếp nhưng các ứng dụng vẫn được cập nhật. Người dùng đã cài đặt ứng dụng trước đó có thể cài đặt lại ứng dụng đó và/hoặc cài đặt trên các thiết bị khác.
• Tạo tên gói ứng dụng được liên kết rõ ràng với công ty của bạn, chẳng hạn như bằng cách sử dụng nhãn hiệu của công ty.
• Các ứng dụng do nhà sản xuất thiết bị xuất bản phải được tải lên cửa hàng Google Play để tránh người dùng bên thứ ba mạo danh tên gói. Nếu nhà sản xuất thiết bị cài đặt ứng dụng trên thiết bị mà không xuất bản ứng dụng đó trên Cửa hàng Play thì nhà phát triển khác có thể tải ứng dụng tương tự lên, sử dụng cùng tên gói và thay đổi siêu dữ liệu cho ứng dụng. Khi ứng dụng được hiển thị cho người dùng, siêu dữ liệu không liên quan này có thể gây nhầm lẫn.

Ứng phó với sự cố

Các bên bên ngoài phải có khả năng liên hệ với nhà sản xuất thiết bị về các vấn đề bảo mật dành riêng cho thiết bị. Chúng tôi khuyên bạn nên tạo một địa chỉ email có thể truy cập công khai để quản lý các sự cố bảo mật. Thực hành tốt nhất:

• Tạo địa chỉ security@your-company.com hoặc địa chỉ tương tự và công khai nó.
• Nếu bạn nhận thấy sự cố bảo mật ảnh hưởng đến hệ điều hành Android hoặc thiết bị Android từ nhiều nhà sản xuất thiết bị, bạn nên liên hệ với Nhóm bảo mật Android bằng cách gửi báo cáo lỗi Bảo mật .

Triển khai sản phẩm

Hãy sử dụng các phương pháp hay nhất sau đây khi triển khai sản phẩm.

Cô lập các tiến trình gốc

Các tiến trình gốc là mục tiêu thường xuyên nhất của các cuộc tấn công leo thang đặc quyền, do đó việc giảm số lượng các tiến trình gốc sẽ giảm nguy cơ leo thang đặc quyền. CTS bao gồm một bài kiểm tra thông tin liệt kê các tiến trình gốc. Thực hành tốt nhất:

• Các thiết bị nên chạy mã cần thiết tối thiểu dưới dạng root. Nếu có thể, hãy sử dụng quy trình Android thông thường thay vì quy trình root. ICS Galaxy Nexus chỉ có sáu quy trình gốc: vold, inetd, zygote, tf_daemon, ueventd và init. Nếu một quy trình phải chạy bằng quyền root trên thiết bị, hãy ghi lại quy trình đó trong yêu cầu tính năng AOSP để quy trình đó có thể được xem xét công khai.
• Nếu có thể, mã gốc phải được tách biệt khỏi dữ liệu không đáng tin cậy và được truy cập qua IPC. Ví dụ: giảm chức năng gốc xuống một Dịch vụ nhỏ có thể truy cập thông qua Binder và hiển thị Dịch vụ có quyền chữ ký cho một ứng dụng có đặc quyền thấp hoặc không có đặc quyền để xử lý lưu lượng truy cập mạng.
• Quá trình root không được lắng nghe trên ổ cắm mạng.
• Các tiến trình gốc không được cung cấp thời gian chạy có mục đích chung cho các ứng dụng (ví dụ: máy ảo Java).

Cách ly ứng dụng hệ thống

Nói chung, các ứng dụng được cài đặt sẵn không nên chạy với UID hệ thống dùng chung. Tuy nhiên, nếu cần thiết để ứng dụng sử dụng UID chung của hệ thống hoặc dịch vụ đặc quyền khác, ứng dụng đó không được xuất bất kỳ dịch vụ, bộ thu phát sóng hoặc nhà cung cấp nội dung nào mà ứng dụng bên thứ ba do người dùng cài đặt có thể truy cập. Thực hành tốt nhất:

• Các thiết bị phải chạy mã cần thiết tối thiểu dưới dạng hệ thống. Nếu có thể, hãy sử dụng quy trình Android với UID riêng thay vì sử dụng lại UID hệ thống.
• Nếu có thể, mã hệ thống phải được tách biệt khỏi dữ liệu không đáng tin cậy và chỉ hiển thị IPC cho các quy trình đáng tin cậy khác.
• Các quy trình hệ thống không được lắng nghe trên ổ cắm mạng.

Quá trình cô lập

Hộp cát ứng dụng Android cung cấp cho ứng dụng khả năng cách ly với các quy trình khác trên hệ thống, bao gồm các quy trình gốc và trình gỡ lỗi. Trừ khi việc gỡ lỗi được ứng dụng và người dùng kích hoạt cụ thể, không có ứng dụng nào được phép vi phạm kỳ vọng đó. Thực hành tốt nhất:

• Quá trình root không được truy cập dữ liệu trong các thư mục dữ liệu ứng dụng riêng lẻ, trừ khi sử dụng phương pháp gỡ lỗi Android được ghi lại.
• Quá trình root không được truy cập vào bộ nhớ của ứng dụng, trừ khi sử dụng phương pháp gỡ lỗi Android được ghi lại.
• Thiết bị không được bao gồm bất kỳ ứng dụng nào truy cập dữ liệu hoặc bộ nhớ của các ứng dụng hoặc quy trình khác.

Bảo mật tập tin SUID

Các chương trình setuid mới sẽ không thể truy cập được bởi các chương trình không đáng tin cậy. Các chương trình Setuid thường là nơi chứa các lỗ hổng có thể được sử dụng để giành quyền truy cập root, vì vậy hãy cố gắng giảm thiểu khả năng cung cấp chương trình setuid cho các ứng dụng không đáng tin cậy. Thực hành tốt nhất:

• Các quy trình SUID không được cung cấp lớp vỏ hoặc cửa sau có thể được sử dụng để phá vỡ mô hình bảo mật của Android.
• Bất kỳ người dùng nào cũng không được phép ghi chương trình SUID.
• Các chương trình SUID không được có thể đọc hoặc thực thi được trên thế giới. Tạo một nhóm, giới hạn quyền truy cập vào tệp nhị phân SUID đối với các thành viên của nhóm đó và đặt bất kỳ ứng dụng nào có thể thực thi chương trình SUID vào nhóm đó.
• Các chương trình SUID là nguồn phổ biến để root thiết bị của người dùng. Để giảm thiểu rủi ro này, người dùng shell không được phép thực thi các chương trình SUID.

Trình xác minh CTS bao gồm một danh sách kiểm tra thông tin các tệp SUID; một số tệp setuid không được phép cho mỗi lần kiểm tra CTS.

Bảo vệ ổ cắm nghe

Kiểm tra CTS không thành công khi thiết bị đang nghe trên bất kỳ cổng nào, trên bất kỳ giao diện nào. Trong trường hợp xảy ra lỗi, Android sẽ xác minh các phương pháp hay nhất sau đây đang được sử dụng:

• Không nên có cổng nghe trên thiết bị.
• Cổng nghe phải có khả năng bị vô hiệu hóa mà không cần OTA. Đây có thể là thay đổi cấu hình máy chủ hoặc thiết bị người dùng.
• Quá trình root không được lắng nghe trên bất kỳ cổng nào.
• Các quy trình thuộc sở hữu của UID hệ thống không được lắng nghe trên bất kỳ cổng nào.
• Đối với IPC cục bộ sử dụng ổ cắm, các ứng dụng phải sử dụng Ổ cắm miền UNIX với quyền truy cập bị giới hạn trong một nhóm. Tạo bộ mô tả tệp cho IPC và đặt nó +RW cho một nhóm UNIX cụ thể. Mọi ứng dụng khách đều phải nằm trong nhóm UNIX đó.
• Một số thiết bị có nhiều bộ xử lý (ví dụ: radio/modem tách biệt với bộ xử lý ứng dụng) sử dụng ổ cắm mạng để liên lạc giữa các bộ xử lý. Trong những trường hợp như vậy, ổ cắm mạng được sử dụng để liên lạc giữa các bộ xử lý phải sử dụng giao diện mạng cách ly để ngăn chặn các ứng dụng trái phép trên thiết bị truy cập (nghĩa là sử dụng iptables để ngăn các ứng dụng khác trên thiết bị truy cập).
• Daemon xử lý các cổng nghe phải có khả năng chống lại dữ liệu không đúng định dạng. Google có thể tiến hành kiểm tra mờ đối với cổng bằng cách sử dụng ứng dụng khách trái phép và ứng dụng khách được ủy quyền nếu có thể. Mọi sự cố sẽ được coi là lỗi với mức độ nghiêm trọng thích hợp.

Ghi dữ liệu

Việc ghi nhật ký dữ liệu làm tăng nguy cơ lộ dữ liệu đó và làm giảm hiệu suất hệ thống. Nhiều sự cố an ninh công cộng đã xảy ra do việc ghi lại dữ liệu nhạy cảm của người dùng bằng các ứng dụng được cài đặt mặc định trên thiết bị Android. Thực hành tốt nhất:

• Các ứng dụng hoặc dịch vụ hệ thống không được ghi lại dữ liệu được cung cấp từ các ứng dụng của bên thứ ba có thể bao gồm thông tin nhạy cảm.
• Các ứng dụng không được ghi lại bất kỳ Thông tin nhận dạng cá nhân (PII) nào như một phần của hoạt động bình thường.

CTS bao gồm các thử nghiệm kiểm tra sự hiện diện của thông tin nhạy cảm tiềm ẩn trong nhật ký hệ thống.

Hạn chế truy cập thư mục

Các thư mục có thể ghi trên toàn thế giới có thể gây ra các điểm yếu về bảo mật và cho phép ứng dụng đổi tên các tệp đáng tin cậy, tệp thay thế hoặc tiến hành các cuộc tấn công dựa trên liên kết tượng trưng (kẻ tấn công có thể sử dụng liên kết tượng trưng đến một tệp để lừa một chương trình đáng tin cậy thực hiện các hành động không nên làm). Các thư mục có thể ghi cũng có thể ngăn việc gỡ cài đặt ứng dụng khỏi việc dọn dẹp đúng cách tất cả các tệp được liên kết với ứng dụng.

Theo cách tốt nhất, các thư mục được tạo bởi hệ thống hoặc người dùng root không được phép ghi trên toàn thế giới. Kiểm tra CTS giúp thực thi phương pháp tốt nhất này bằng cách kiểm tra các thư mục đã biết.

Bảo mật các tập tin cấu hình

Nhiều trình điều khiển và dịch vụ dựa vào cấu hình và tệp dữ liệu được lưu trữ trong các thư mục như /system/etc và /data . Nếu các tệp này được xử lý bằng quy trình đặc quyền và có thể ghi trên toàn thế giới thì ứng dụng có thể khai thác lỗ hổng trong quy trình bằng cách tạo nội dung độc hại trong tệp có thể ghi trên toàn thế giới. Thực hành tốt nhất:

• Các tệp cấu hình được sử dụng bởi các quy trình đặc quyền không được có thể đọc được trên thế giới.
• Các tệp cấu hình được sử dụng bởi các quy trình đặc quyền không được phép ghi trên toàn thế giới.

Lưu trữ thư viện mã gốc

Bất kỳ mã nào được sử dụng bởi quy trình của nhà sản xuất thiết bị đặc quyền đều phải nằm trong /vendor hoặc /system ; các hệ thống tập tin này được gắn ở chế độ chỉ đọc khi khởi động. Theo cách tốt nhất, các thư viện được hệ thống sử dụng hoặc các ứng dụng có đặc quyền cao khác được cài đặt trên thiết bị cũng phải nằm trong các hệ thống tệp này. Điều này có thể ngăn chặn lỗ hổng bảo mật có thể cho phép kẻ tấn công kiểm soát mã mà quy trình đặc quyền thực thi.

Hạn chế quyền truy cập trình điều khiển thiết bị

Chỉ mã đáng tin cậy mới có quyền truy cập trực tiếp vào trình điều khiển. Nếu có thể, kiến ​​trúc ưu tiên là cung cấp một daemon đơn mục đích để ủy quyền gọi trình điều khiển và hạn chế quyền truy cập của trình điều khiển vào daemon đó. Theo cách tốt nhất, các nút thiết bị trình điều khiển không được có thể đọc hoặc ghi được trên thế giới. Kiểm tra CTS giúp thực thi phương pháp tốt nhất này bằng cách kiểm tra các trường hợp trình điều khiển bị lộ đã biết.

Vô hiệu hóa ADB

Cầu gỡ lỗi Android (adb) là một công cụ phát triển và gỡ lỗi có giá trị nhưng được thiết kế để sử dụng trong môi trường được kiểm soát, an toàn và không được kích hoạt để sử dụng thông thường. Thực hành tốt nhất:

• ADB phải được tắt theo mặc định.
• ADB phải yêu cầu người dùng bật nó lên trước khi chấp nhận kết nối.

Mở khóa bootloader

Nhiều thiết bị Android hỗ trợ mở khóa, cho phép chủ sở hữu thiết bị sửa đổi phân vùng hệ thống và/hoặc cài đặt hệ điều hành tùy chỉnh. Các trường hợp sử dụng phổ biến bao gồm cài đặt ROM của bên thứ ba và thực hiện phát triển cấp hệ thống trên thiết bị. Ví dụ: chủ sở hữu thiết bị Google Nexus có thể chạy fastboot oem unlock để bắt đầu quá trình mở khóa, quá trình này sẽ hiển thị thông báo sau cho người dùng:

Theo phương pháp hay nhất, các thiết bị Android có thể mở khóa phải xóa tất cả dữ liệu người dùng một cách an toàn trước khi được mở khóa. Việc không xóa đúng cách tất cả dữ liệu khi mở khóa có thể cho phép kẻ tấn công ở gần về mặt vật lý có được quyền truy cập trái phép vào dữ liệu bí mật của người dùng Android. Để ngăn chặn việc tiết lộ dữ liệu người dùng, thiết bị hỗ trợ tính năng mở khóa phải thực hiện đúng cách (chúng tôi đã thấy nhiều trường hợp các nhà sản xuất thiết bị thực hiện việc mở khóa không đúng cách). Quá trình mở khóa được thực hiện đúng cách có các thuộc tính sau:

• Khi lệnh mở khóa được người dùng xác nhận, thiết bị phải bắt đầu xóa dữ liệu ngay lập tức. Cờ unlocked không được đặt cho đến khi quá trình xóa an toàn hoàn tất.
• Nếu không thể hoàn tất việc xóa an toàn, thiết bị phải ở trạng thái khóa.
• Nếu được hỗ trợ bởi thiết bị khối cơ bản, nên sử dụng ioctl(BLKSECDISCARD) hoặc tương đương. Đối với thiết bị eMMC, điều này có nghĩa là sử dụng lệnh Xóa an toàn hoặc Cắt an toàn. Đối với eMMC 4.5 trở lên, điều này có nghĩa là sử dụng thao tác Xóa hoặc Cắt thông thường, sau đó là thao tác Vệ sinh.
• Nếu BLKSECDISCARD không được thiết bị khối cơ bản hỗ trợ thì ioctl(BLKDISCARD) phải được sử dụng thay thế. Trên các thiết bị eMMC, đây là thao tác Cắt bình thường.
• Nếu BLKDISCARD không được hỗ trợ, việc ghi đè các thiết bị khối bằng tất cả số 0 có thể được chấp nhận.
• Người dùng cuối phải có tùy chọn yêu cầu xóa dữ liệu người dùng trước khi flash phân vùng. Ví dụ: trên thiết bị Nexus, việc này được thực hiện thông qua lệnh fastboot oem lock .
• Một thiết bị có thể ghi lại, thông qua cầu chì hoặc cơ chế tương tự, xem thiết bị đã được mở khóa và/hoặc khóa lại hay chưa.

Những yêu cầu này đảm bảo rằng tất cả dữ liệu sẽ bị hủy sau khi hoàn thành thao tác mở khóa. Việc không triển khai các biện pháp bảo vệ này được coi là lỗ hổng bảo mật ở mức độ vừa phải.

Một thiết bị đã được mở khóa sau đó có thể được khóa lại bằng lệnh fastboot oem lock . Việc khóa bộ nạp khởi động cung cấp khả năng bảo vệ dữ liệu người dùng tương tự với hệ điều hành tùy chỉnh mới như đã có với hệ điều hành ban đầu của nhà sản xuất thiết bị (ví dụ: dữ liệu người dùng sẽ bị xóa nếu thiết bị được mở khóa lại).