Nội dung
- User SELinux - SELinux trong Hành động 1: Hạn chế Quyền truy cập của User Đã Chuyển đổi - SELinux trong Hành động 2: Hạn chế quyền chạy tập lệnh - SELinux trong Hành động 3: Hạn chế Quyền truy cập vào Dịch vụ - Nhật ký kiểm tra SELinux - Bảo mật đa cấp

Thứ sáu, 05/09/2014 | 00:00 GMT+7

Giới thiệu về SELinux trên CentOS 7 - Phần 3: Người dùng

Trong phần cuối cùng của hướng dẫn SELinux của ta , ta sẽ nói về user SELinux và cách tinh chỉnh quyền truy cập của họ. Ta cũng sẽ tìm hiểu về log lỗi SELinux và cách hiểu thông báo lỗi.

Ghi chú
Các lệnh, gói và file được hiển thị trong hướng dẫn này đã được thử nghiệm trên CentOS 7. Các khái niệm vẫn giữ nguyên cho các bản phân phối khác.

Trong hướng dẫn này, ta sẽ chạy các lệnh với quyền là user root trừ khi có quy định khác. Nếu bạn không có quyền truy cập vào account root và sử dụng account khác có quyền sudo, bạn cần đặt trước các lệnh bằng từ khóa sudo .

User SELinux

User SELinux là các thực thể khác với account user Linux bình thường, bao gồm cả account root . User SELinux không phải là thứ mà bạn tạo bằng lệnh đặc biệt, cũng không có quyền truy cập đăng nhập riêng vào server . Thay vào đó, user SELinux được xác định trong policy được tải vào bộ nhớ lúc khởi động và chỉ có một số user này. Tên user kết thúc bằng _u , giống như các loại hoặc domain kết thúc bằng _t và role kết thúc bằng _r . Những user SELinux khác nhau có các quyền khác nhau trong hệ thống và đó là điều khiến chúng trở nên hữu ích.

User SELinux được liệt kê trong phần đầu tiên của ngữ cảnh bảo mật của file là user sở hữu file đó. Điều này giống như bạn sẽ thấy chủ sở hữu của file từ kết quả lệnh ls -l thông thường. Nhãn user trong ngữ cảnh quy trình hiển thị quyền của user SELinux mà quy trình đang chạy.

Khi SELinux được thực thi, mỗi account user Linux thông thường được ánh xạ tới một account user SELinux. Có thể có nhiều account user được ánh xạ tới cùng một user SELinux. Ánh xạ này cho phép một account thông thường kế thừa quyền của đối tác SELinux của nó.

Để xem ánh xạ này, ta có thể chạy lệnh semanage login -l :

semanage login -l

Trong CentOS 7, Đây là kết quả ta có thể thấy:

Login Name           SELinux User         MLS/MCS Range        Service  __default__          unconfined_u         s0-s0:c0.c1023       * root                 unconfined_u         s0-s0:c0.c1023       * system_u             system_u             s0-s0:c0.c1023       *

Cột đầu tiên trong bảng này, "Tên đăng nhập", đại diện cho các account user Linux local . Nhưng chỉ có ba được liệt kê ở đây, bạn có thể hỏi, không phải ta đã tạo một vài account trong phần thứ hai của hướng dẫn này? Có, và chúng được thể hiện bằng mục nhập được hiển thị dưới dạng mặc định . Bất kỳ account user Linux thông thường nào trước tiên đều được ánh xạ tới thông tin đăng nhập mặc định . Sau đó, điều này được ánh xạ tới user SELinux có tên là unconfined_u. Trong trường hợp của ta , đây là cột thứ hai của hàng đầu tiên. Cột thứ ba hiển thị lớp bảo mật đa cấp / Bảo mật đa danh mục (MLS / MCS) cho user . Hiện tại, ta hãy bỏ qua phần đó và cả cột sau đó (Dịch vụ).

Tiếp theo, ta có user root . Lưu ý nó không được ánh xạ đến thông tin đăng nhập " mặc định ", thay vào đó nó đã được cấp mục nhập riêng. , root cũng được ánh xạ tới user SELinux unsonfined_u.

system_u là một lớp user khác, dành cho việc chạy các tiến trình hoặc daemon.

Để xem những user SELinux nào có sẵn trong hệ thống, ta có thể chạy lệnh semanage user :

semanage user -l

Đầu ra trong hệ thống CentOS 7 của ta sẽ giống như sau:

                 Labeling   MLS/       MLS/ SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles  guest_u         user       s0         s0                             guest_r root            user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r system_u        user       s0         s0-s0:c0.c1023                 system_r unconfined_r unconfined_u    user       s0         s0-s0:c0.c1023                 system_r unconfined_r user_u          user       s0         s0                             user_r xguest_u        user       s0         s0                             xguest_r

