Vì sao di chuyển chứng chỉ VPN làm hỏng nhãn SELinux của nó

Chứng chỉ có thể nằm trong thư mục đúng với chế độ đọc được và quyền sở hữu root, và dịch vụ vẫn có thể báo rằng nó không mở được tệp. Trên hệ thống SELinux, sự kết hợp đó chỉ vào một cơ chế cụ thể chứ không phải quyền. Nhãn đã đi theo tệp, vì việc đổi tên không tạo ra đối tượng mới. inode giữ nguyên ngữ cảnh bảo mật mà nó có trên đường dẫn cũ, và chính sách cho đường dẫn mới không bao giờ có cơ hội gán ngữ cảnh của riêng nó.

Đổi tên thực sự làm gì với một nhãn

Một tệp mang ngữ cảnh SELinux của nó như dữ liệu thuộc tính gắn với inode. Đổi tên trong cùng một hệ thống tệp chỉ thay đổi mục nhập thư mục và không gì khác, điều này nhanh và nguyên tử, và đó là lý do ngữ cảnh sống sót qua lần di chuyển. Không có chính sách nào bị hỏi, không có giá trị mặc định nào được áp dụng, và không có cảnh báo nào được in ra.

Sao chép hành xử khác. Một bản sao tạo inode mới trong thư mục đích, và chính sách gán ngữ cảnh theo kiểu của thư mục đó, nên chứng chỉ được sao chép thường có nhãn đúng trong khi bản được di chuyển vẫn sai. Chính sự khác biệt duy nhất đó giải thích phần lớn sự nhầm lẫn trong loại phiếu này.

Di chuyển giữa các hệ thống tệp quay về ngữ nghĩa sao chép, nên cùng một lệnh có thể hành xử khác nhau trên hai máy tùy thuộc /etc có nằm trên ổ riêng hay không. Hãy kiểm tra điều đó trước khi kết luận rằng công cụ không đáng tin. Một cái nhìn vào bảng mount cho bạn biết bạn đã thực hiện kiểu di chuyển nào.

Đọc nhãn hiện tại so với nhãn kỳ vọng

Ba lệnh chỉ đọc trả lời câu hỏi mà không thay đổi gì. Lệnh đầu cho thấy tệp hiện có gì, lệnh thứ hai báo cáo chính sách kỳ vọng gì cho đúng đường dẫn đó, và lệnh thứ ba liệt kê mọi tệp dưới thư mục có nhãn khác.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

Thứ đáng tin là lần chạy thử, vì nó nêu tên mọi tệp có ngữ cảnh lệch khỏi chính sách mà vẫn để hệ thống không bị chạm tới. Nếu chứng chỉ xuất hiện trong danh sách đó, bạn đã tìm ra sự khác biệt giữa ý nghĩa của đường dẫn và điều tệp tuyên bố. Nếu nó không xuất hiện, nhãn đã là thứ chính sách muốn và thời gian của bạn thuộc về nơi khác.

Sau đó hãy liên hệ sự khác biệt với một lần từ chối thực tế. Sự không khớp là bằng chứng của nhãn sai, không phải bằng chứng rằng dịch vụ thất bại vì nó, và một bản sửa được áp dụng mà không có lần từ chối tương ứng trong nhật ký là một phỏng đoán với thêm bước.

Khôi phục ánh xạ thay vì tạo ra một ngoại lệ

Với một vị trí tiêu chuẩn, chính sách đã ánh xạ đường dẫn, nên restorecon áp dụng nó và công việc xong. Giữ phạm vi trong thư mục bạn đang sửa; dán nhãn lại toàn bộ hệ thống tệp là chậm, gây xáo trộn, và nó chôn sai lầm ban đầu dưới một thay đổi rất lớn.

Với một thư mục tùy chỉnh, thứ tự quan trọng, và đảo ngược nó tạo ra một lệnh báo thành công mà không thay đổi gì. Ánh xạ thuộc về chính sách, việc dán nhãn lại thuộc về cuối, và lần chạy thử thuộc về trước cả hai. Bỏ qua phần cuối đó chính là cách một đường dẫn chưa bao giờ sai vẫn bị dán nhãn lại.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon áp dụng một ánh xạ; nó không thể tạo ra một ánh xạ. Nếu không quy tắc nào mô tả đường dẫn, thì không có gì để khôi phục, đó là lý do ánh xạ lâu dài phải tồn tại trước khi dán nhãn lại. Ghi lại cấu hình nào sở hữu ánh xạ đó, vì nếu không thì một lần di chuyển sau, một bản cập nhật gói hoặc một lần dán nhãn lại sẽ tạo lại lỗi và người tiếp theo bắt đầu từ số không.

Vì sao chcon không phải là giải pháp

chcon ghi ngữ cảnh trực tiếp lên tệp. Nó có hiệu lực ngay và là lựa chọn kém bền nhất hiện có, vì việc dán nhãn lại hệ thống tệp áp dụng lại chính sách và vứt bỏ các thay đổi thủ công mà không hỏi. Tệp trông như đã được sửa và bản sửa có một ngày hết hạn mà không ai ghi lại. Thứ bạn muốn thay vào đó là một quy tắc mô tả đường dẫn, để mọi tệp đến đó tự động nhận cùng cách xử lý.

Tệ hơn, nó dạy bài học sai: ánh xạ nền vẫn thiếu, nên lỗi quay lại sau nhiều tuần mà không có tác nhân rõ ràng và không có ký ức về cách lách đó. Chỉ dùng chcon như một thí nghiệm tạm thời để xác nhận giả thuyết, rồi thay nó bằng một ánh xạ sống sót qua lần dán nhãn lại tiếp theo, và kiểm tra rằng bản thay thế thực sự nằm đúng chỗ.

Khi nhãn đúng mà truy cập vẫn thất bại

Bắt đầu với các thư mục cha. Quyền đi qua được kiểm tra trên từng thành phần của đường dẫn, nên một chứng chỉ được dán nhãn đúng bên trong thư mục mà dịch vụ không vào được vẫn không đọc được. Cả SELinux và quyền thông thường đều phải cho phép từng bước, và sửa cái này không sửa cái kia.

Sau đó kiểm tra danh tính tiến trình và hộp cát của chính dịch vụ. Một unit có hộp cát hạn chế có thể từ chối truy cập vào tệp mà chính sách sẵn lòng cho phép, và từ dòng nhật ký hai nguyên nhân trông giống hệt nhau. Hãy xác nhận tiến trình nào thực sự đang hỏi, không phải tiến trình bạn cho là đang hỏi.

Hãy nhớ rằng các quy tắc dontaudit có thể chặn thông điệp từ chối, nên nhật ký kiểm toán trống là bằng chứng yếu chứ không phải bằng chứng. Nếu chính sách trông đúng mà truy cập vẫn thất bại, hãy điều tra trước khi tạo một mô-đun cho phép rộng, và đừng tắt SELinux để triệu chứng biến mất. Cả hai lối tắt đều tạo ra một hệ thống trông như đang chạy và một tư thế bảo mật mà không ai mô tả được. Một cuộc điều tra ngắn tốt hơn cả hai.