Root trong terminal, bị từ chối dưới SELinux: vì sao hook thất bại

Bạn chạy script up với quyền root, nó hoàn tất, và chính script đó thất bại khi dịch vụ gọi nó. Không có gì trong quyền của tệp thay đổi, nên bước tiếp theo tự nhiên là nới lỏng chúng lần nữa, điều này không sửa được gì. Trên một máy chủ SELinux, yếu tố quyết định thường không phải tiến trình là ai mà là nó chạy trong miền nào, và root bên trong một miền bị giới hạn vẫn bị giới hạn.

Cùng một lệnh, hai miền bảo mật khác nhau

Việc thực thi kiểu đánh giá cùng lúc miền nguồn, nhãn đích và thao tác được yêu cầu. Phiên terminal của bạn chạy trong một miền không giới hạn hoặc miền quản trị, và daemon chạy trong miền được gán cho unit của nó. Vì vậy các lệnh giống hệt nhau tạo ra quyết định khác nhau, và sự khác biệt là có chủ đích chứ không phải lỗi trong chính sách.

Đó là lý do việc so sánh hai lần chạy chỉ hữu ích nếu bạn so sánh ngữ cảnh của chúng. Chạy cùng lệnh từ shell và từ hook, và bản từ shell chứng minh rằng tệp nhị phân tồn tại và các đối số đúng; nó không chứng minh gì về việc dịch vụ có được phép chạy nó hay không. Chạy theo cả hai cách và so sánh các miền, không chỉ mã thoát. Chính sự so sánh đó biến một phàn nàn mơ hồ về quyền thành một câu hỏi cụ thể về một miền và một nhãn.

Hình thức cổ điển của lỗi này là một trình trợ giúp gọi công cụ bên ngoài. Bản thân hook có thể được phép, trong khi công cụ nó gọi mang nhãn mà miền dịch vụ không được phép thực thi, hoặc ghi vào thư mục mà nhãn của thư mục đó cấm.

Đọc bản ghi AVC bên cạnh lỗi của hook

Một từ chối AVC nêu tên các trường quyết định vụ việc: ngữ cảnh nguồn của tiến trình, ngữ cảnh đích của đối tượng, lớp của đối tượng và quyền cụ thể bị từ chối. Hãy đọc cả bốn trước khi lập giả thuyết, vì từ chối thực thi và từ chối ghi có cách sửa hoàn toàn khác nhau.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Ngữ cảnh nguồn phải khớp với miền mà dịch vụ thực sự chạy, và ngữ cảnh đích phải khớp với nhãn của tệp hoặc thư mục mà thao tác đã chạm tới. Nếu một trong hai không khớp với lỗi bạn đang theo đuổi, bạn đang đọc một sự kiện khác.

Ghi lại phiên bản chính sách và đường dẫn chính xác của tệp thực thi bên cạnh bản ghi. Một tên miền xuất hiện trong chính sách của một bản phân phối là bằng chứng về bản cài đặt đó, không phải bảo đảm rằng bản dựng khác cung cấp cùng các quy tắc. Chính ngữ cảnh đó cho phép người khác tái tạo kết luận của bạn trên máy chủ của họ. Không có nó, bản ghi được đọc như một giai thoại chứ không phải bằng chứng.

Nhãn, cấu hình hay chính sách: ba cách sửa

Cách sửa đầu tiên là một nhãn không khớp với vị trí đã cài đặt của tệp. Một script được sao chép vào chỗ bằng cp hoặc được viết bằng trình soạn thảo có thể mang nhãn mặc định mà miền dịch vụ không thể dùng, và việc khôi phục ngữ cảnh mong đợi sửa được điều đó mà không cần chạm vào chính sách.

Cách thứ hai là cấu hình. Bản phân phối có thể cung cấp một cách được hỗ trợ để chạy thao tác, một thư mục được ghi chép cho trình trợ giúp, hoặc một gói chính sách đã cập nhật vốn đã cho phép. Chuyển bố cục của bạn sang bố cục được hỗ trợ rẻ hơn việc viết chính sách và tồn tại qua các bản cập nhật.

Cách thứ ba là một quy tắc thực sự thiếu, và nó nên là biện pháp cuối cùng. Tạo một ứng viên bằng các công cụ kiểm toán, đọc xem nó thực sự cho phép gì, thu hẹp nó vào thao tác và miền bạn đã quan sát, và nhờ người khác xem xét trước khi nó đến gần môi trường sản xuất.

Vì sao một mô-đun allow cũ không phải là câu trả lời

Kết quả tìm kiếm cho lỗi này đầy những mô-đun dựng sẵn, thường dành cho một công cụ mà hook không còn gọi. Cài đặt một cái sẽ cấp những quyền có thể không liên quan gì đến việc từ chối của bạn, và nó để nguyên sự không khớp thật trong khi thêm một lỗ hổng vĩnh viễn.

Nó cũng che giấu thất bại tiếp theo. Một mô-đun cho phép một lớp thao tác rộng sẽ làm lỗi này biến mất và biến lỗi tiếp theo thành thứ khó quy nguồn hơn nhiều. Việc gỡ mô-đun sau đó cũng là một thay đổi không ai muốn lên lịch, nên lối tắt có xu hướng trở thành vĩnh viễn.

Sự so sánh có kỷ luật là giữa việc từ chối mà bạn có thể đọc và thay đổi mà bạn đề xuất. Hướng dẫn khắc phục sự cố SELinux của Red Hat đặt các kiểm tra nhãn và cấu hình trước chính sách được tạo ra đúng vì lý do này. Nếu không có từ chối tương ứng trong bản ghi, SELinux có lẽ không phải vấn đề của bạn, và các vấn đề về đường dẫn, sandbox hay quyền vẫn còn mở.