Cái bàn lớn hơn này nghĩa là gì? Trước hết, nó hiển thị những user SELinux khác nhau được xác định bởi policy . Trước đây, ta đã thấy những user như Unconfined_u và system_u, nhưng giờ ta thấy những kiểu user khác như guest_u, staff_u, sysadm_u, user_u, v.v. Những cái tên phần nào thể hiện các quyền liên quan đến chúng. Ví dụ: ta có thể giả định user sysadm_u sẽ có nhiều quyền truy cập hơn guest_u.

Để xác minh vị khách của ta , hãy xem cột thứ năm, Role của SELinux. Nếu bạn nhớ từ phần đầu tiên của hướng dẫn này, các role của SELinux giống như các cổng giữa user và một quy trình. Ta cũng so sánh chúng với các bộ lọc: user có thể nhập một role , miễn là role đó cho phép nó. Nếu một role được ủy quyền truy cập vào một domain quy trình, thì user được liên kết với role đó sẽ có thể vào domain quy trình đó.

Bây giờ từ bảng này, ta có thể thấy user unconfined_u được ánh xạ tới các role system_r và unconfined_r . Mặc dù không rõ ràng ở đây, nhưng policy SELinux thực sự cho phép các role này chạy các quy trình trong domain unconfined_t . Tương tự, user sysadm_u được ủy quyền cho role r sysadm , nhưng khách u được ánh xạ đến role guest_r. Mỗi role này sẽ có các domain khác nhau được ủy quyền cho chúng.

Bây giờ, nếu ta lùi lại một bước, ta cũng thấy từ đoạn mã đầu tiên, thông tin đăng nhập mặc định ánh xạ tới user u không xác định , giống như user root ánh xạ tới user unonfined_u. Vì thông tin đăng nhập ** mặc định _ ** đại diện cho bất kỳ account user Linux thông thường nào, các account đó cũng sẽ được cấp quyền cho các role system_r và unsonfined_r.

Vì vậy, điều này thực sự nghĩa là bất kỳ user Linux nào ánh xạ tới user Unconfined_u sẽ có quyền chạy bất kỳ ứng dụng nào chạy trong domain unconfined_t.

Để chứng minh điều này, hãy chạy lệnh id -Z với quyền là user root:

id -Z

Điều này cho thấy bối cảnh bảo mật SELinux cho root :

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Vì vậy, account root được ánh xạ tới user SELinux unsonfined_u, và unsonfined_u được cấp quyền cho role Unconfined_r, role này được phép chạy các quy trình trong domain Unconfined_t.

Ta khuyên bạn nên dành thời gian ngay bây giờ để bắt đầu bốn phiên SSH mới với bốn user bạn đã tạo từ các cửa sổ terminal riêng biệt. Điều này sẽ giúp ta chuyển đổi giữa các account khác nhau khi cần thiết.

Người sử dụng thường xuyên
user chuyển mạch
Tài khoản khách
user bị hạn chế

Tiếp theo, ta chuyển sang phiên terminal được đăng nhập với quyền regular user . Nếu bạn còn nhớ, ta đã tạo một số account user trong hướng dẫn thứ hai và user thường xuyên là một trong số đó. Nếu bạn chưa làm như vậy, hãy mở một cửa sổ terminal riêng biệt để kết nối với hệ thống CentOS 7 của bạn với quyền là regular user . Nếu ta thực hiện cùng một lệnh id -Z từ đó, kết quả sẽ giống như sau:

[regularuser@localhost ~]$ id -Z

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Trong trường hợp này, account user điều chỉnh được ánh xạ tới account user SELinux unsonfined_u và nó có thể đảm nhận role user không xác định. Role có thể chạy các quy trình trong một domain không xác định. Đây là user / role / domain SELinux mà account root cũng ánh xạ tới. Đó là bởi vì policy nhắm đến của SELinux cho phép user đã đăng nhập chạy trong các domain không xác định.

Ta đã xem danh sách một số user SELinux trước đây:

guest_u : User này không có quyền truy cập vào hệ thống X-Window (GUI) hoặc mạng và không thể thực hiện lệnh su / sudo.
xguest_u : User này có quyền truy cập vào các công cụ GUI và mạng khả dụng qua trình duyệt Firefox.
user_u : User này có nhiều quyền truy cập hơn account khách (GUI và mạng), nhưng không thể chuyển đổi user bằng cách chạy su hoặc sudo.
staff_u : Quyền tương tự như user_u, ngoại trừ nó có thể thực thi lệnh sudo để có quyền root.
system_u : User này dùng để chạy các dịch vụ hệ thống và không được ánh xạ tới account regular user .

SELinux trong Hành động 1: Hạn chế Quyền truy cập của User Đã Chuyển đổi

Để xem cách SELinux có thể thực thi bảo mật cho account user , hãy nghĩ về account regular user . Với quyền là administrator hệ thống, bây giờ bạn biết user có các quyền SELinux không hạn chế giống như account root và bạn muốn thay đổi điều đó. Cụ thể, bạn không muốn user có thể chuyển sang các account khác, bao gồm cả account root .

