Làm thế nào để làm cứng su với dpkg-statoverride?

Tôi đang đọc hướng dẫn làm cứng Ubuntu 14 và đây là một trong những gợi ý:

Nhìn chung có vẻ như là một ý tưởng hợp lý để đảm bảo rằng chỉ những người dùng trong nhóm sudo mới có thể chạy lệnh su để hoạt động như (hoặc trở thành) root:

dpkg-statoverride --update --add root sudo 4750
/ thùng / su

Tôi đã tra cứu dpkg-statoverridelệnh nhưng tôi vẫn không thể biết chính xác lệnh trên đang làm gì?

Nó dường như ngụ ý rằng Ubuntu 14 theo mặc định cho phép bất cứ ai sudo. Để kiểm tra, tôi đã tạo một người dùng mới, đăng nhập với tư cách là người dùng đó, đã thử sudo và nó đã thất bại - điều đó tốt.

Vậy mục đích của gợi ý trên là gì?

Mục đích là để ngăn người dùng thông thường chạy lệnh su (su tương tự như sudo, sự khác biệt là sudo thực thi một lệnh, su bắt đầu một phiên mới với tư cách là người dùng mới, kéo dài cho đến khi người dùng đó chạy thoát)

Chế độ mặc định của su là 4755 hoặc rwsr-xr-x, "s" có nghĩa là lệnh được đặt-UID (có nghĩa là nó luôn chạy như người dùng sở hữu nó, thay vì người dùng thực hiện nó. Trong trường hợp này su được sở hữu bởi root, vì vậy nó luôn chạy với quyền root)

su có các biện pháp bảo mật riêng để đảm bảo rằng người dùng thực thi quyền đó có quyền trở thành người dùng khác (thường bằng cách hỏi mật khẩu của người dùng khác), nhưng có thể hiểu rằng sẽ có lỗ hổng bảo mật trong su cho phép kẻ tấn công để bằng cách nào đó thuyết phục nó làm một cái gì đó khác mà không có thẩm quyền.

Bằng cách thay đổi chế độ thành 4750, nó ngăn người dùng thông thường (người dùng khác ngoài root và những người trong nhóm sudo) thậm chí đọc hoặc thực thi nó ở nơi đầu tiên, vì vậy kẻ tấn công sẽ cần thay đổi quyền sở hữu tệp đó hoặc thay đổi chế độ của tệp hoặc thay đổi UID / GID hiệu quả của chính họ trước khi họ thậm chí có thể cố gắng khai thác lỗ hổng lý thuyết này trong su.

Lệnh dpkg-statoverride rất hữu ích trong trường hợp này vì nó chỉ đạo trình quản lý gói sử dụng các giá trị quyền sở hữu / chế độ đó cho tệp đó, ngay cả khi nó được thay thế bằng phiên bản mới hơn (tức là thông qua nâng cấp apt). Nói cách khác, nó làm cho nó lâu dài hơn chỉ là một chown và chmod.

Đây là một chiến thuật có mục đích chung mà tôi khuyên dùng trong trường hợp này: Bất cứ khi nào tôi điều chỉnh cấu hình của su / sudo hoặc bất kỳ thành phần xác thực nào trên máy Linux / UNIX, tôi sẽ mở một phiên ssh / putty khác cho máy chủ đó và đăng nhập như người dùng root và chỉ để phiên đó mở trong một cửa sổ khác. Theo cách đó, nếu tôi làm hỏng cái gì đó và tự khóa, tôi đã có một phiên đăng nhập nơi tôi có thể sửa bất cứ thứ gì tôi đã phá vỡ.

Tùy thuộc vào người dùng của bạn, đó có thể là một ý tưởng tốt hay xấu.

Người sudùng thông thường có thể sử dụng lệnh này để đăng nhập vào bất kỳ tài khoản nào khác, không chỉ siêu nhân, miễn là họ biết mật khẩu của tài khoản.

Điều này rất hữu ích, ví dụ khi hai người dùng đang hợp tác trong một dự án, một trong số họ (userA) đã đăng nhập và họ cần đọc một tệp chỉ có thể truy cập đối với người dùng khác (userB). Đơn giản là chạy