Trước tiên, hãy kiểm tra khả năng chuyển sang account khác của user . Trong đoạn mã sau, regular user chuyển sang account user đã chuyển. Ta cho rằng anh ta biết password của user chuyển mạch:

[regularuser@localhost ~]$ su - switcheduser Password: [switcheduser@localhost ~]$

Tiếp theo, ta quay lại cửa sổ terminal đã đăng nhập với quyền user root và thay đổi ánh xạ user SELinux của regular user . Ta sẽ ánh xạ user thường xuyên tới user_u.

semanage login -a -s user_u regularuser

Vậy ta đang làm gì ở đây? Ta đang thêm (-a) account regular user vào account user SELinux (-s) user_u. Thay đổi sẽ không có hiệu lực cho đến khi regular user đăng xuất và đăng nhập lại.

Quay trở lại cửa sổ terminal của regular user , trước tiên ta chuyển trở lại từ user đã chuyển đổi:

[switcheduser@localhost ~]$ logout

Tiếp theo, regular user cũng đăng xuất:

[regularuser@localhost ~]$ logout

Sau đó, ta mở một cửa sổ terminal mới để kết nối như regular user . Tiếp theo, ta cố gắng thay đổi lại user đã chuyển đổi:

[regularuser@localhost ~]$ su - switcheduser

Password:

Đây là những gì ta thấy bây giờ:

su: Authentication failure

Nếu bây giờ ta chạy lại lệnh id -Z để xem ngữ cảnh SELinux cho user thường xuyên, ta sẽ thấy kết quả kết quả khá khác so với những gì ta đã thấy trước đây: user thường xuyên hiện được ánh xạ tới user_u.

[regularuser@localhost ~]$ id -Z

user_u:user_r:user_t:s0

Vậy bạn sẽ sử dụng những hạn chế như vậy ở đâu? Bạn có thể nghĩ đến một group phát triển ứng dụng trong tổ chức CNTT của bạn. Bạn có thể có một số nhà phát triển và người thử nghiệm trong group đó viết mã và thử nghiệm ứng dụng mới nhất cho công ty của bạn. Là administrator hệ thống, bạn biết các nhà phát triển đang chuyển từ account của họ sang một số account có quyền cao để áp dụng các thay đổi đột xuất đối với server của bạn. Bạn có thể ngăn điều này xảy ra bằng cách hạn chế khả năng chuyển đổi account của họ. (Xin lưu ý với bạn, điều đó vẫn không ngăn họ đăng nhập trực tiếp với quyền là user có quyền cao).

SELinux trong Hành động 2: Hạn chế quyền chạy tập lệnh

Hãy xem một ví dụ khác về việc hạn chế quyền truy cập của user thông qua SELinux. Chạy các lệnh này từ phiên gốc .

Theo mặc định, SELinux cho phép user được ánh xạ tới account guest_t để thực thi các tập lệnh từ folder chính của họ. Ta có thể chạy lệnh getsebool để kiểm tra giá trị boolean:

getsebool allow_guest_exec_content

Đầu ra cho thấy cờ đang bật.

guest_exec_content --> on

Để xác minh tác dụng của nó, trước tiên ta hãy thay đổi ánh xạ user SELinux cho account user khách mà ta đã tạo ở đầu hướng dẫn này. Ta sẽ làm điều đó với quyền là user root.

semanage login -a -s guest_u guestuser

Ta có thể xác minh hành động bằng cách chạy lại lệnh semanage login -l :

semanage login -l

Như ta có thể thấy, user khách hiện đã được ánh xạ tới account user SELinux guest_u.

Login Name           SELinux User         MLS/MCS Range        Service  __default__          unconfined_u         s0-s0:c0.c1023       * guestuser            guest_u              s0                   * regularuser          user_u               s0                   * root                 unconfined_u         s0-s0:c0.c1023       * system_u             system_u             s0-s0:c0.c1023       *

Nếu ta có một cửa sổ terminal đang mở với quyền là user khách, ta sẽ đăng xuất khỏi cửa sổ đó và đăng nhập lại trong một cửa sổ terminal mới với quyền là user .

Tiếp theo, ta sẽ tạo một bash script cực kỳ đơn giản trong folder chính của user . Các khối mã sau trước tiên kiểm tra folder chính, sau đó tạo file và đọc nó trên console . Cuối cùng, quyền thực thi được thay đổi.

Xác minh bạn đang ở trong guestuser folder chính:

[guestuser@localhost ~]$ pwd

/home/guestuser

Tạo tập lệnh:

[guestuser@localhost ~]$ vi myscript.sh

Nội dung kịch bản:

#!/bin/bash echo "This is a test script"

Làm cho tập lệnh có thể thực thi:

chmod u+x myscript.sh

Khi ta cố gắng thực thi tập lệnh với quyền là user khách, nó hoạt động như mong đợi:

[guestuser@localhost ~]$ ~/myscript.sh

This is a test script

Tiếp theo, ta quay lại cửa sổ root terminal và thay đổi cài đặt boolean allow_guest_exec_content thành off và xác minh nó:

setsebool allow_guest_exec_content off getsebool allow_guest_exec_content

guest\_exec\_content --> off

Quay lại console đã đăng nhập với quyền là user khách, ta cố gắng chạy lại tập lệnh. Lần này, quyền truy cập bị từ chối:

[guestuser@localhost ~]$ ~/myscript.sh

-bash: /home/guestuser/myscript.sh: Permission denied

Vì vậy, đây là cách SELinux có thể áp dụng một lớp bảo mật bổ sung trên đầu DAC. Ngay cả khi user có toàn quyền truy cập đọc, ghi, thực thi vào tập lệnh được tạo trong folder chính của riêng họ, họ vẫn có thể bị dừng thực thi nó. Bạn cần nó ở đâu? Hãy nghĩ về một hệ thống production . Bạn biết rằng các nhà phát triển có quyền truy cập vào nó cũng như một số nhà thầu làm việc cho công ty của bạn. Bạn muốn họ truy cập vào server để xem thông báo lỗi và file log , nhưng bạn không muốn họ thực thi bất kỳ tập lệnh shell nào. Để thực hiện việc này, trước tiên bạn có thể kích hoạt SELinux và sau đó đảm bảo giá trị boolean tương ứng được đặt.

Ta sẽ nói về thông báo lỗi SELinux ngay sau đó, nhưng hiện tại, nếu ta muốn biết vị trí từ chối này được ghi lại, ta có thể xem file /var/log/messages . Thực thi điều này từ phiên root :

grep "SELinux is preventing" /var/log/messages

Hai thông báo cuối cùng trong file trong server CentOS 7 của ta hiển thị từ chối truy cập:

Aug 23 12:59:42 localhost setroubleshoot: SELinux is preventing /usr/bin/bash from execute access on the file . For complete SELinux messages. run sealert -l 8343a9d2-ca9d-49db-9281-3bb03a76b71a Aug 23 12:59:42 localhost python: SELinux is preventing /usr/bin/bash from execute access on the file .

Thông báo cũng hiển thị một giá trị ID dài và đề xuất ta chạy lệnh sealert với ID này để biết thêm thông tin. Lệnh sau hiển thị điều này (sử dụng ID cảnh báo của bạn ):

sealert -l 8343a9d2-ca9d-49db-9281-3bb03a76b71a

Và thực sự, kết quả cho ta thấy chi tiết hơn về lỗi:

SELinux is preventing /usr/bin/bash from execute access on the file .  *****  Plugin catchall_boolean (89.3 confidence) suggests   ******************  If you want to allow guest to exec content Then you must tell SELinux about this by enabling the 'guest\_exec\_content' boolean. You can read 'None' man page for more details. Do setsebool -P guest\_exec\_content 1  *****  Plugin catchall (11.6 confidence) suggests   **************************  ...

Đó là một lượng lớn sản lượng, nhưng hãy lưu ý vài dòng ở đầu:

SELinux đang ngăn / usr / bin / bash thực thi quyền truy cập vào file .

Điều đó cho ta một ý tưởng khá tốt về nguyên nhân của lỗi.

Một số dòng tiếp theo cũng cho bạn biết cách sửa lỗi:

If you want to allow guest to exec content Then you must tell SELinux about this by enabling the 'guest\_exec\_content' boolean. ... setsebool -P guest\_exec\_content 1

SELinux trong Hành động 3: Hạn chế Quyền truy cập vào Dịch vụ

Trong phần đầu tiên của loạt bài này, ta đã nói về các role của SELinux khi ta giới thiệu thuật ngữ cơ bản về user , role , domain và loại. Bây giờ ta hãy xem role cũng đóng một phần như thế nào trong việc hạn chế quyền truy cập của user . Như ta đã nói trước đây, một role trong SELinux nằm giữa user và domain quy trình và kiểm soát domain nào mà quy trình của user có thể truy cập. Role không quan trọng lắm khi ta thấy chúng trong bối cảnh bảo mật file . Đối với file , nó được liệt kê với giá trị chung là object_r. Role trở nên quan trọng khi giao dịch với user và quy trình.

Trước tiên, hãy đảm bảo daemon httpd không chạy trong hệ thống. Với quyền là user root, bạn có thể chạy lệnh sau đảm bảo quá trình đã dừng:

service httpd stop

Tiếp theo, ta chuyển sang cửa sổ terminal mà ta đã đăng nhập với quyền là user bị hạn chế và cố gắng xem ngữ cảnh bảo mật SELinux cho nó. Nếu bạn không mở cửa sổ terminal , hãy bắt đầu một phiên terminal mới trên hệ thống và đăng nhập bằng account user bị hạn chế mà ta đã tạo ở đầu hướng dẫn này.