su -c 'cat /home/userB/file' userB >file

có thể được sử dụng để sao chép tệp vào thư mục chính của người dùng đã đăng nhập, nhưng điều đó chỉ có thể nếu userA được phép chạy sulệnh.

Trên các máy chủ cơ sở dữ liệu PostgreSQL, người quản trị cơ sở dữ liệu thường có thể chuyển sang postgresngười dùng để thực hiện một số tác vụ bảo trì không thể thực hiện được trong khi máy chủ cơ sở dữ liệu đang hoạt động; để làm việc này, họ cần có khả năng chạy su - postgres.

Các cân nhắc tương tự áp dụng cho sudolệnh (khác biệt và phức tạp hơn so với su- đó chỉ là cấu hình mặc định làm cho lệnh chủ yếu hữu ích cho sudoersnhóm, vì nhóm đó được phép chạy bất kỳ lệnh nào root. Tuy nhiên, nếu bạn thêm bất kỳ quy tắc tùy chỉnh nào, ví dụ: cho phép bất kỳ người dùng nào chạy updatedbmà không có đối số, sau đó người dùng bên ngoài sudoersnhóm cần có quyền thực thi sudo.

Ngoài ra, không chỉ có suđó là setuid - còn có

• sg (cho phép tạm thời tham gia nhóm nếu có mật khẩu nhóm)
• passwd (cho phép thay đổi mật khẩu)
• chfn (cho phép thay đổi thông tin người dùng)
• chsh (cho phép thay đổi shell mặc định)

và một số người khác. Các công cụ này chia sẻ rất nhiều mã với sulệnh, vì vậy việc thay đổi chế độ /bin/sumột mình sẽ không mua cho bạn nhiều và việc thay đổi chế độ của tất cả chúng chắc chắn sẽ gây khó chịu cho người dùng của bạn, đặc biệt là trong trường hợp passwd.

Trên một máy chủ cứng, bạn muốn có ít nhị phân setuid / setgid, đặc biệt là có thể được chạy bởi tài khoản người dùng không cần công cụ cụ thể - vì một lý do đơn giản:

Bạn không hoàn toàn tin tưởng những công cụ này cho cảnh sát những gì ai đó làm với họ. Lỗi trong các chương trình như vậy hoặc sự phụ thuộc của chúng cho phép người dùng phá vỡ chính sách như vậy thường được tìm thấy và được các nhà nghiên cứu bảo mật và kẻ tấn công tích cực tìm kiếm. Cấu hình sai (hành vi su phụ thuộc vào cấu hình thư viện PAM) có thể gây ra vấn đề tương tự. Vì vậy, mọi nhị phân setuid / setgid mà một tài khoản (dịch vụ hoặc người dùng) nhất định có thể chạy là một véc tơ tiềm năng để có được quyền truy cập root không mong muốn.

Mặc dù các sự cố đã biết trong phần mềm như vậy thường sẽ khiến các bản vá / cập nhật nhanh chóng có sẵn, nhưng việc buộc phải cài đặt chúng nhanh chóng có thể gây gián đoạn - và một số lỗ hổng có thể không được mọi người biết đến, kể cả nhà cung cấp.

Vì vậy, để giảm thiểu khả năng giải quyết vấn đề khẩn cấp, bạn nên làm điều gì đó như /programming/2189976/find-suid-and-gid-files-under-root , sau đó nghiên cứu xem có thể được loại bỏ (hầu hết trong số họ NẾU bạn đang chạy một máy chủ được xây dựng có mục đích và biết bạn đang làm gì), tốt nhất là sử dụng các phương pháp như dpkg-statoverride mà hệ thống quản lý gói của bạn hỗ trợ để giữ các thay đổi đó vĩnh viễn.

Có một lý do khác để hạn chế quyền truy cập vào "su" trong các thiết lập cụ thể với NFS trường học cũ - vì lý do chính trị, về cơ bản, bạn có thể hạn chế tài khoản root (một số người dùng có thể nhận được, vì lý do chính trị. su tầm thường, vì nó phá vỡ cờ root_squash của một mount NFS.