[restricteduser@localhost ~]$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Vì vậy, account có hành vi mặc định là chạy với quyền user Unconfined_u và có quyền truy cập vào role Unconfined_r. Tuy nhiên, account này không có quyền khởi động bất kỳ quy trình nào trong hệ thống. Khối mã sau cho thấy rằng user bị hạn chế đang cố khởi động trình httpd và nhận được lỗi bị từ chối truy cập:

[restricteduser@localhost ~]$ service httpd start Redirecting to /bin/systemctl start  httpd.service Failed to issue method call: Access denied

Tiếp theo, ta quay trở lại cửa sổ terminal của user root và đảm bảo account user bị hạn chế đã được thêm vào file / etc / sudoers. Hành động này sẽ cho phép account user bị hạn chế sử dụng quyền root.

visudo

Và sau đó trong file , thêm dòng sau, lưu và thoát:

restricteduser ALL=(ALL)      ALL

Nếu bây giờ ta đăng xuất khỏi cửa sổ terminal của user bị hạn chế và đăng nhập lại, ta có thể bắt đầu và dừng dịch vụ httpd với các quyền sudo:

[restricteduser@localhost ~]$ sudo service httpd start

 We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things:      #1) Respect the privacy of others.     #2) Think before you type.     #3) With great power comes great responsibility.  [sudo] password for restricteduser: Redirecting to /bin/systemctl start  httpd.service

User cũng có thể dừng dịch vụ ngay bây giờ:

[restricteduser@localhost ~]$ sudo service httpd stop

Redirecting to /bin/systemctl stop  httpd.service

Đó là tất cả rất bình thường: administrator hệ thống cấp cho sudo quyền truy cập vào account user mà họ tin tưởng. Nhưng nếu bạn muốn ngăn user cụ thể này khởi động dịch vụ httpd ngay cả khi account của user được liệt kê trong file sudoers thì sao?

Để xem cách này có thể đạt được như thế nào, hãy quay lại cửa sổ terminal của user root và ánh xạ user bị hạn chế vào account SELinux user_r. Đây là những gì ta đã làm cho account regular user trong một ví dụ khác.

semanage login -a -s user_u restricteduser

Quay trở lại cửa sổ terminal của user bị hạn chế, ta đăng xuất và đăng nhập lại trong phiên terminal mới với quyền user bị hạn chế.

Bây giờ user bị hạn chế đó đã bị hạn chế đối với user_u (và điều đó nghĩa là đóng role user_r và domain user_t), ta có thể xác minh quyền truy cập của nó bằng cách sử dụng lệnh seinfo từ cửa sổ user root của ta :

seinfo -uuser_u -x

Kết quả hiển thị các role mà user_u có thể đảm nhận. Đây là object_r và user_r:

   user_u       default level: s0       range: s0       roles:          object_r          user_r

Tiến thêm một bước nữa, ta có thể chạy lệnh seinfo để kiểm tra những domain nào mà role user_r được phép nhập:

seinfo -ruser_r -x

Có một số domain mà user_r được phép nhập:

   user_r       Dominated Roles:          user_r       Types:          git_session_t          sandbox_x_client_t          git_user_content_t          virt_content_t          policykit_grant_t          httpd_user_htaccess_t          telepathy_mission_control_home_t          qmail_inject_t          gnome_home_t          ...          ...

Nhưng danh sách này có hiển thị httpd_t là một trong các domain không? Hãy thử cùng một lệnh với bộ lọc:

seinfo -ruser_r -x | grep httpd

Có một số domain liên quan đến httpd mà role có quyền truy cập, nhưng httpd_t không phải là một trong số chúng:

         httpd_user_htaccess_t          httpd_user_script_exec_t          httpd_user_ra_content_t          httpd_user_rw_content_t          httpd_user_script_t          httpd_user_content_t

Lấy ví dụ này sau đó, nếu account user bị hạn chế cố gắng khởi động daemon httpd, quyền truy cập sẽ bị từ chối vì quá trình httpd chạy trong domain httpd_t và đó không phải là một trong những domain mà role user_r được phép truy cập. Và ta biết user_u (được ánh xạ tới user bị hạn chế) có thể đảm nhận role user_r. Điều này sẽ không thành công ngay cả khi account user bị hạn chế đã được cấp quyền sudo.

Quay lại cửa sổ terminal của account user bị hạn chế, ta cố gắng khởi động trình httpd ngay bây giờ ( ta đã có thể dừng nó trước đây vì account đã được cấp quyền sudo):

[restricteduser@localhost ~]$ sudo service httpd start

Quyền truy cập bị từ chối:

sudo: PERM_SUDOERS: setresuid(-1, 1, -1): Operation not permitted

Vì vậy, có một ví dụ khác về cách SELinux có thể hoạt động như một người gác cổng.

Nhật ký kiểm tra SELinux

Với quyền là administrator hệ thống, bạn muốn xem các thông báo lỗi do SELinux ghi lại. Các thông báo này được ghi vào các file cụ thể và chúng có thể cung cấp thông tin chi tiết về việc từ chối truy cập. Trong hệ thống CentOS 7, bạn có thể xem hai file :

/var/log/audit/audit.log
/var/log/messages

Các file này được điền bởi daemon audd và daemon rsyslogd tương ứng. Vậy những con daemon này làm gì? Các trang người đàn ông nói rằng daemon Auditd là thành phần không gian user của hệ thống kiểm toán Linux và rsyslogd là tiện ích hệ thống cung cấp hỗ trợ ghi log thư. Nói một cách đơn giản, các daemon này ghi lại các thông báo lỗi trong hai file này.

Tệp /var/log/audit/audit.log sẽ được sử dụng nếu daemon Auditd đang chạy. Tệp /var/log/messages được sử dụng nếu Auditd bị dừng và rsyslogd đang chạy. Nếu cả hai daemon đang chạy, cả hai file đều được sử dụng: /var/log/audit/audit.log ghi lại thông tin chi tiết trong khi version dễ đọc được lưu trong /var/log/messages .

Giải mã thông báo lỗi SELinux

Ta đã xem xét một thông báo lỗi SELinux trong phần trước (tham khảo “SELinux trong Hành động 2: Hạn chế Quyền Chạy Tập lệnh”). Sau đó, ta sử dụng grep để sàng lọc qua file /var/log/messages . May mắn là SELinux đi kèm với một số công cụ giúp cuộc sống dễ dàng hơn thế một chút. Các công cụ này không được cài đặt theo mặc định và yêu cầu cài đặt một vài gói, mà bạn nên cài đặt trong phần đầu tiên của hướng dẫn này.

Lệnh đầu tiên là ausearch . Ta có thể sử dụng lệnh này nếu daemon Auditd đang chạy. Trong đoạn mã sau, ta đang cố gắng xem xét tất cả các thông báo lỗi liên quan đến daemon httpd. Đảm bảo rằng bạn đang ở trong account root của bạn :

ausearch -m avc -c httpd

Trong hệ thống của ta , một số mục nhập đã được liệt kê, nhưng ta sẽ tập trung vào mục cuối cùng:

---- time->Thu Aug 21 16:42:17 2014 ... type=AVC msg=audit(1408603337.115:914): avc:  denied  { getattr } for  pid=10204 comm="httpd" path="/www/html/index.html" dev="dm-0" ino=8445484 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

Ngay cả những administrator hệ thống có kinh nghiệm cũng có thể bị bối rối bởi những thông báo như thế này trừ khi họ biết họ đang tìm gì. Để hiểu nó, hãy tách từng trường:

type = AVC và avc: AVC là viết tắt của Access Vector Cache . SELinux lưu trữ các quyết định kiểm soát truy cập cho tài nguyên và quy trình. Bộ nhớ cache này được gọi là Access Vector Cache (AVC). Đó là lý do tại sao các thông báo từ chối quyền truy cập SELinux còn gọi là “AVC từ chối”. Hai trường thông tin này cho biết mục nhập đến từ log AVC và đó là một sự kiện AVC.
từ chối {getattr}: Quyền đã được thử và kết quả nó nhận được. Trong trường hợp này, hoạt động thuộc tính get đã bị từ chối.
pid = 10204. Đây là id quy trình của quy trình đã cố gắng truy cập.
comm: Bản thân id quy trình không có nhiều ý nghĩa. Thuộc tính comm hiển thị lệnh tiến trình. Trong trường hợp này, đó là httpd. Ngay lập tức ta biết lỗi đến từ web server .
path: Vị trí của tài nguyên đã được truy cập. Trong trường hợp này, đó là một file trong /www/html/index.html.
dev và ino: Thiết bị chứa tài nguyên đích và địa chỉ inode của nó.
scontext: Bối cảnh bảo mật của quy trình. Ta có thể thấy nguồn đang chạy trong domain httpd_t.
tcontext: Bối cảnh bảo mật của tài nguyên đích. Trong trường hợp này, loại file là default_t.
tclass: Lớp của tài nguyên đích. Trong trường hợp này, đó là một file .

Nếu bạn nhìn kỹ, domain quy trình là httpd_t và ngữ cảnh loại file là default_t. Vì daemon httpd chạy trong một domain hạn chế và policy SELinux quy định domain này không có bất kỳ quyền truy cập nào vào các file có kiểu default_t, quyền truy cập đã bị từ chối.

Ta đã thấy công cụ sealert . Lệnh này được dùng với giá trị id của thông báo lỗi được đăng nhập trong file /var/log/messages .

Trong đoạn mã sau đoạn mã ta grep thông qua các /var/log/message file lỗi liên quan SELinux:

cat /var/log/messages | grep "SELinux is preventing"

Trong hệ thống của ta , ta xem xét lỗi cuối cùng. Đây là lỗi đã được ghi lại khi user bị hạn chế của ta cố gắng chạy daemon httpd:

... Aug 25 11:59:46 localhost setroubleshoot: SELinux is preventing /usr/bin/su from using the setuid capability. For complete SELinux messages. run sealert -l e9e6c6d8-f217-414c-a14e-4bccb70cfbce

Như được đề xuất, ta đã chạy sealert với giá trị ID và có thể xem chi tiết (giá trị ID của bạn phải là duy nhất cho hệ thống của bạn):

sealert -l e9e6c6d8-f217-414c-a14e-4bccb70cfbce

SELinux is preventing /usr/bin/su from using the setuid capability.  ...  Raw Audit Messages type=AVC msg=audit(1408931985.387:850): avc:  denied  { setuid } for  pid=5855 comm="sudo" capability=7  scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=capability   type=SYSCALL msg=audit(1408931985.387:850): arch=x86_64 syscall=setresuid success=no exit=EPERM a0=ffffffff a1=1 a2=ffffffff a3=7fae591b92e0 items=0 ppid=5739 pid=5855 auid=1008 uid=0 gid=1008 euid=0 suid=0 fsuid=0 egid=0 sgid=1008 fsgid=0 tty=pts2 ses=22 comm=sudo exe=/usr/bin/sudo subj=user_u:user_r:user_t:s0 key=(null)  Hash: su,user_t,user_t,capability,setuid

Ta đã thấy vài dòng đầu tiên của kết quả của sealert cho ta biết về các bước khắc phục như thế nào. Tuy nhiên, nếu bây giờ ta xem gần cuối stream kết quả , ta có thể thấy phần "Thông báo kiểm tra thô". Mục nhập ở đây đến từ file audit.log mà ta đã thảo luận trước đó, vì vậy bạn có thể sử dụng phần đó để giúp bạn diễn giải kết quả ở đây.

Bảo mật đa cấp

Bảo mật đa cấp hay MLS là phần chi tiết của ngữ cảnh bảo mật SELinux.

Lúc này, trong cuộc thảo luận của ta về bối cảnh bảo mật cho quy trình, user hoặc tài nguyên, ta đã nói về ba thuộc tính: user SELinux, role SELinux và kiểu hoặc domain SELinux. Trường thứ tư của bối cảnh bảo mật cho thấy mức độ nhạy cảm và tùy chọn, loại tài nguyên.

Để hiểu nó, hãy xem xét ngữ cảnh bảo mật của file cấu hình FTP daemon:

ls -Z /etc/vsftpd/vsftpd.conf

Trường thứ tư của bối cảnh bảo mật cho thấy độ nhạy của s0.

-rw-------. root root system_u:object_r:etc_t:s0       /etc/vsftpd/vsftpd.conf

Độ nhạy là một phần của cơ chế bảo mật đa cấp phân cấp. Theo phân cấp, ta nghĩa là mức độ nhạy cảm có thể ngày càng sâu hơn đối với nội dung được bảo mật hơn trong hệ thống file . Mức 0 (được mô tả bằng s0) là mức độ nhạy thấp nhất, có thể so sánh với "công khai". Có thể có các mức độ nhạy cảm khác với giá trị s cao hơn: ví dụ, nội bộ, bí mật hoặc quy định có thể được mô tả bằng s1, s2 và s3 tương ứng. Ánh xạ này không được quy định bởi policy : administrator hệ thống có thể cấu hình ý nghĩa của từng mức độ nhạy.

Khi hệ thống hỗ trợ SELinux sử dụng MLS cho loại policy của nó (được cấu hình trong file /etc/selinux/config ), nó có thể đánh dấu các file và quy trình nhất định với mức độ nhạy nhất định. Mức thấp nhất được gọi là “độ nhạy dòng điện” và mức cao nhất được gọi là “độ nhạy thanh thải”.

Đi đôi với nhạy cảm là phạm trù của nguồn lực, được mô tả bằng c. Các danh mục có thể được coi là nhãn được gán cho một tài nguyên. Ví dụ về danh mục có thể là tên bộ phận, tên khách hàng, dự án, v.v. Mục đích của phân loại là để tinh chỉnh hơn nữa việc kiểm soát truy cập. Ví dụ: bạn có thể đánh dấu các file nhất định với độ nhạy bí mật cho user từ hai bộ phận nội bộ khác nhau.

Đối với các ngữ cảnh bảo mật của SELinux, độ nhạy và danh mục hoạt động cùng nhau khi một danh mục được triển khai. Khi sử dụng một loạt các mức độ nhạy, định dạng là hiển thị các mức độ nhạy được phân tách bằng dấu gạch ngang (ví dụ: s0-s2). Khi sử dụng một danh mục, một phạm vi được hiển thị với một dấu chấm ở giữa. Giá trị độ nhạy và danh mục được phân tách bằng dấu hai chấm (:).

Đây là một ví dụ về cặp danh mục / độ nhạy:

user_u:object_r:etc_t:s0:c0.c2

Chỉ có một mức độ nhạy ở đây và đó là s0. Mức danh mục cũng có thể được viết là c0-c2.

Vậy bạn chỉ định cấp độ danh mục của bạn ở đâu? Hãy cùng tìm chi tiết từ file /etc/selinux/targeted/setrans.conf :

cat /etc/selinux/targeted/setrans.conf

# # Multi-Category Security translation table for SELinux # # # Objects can be categorized with 0-1023 categories defined by the admin. # Objects can be in more than one category at a time. # Categories are stored in the system as c0-c1023.  Users can use this # table to translate the categories into a more meaningful output. # Examples: # s0:c0=CompanyConfidential # s0:c1=PatientRecord # s0:c2=Unclassified # s0:c3=TopSecret # s0:c1,c3=CompanyConfidentialRedHat s0=SystemLow s0-s0:c0.c1023=SystemLow-SystemHigh s0:c0.c1023=SystemHigh

Ta sẽ không đi vào chi tiết về độ nhạy và danh mục ở đây. Chỉ cần biết rằng một quy trình chỉ được phép đọc quyền truy cập vào tài nguyên khi độ nhạy và cấp độ danh mục của nó cao hơn cấp tài nguyên (tức là domain quy trình thống trị loại tài nguyên). Quá trình có thể ghi vào tài nguyên khi mức độ nhạy cảm / danh mục của nó nhỏ hơn mức của tài nguyên.

Kết luận

Ta đã cố gắng đề cập đến một chủ đề rộng lớn về bảo mật Linux trong repository ảng thời gian ngắn của loạt bài gồm ba phần này. Nếu ta nhìn vào hệ thống của bạn bây giờ, ta có một web server Apache đơn giản được cài đặt với nội dung của nó được cung cấp từ một folder tùy chỉnh. Ta cũng có một daemon FTP đang chạy trong server của ta . Đã có một vài user được tạo có quyền truy cập bị hạn chế. Trong quá trình thực hiện, ta đã sử dụng các gói, file và lệnh SELinux để phục vụ cho nhu cầu bảo mật của bạn . Trong quá trình này, ta cũng đã học cách xem các thông báo lỗi SELinux và hiểu chúng.

Toàn bộ sách đã được viết về chủ đề SELinux và bạn có thể dành hàng giờ để tìm ra các gói, file cấu hình, lệnh khác nhau và ảnh hưởng của chúng đối với bảo mật. Thế thì từ nơi này bạn sẽ đi đâu?

Một điều tôi sẽ làm là lưu ý bạn không thử nghiệm bất kỳ thứ gì trên hệ thống production . Khi bạn đã thành thạo các kiến thức cơ bản, hãy bắt đầu chơi với SELinux bằng cách kích hoạt nó trên bản sao thử nghiệm của hộp production của bạn. Đảm bảo rằng các trình kiểm tra đang chạy và theo dõi các thông báo lỗi. Kiểm tra bất kỳ từ chối nào ngăn dịch vụ bắt đầu. Chơi xung quanh với các cài đặt boolean. Lập danh sách các bước có thể thực hiện để bảo mật hệ thống của bạn, như tạo user mới được ánh xạ tới các account SELinux kém an toàn nhất hoặc áp dụng ngữ cảnh phù hợp cho các vị trí file không chuẩn. Hiểu cách giải mã log lỗi. Kiểm tra các cổng để tìm các daemon khác nhau: nếu các cổng không chuẩn được sử dụng, hãy đảm bảo chúng được chỉ định chính xác cho policy .

Tất cả sẽ đến cùng với thời gian và sự luyện tập. :)

Tags:

Các tin liên quan

Giới thiệu về SELinux trên CentOS 7 - Phần 1: Các khái niệm cơ bản
2014-09-05
Giới thiệu về SELinux trên CentOS 7 - Phần 2: Tệp và Quy trình
2014-09-05
Cách cài đặt puppet ở chế độ độc lập trên CentOS 7
2014-09-04
Cách cài đặt Node.js trên server CentOS 7
2014-08-18
Cách sử dụng Logstash và Kibana để tập trung log trên CentOS 7
2014-07-15
Cách sử dụng Logstash và Kibana để tập trung log trên CentOS 6
2014-07-08
Cách thiết lập DavMail trên CentOS 6
2014-02-13
Cách cài đặt Ruby 2.1.0 trên CentOS 6.5 bằng RVM
2014-01-22
Cách cài đặt ZeroMQ từ nguồn trên VPS CentOS 6 x64
2013-12-23
Cách cài đặt Diễn đàn Máy đơn giản trên CentOS 6
2013-12-05