Chúng tôi đang có một vấn đề nhỏ trên một máy chủ. Chúng tôi muốn rằng một số người dùng sẽ có thể thực hiện ví dụ sudovà trở thành root, nhưng với hạn chế là người dùng không thể thay đổi mật khẩu root. Đó là, đảm bảo rằng chúng tôi vẫn có thể đăng nhập vào máy chủ đó và trở thành root bất kể người dùng khác sẽ làm gì.

Điều đó có thể không?

Chúng tôi muốn rằng một số người dùng sẽ có thể làm ví dụ sudovà trở thành root,

Vâng, đó là vấn đề sudo được thiết kế để giải quyết, vì vậy phần đó đủ dễ dàng.

nhưng với hạn chế là người dùng không thể thay đổi mật khẩu root.

Bạn có thể, như SHW đã chỉ ra trong một bình luận, cấu hình sudo để chỉ cho phép một số hành động nhất định được thực hiện dưới quyền root bởi một số người dùng. Nghĩa là, bạn có thể cho phép user1 làm sudo services apache2 restart, cho phép user2 làm sudo rebootnhưng không làm gì khác, trong khi cho phép người quản trị được thuê làm hệ thống user3làm sudo -i. Có nhiều hướng dẫn về cách thiết lập sudo như thế hoặc bạn có thể tìm kiếm (hoặc hỏi) tại đây. Đó là một vấn đề có thể giải quyết được.

Tuy nhiên, một người dùng đã được cấp khả năng sudo -ihoặc sudovào một vỏ ( sudo bashví dụ) có thể làm bất cứ điều gì. Đó là bởi vì vào thời điểm sudo ra mắt shell, sudo đã ra khỏi hình ảnh. Nó cung cấp bối cảnh bảo mật của một người dùng khác (thường là root), nhưng không nói rõ ứng dụng đã thực hiện là gì. Nếu ứng dụng đó lần lượt ra mắt passwd root, không có gì sudo có thể làm về nó. Lưu ý rằng điều này cũng có thể được thực hiện thông qua các ứng dụng khác; ví dụ, nhiều trình soạn thảo nâng cao hơn cung cấp các phương tiện để thực thi lệnh thông qua shell, shell sẽ được thực thi với uid hiệu quả của quá trình soạn thảo đó (nghĩa là root).

Đó là, đảm bảo rằng chúng tôi vẫn có thể đăng nhập vào máy chủ đó và trở thành root bất kể người dùng khác sẽ làm gì.

Lấy làm tiếc; nếu bạn thực sự có nghĩa là "đảm bảo chúng tôi sẽ có thể đăng nhập và sử dụng hệ thống bất kể ai đó có quyền truy cập root làm gì với nó", điều đó (cho tất cả ý định và mục đích) không thể được thực hiện. Một "sudo rm / etc / passwd" hoặc "sudo chmod -x / bin / bash" nhanh chóng (hoặc bất cứ cách nào sử dụng root shell) và dù sao bạn cũng bị hos khá nhiều. "Khá nhiều hosed" có nghĩa là "bạn sẽ cần khôi phục từ bản sao lưu và hy vọng họ không làm gì tệ hơn là trượt ngón tay". Bạn có thể thực hiện một số bước để giảm nguy cơ rủi ro do tai nạn dẫn đến một hệ thống không thể sử dụng được, nhưng bạn không thể ngăn chặn ác ý gây ra các vấn đề rất nghiêm trọng và bao gồm cả việc cần phải xây dựng lại hệ thống từ đầu hoặc ít nhất là đã biết sao lưu tốt.

Bằng cách cấp quyền truy cập root không bị chặn trên hệ thống cho người dùng, bạn tin tưởng người dùng đó (bao gồm mọi phần mềm họ có thể chọn để thực thi, thậm chí một thứ gì đó trần tục như ls) để không có ý định xấu và không gây rối. Đó là bản chất của quyền truy cập root.

Truy cập root hạn chế thông qua ví dụ sudo tốt hơn một chút, nhưng bạn vẫn phải cẩn thận để không mở bất kỳ vectơ tấn công nào. Và với quyền truy cập root, có rất nhiều vectơ tấn công có thể cho các cuộc tấn công leo thang đặc quyền.

Nếu bạn không thể tin tưởng họ với mức độ truy cập đó là gốc đòi hỏi, bạn sẽ cần hoặc là một rất chặt xuống cấu hình sudo, hay chỉ đơn giản là không cấp cho người dùng trong việc tiếp cận gốc câu hỏi ở tất cả các thông qua bất kỳ phương tiện nào, sudo hoặc ngược lại.

Điều này thực tế là không thể. Trước hết, nếu bạn cho họ sức mạnh để trở thành root , thì bạn không thể làm gì để ngăn họ làm bất cứ điều gì. Trong trường hợp sử dụng của bạn, sudonên được sử dụng để cấp cho người dùng của bạn một số quyền hạn gốc trong khi hạn chế những người khác mà không cho phép họ trở thành root .

Trong kịch bản của bạn, bạn sẽ cần phải hạn chế quyền truy cập vào suvà passwdcác lệnh và truy cập mở vào khá nhiều thứ khác. Vấn đề là, bạn không thể làm gì để ngăn người dùng chỉnh sửa /etc/shadow(hoặc /etc/sudoerscho vấn đề đó) trực tiếp và thả mật khẩu gốc thay thế để chiếm quyền root. Và đây chỉ là kịch bản "tấn công" đơn giản nhất có thể. Sudoers với sức mạnh không giới hạn ngoại trừ một hoặc hai lệnh có thể hoạt động xung quanh các hạn chế để chiếm quyền truy cập root đầy đủ.

Giải pháp duy nhất, như được đề xuất bởi SHW trong các bình luận là sử dụng sudođể cấp cho người dùng của bạn quyền truy cập vào một nhóm lệnh bị hạn chế thay thế.

Cập nhật

Có thể có một cách để thực hiện điều này nếu bạn sử dụng vé Kerberos để xác thực. Đọc tài liệu này giải thích việc sử dụng các .k5logintập tin.

Tôi trích dẫn các phần có liên quan:

Giả sử alice người dùng có tệp .k5login trong thư mục chính của cô ấy chứa dòng sau:
bob@FOOBAR.ORG
Điều này sẽ cho phép bob sử dụng các ứng dụng mạng Kerberos, chẳng hạn như ssh (1), để truy cập tài khoản của alice, sử dụng vé Kerberos của bob.
...
Lưu ý rằng vì bob giữ lại vé Kerberos cho hiệu trưởng của mình bob@FOOBAR.ORG, anh ta sẽ không có bất kỳ đặc quyền nào yêu cầu vé của alice, chẳng hạn như quyền truy cập root vào bất kỳ máy chủ nào của trang web hoặc khả năng thay đổi mật khẩu của alice.

Tôi có thể bị nhầm, mặc dù. Tôi vẫn đang lướt qua các tài liệu và chưa tự mình thử Kerberos.

Tôi giả sử bạn muốn đảm bảo rằng bạn có quyền truy cập "quản trị viên khẩn cấp", ngay cả khi quản trị viên thực tế của bạn làm hỏng (nhưng ngoài điều đó, bạn hoàn toàn tin tưởng quản trị viên chính).

Một cách tiếp cận phổ biến (mặc dù rất hackish) là có một người dùng thứ haiuid=0 , thường được đặt tên toor(gốc ngược). Nó có một mật khẩu khác nhau, và có thể phục vụ như một truy cập sao lưu. Để thêm, bạn có thể cần phải chỉnh sửa /etc/passwdvà /etc/shadow(sao chép các rootdòng).

Đó là tất cả nhưng không an toàn, nhưng nếu bạn chỉ cần bảo vệ chống lại "quản trị viên chính" thay đổi mật khẩu mà không cần thông báo, thì nó sẽ hoạt động. Việc vô hiệu hóa bằng cách xóa toortài khoản; vì vậy lợi ích duy nhất là có một mật khẩu riêng.

Ngoài ra, bạn có thể muốn xem xét các cơ chế xác thực thay thế, ví dụ: sshkhóa libnss-extrausers, LDAP, v.v.

Lưu ý rằng quản trị viên vẫn có thể làm hỏng việc. Ví dụ, bằng cách chặn tường lửa.

Nếu bạn muốn có một hệ thống rất an toàn, hãy cân nhắc sử dụng SELinux, trong đó người dùng unix (ví dụ root) cũng đi kèm với một vai trò, có thể được xử lý tốt hơn nhiều. Bạn có thể muốn cấp quyền truy cập root cho quản trị viên của mình, nhưng chỉ có một vai trò bị hạn chế (ví dụ: chỉ quản trị apache). Nhưng điều này sẽ đòi hỏi khá nhiều nỗ lực từ phía bạn để cấu hình chính sách.

Bản chất của root là có lệnh không giới hạn của hệ thống. Bạn có thể tinh chỉnh nó bằng SELinux (trước đây từng có một trang demo, nơi mọi người có thể đăng nhập bằng root, nhưng sức mạnh của nó bị tê liệt thông qua hệ thống truy cập), nhưng đó không phải là vấn đề. Vấn đề là đây là giải pháp sai cho vấn đề của bạn.

Bây giờ, bạn chưa nói vấn đề của bạn là gì, nhưng nếu bạn không tin tưởng những người dùng này sẽ giữ mật khẩu gốc, họ không có doanh nghiệp nào là root. Nếu họ cần quản trị máy chủ web, hoặc các thiết bị phần cứng khác nhau, hoặc ổ đĩa dọc hoặc bất cứ thứ gì, hãy thiết lập một giải pháp cho điều đó. Tạo một nhóm siêu năng lực, cung cấp cho nó tất cả quyền truy cập mà nó cần và thêm chúng vào đó. Nếu họ cần thực hiện các cuộc gọi hệ thống chỉ root, hãy viết một số chương trình setuid.

Tất nhiên một người dùng có loại quyền truy cập đó (và một chút kiến ​​thức) có thể dễ dàng hack hệ thống, nhưng ít nhất bạn đang làm việc với mô hình bảo mật hệ điều hành, chứ không phải chống lại nó.

Tái bút Có nhiều cách để sắp xếp quyền truy cập root cho chính bạn mà không cần mật khẩu; đối với một, nếu bạn ở /etc/sudoers(không có giới hạn), bạn chỉ cần mật khẩu của riêng mình để trở thành root, ví dụ như với sudo bash. Nhưng bạn không cần phải đến đó.

Về lý thuyết, có lẽ có thể thực hiện được điều này bằng cách sử dụng SELinux . Điều này cho phép bạn thiết lập các quy tắc chính xác hơn nhiều về những gì người dùng hoặc quá trình là hoặc không được phép làm. Ngay cả với SELinux, có thể rất khó để khiến người dùng không thể thay đổi mật khẩu gốc, nhưng vẫn có thể làm bất cứ điều gì họ cần làm.

Thực sự nó phụ thuộc vào những gì người dùng không được phép thay đổi mật khẩu gốc thực sự cần phải có thể làm được. Có lẽ sẽ dễ dàng và an toàn hơn nếu chỉ tìm ra đó là gì và cấp các quyền đó cụ thể bằng sudo.

Có lẽ bạn nên xem xét cho phép người dùng có quyền truy cập root vào máy ảo hoặc bộ chứa LXC. Điều đó sẽ cho phép họ có quyền truy cập root đầy đủ vào một hệ thống, mà không để họ ngăn bạn đăng nhập vào máy chủ hoặc thực hiện các hành động hành chính.

Tôi không biết nó sẽ khả thi trên thực tế nhưng đây là một bản hack bẩn:

1. viết một kịch bản / chương trình bao bọc sẽ sao chép /etc/passwdtệp vào một số vị trí khác, trước khi gọi thực tếsudo
2. Cho phép người dùng bình thường sử dụng sudo
3. Khi anh ta hoàn thành nhiệm vụ của mình, hoặc khi anh ta thoát khỏi sudo, hãy khôi phục lại /etc/passwdtệp

Tôi biết, có rất nhiều điều cộng trừ bạn phải xem xét để đạt được điều này. Rốt cuộc, đó là một hack bẩn

Tuyên bố sudochỉ dành cho việc cấp quyền và không có sự bảo vệ nào sau đó là sai một cách trắng trợn.

Bạn sử dụng visudođể sửa đổi tập tin sudoers. Đây là một dòng ví dụ:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandrolà tên người dùng chúng tôi cho phép. Đặt một %ở phía trước để làm cho nó áp dụng cho một nhóm.
• ALLlà một tên cho quy tắc này. Sudoers có thể làm nhiều hơn là chỉ cấp quyền toàn cầu. Đó là nơi nó trở nên phức tạp.
• = không cần giải thích
• ALL:ALLđọc là (who_to_run_it_as: what_group_to_run_it_as). Bằng cách này, bạn có thể cho phép chạy một lệnh, nhưng chỉ trong ngữ cảnh của một người dùng hoặc nhóm cụ thể.
• NOPASSWD: bảo nó tắt dấu nhắc mật khẩu.
• /path/to/command cho phép bạn chỉ định các lệnh cụ thể path_to_commmand, Another_command

Điều cần nhớ là trong khi sudohầu hết được sử dụng bởi người dùng gia đình để leo thang đến các đặc quyền gốc, nó có thể và được sử dụng để kiểm soát truy cập vào các lệnh cụ thể theo cách chi tiết hơn nhiều.

Người giới thiệu

• từ câu trả lời khác của tôi ở đây

(Tôi không biết Ubuntu, nhưng nó tương tự như Fedora / Red-Hat)
Điều duy nhất tôi có thể tưởng tượng là hạn chế quyền truy cập để thay đổi mật khẩu gốc là không cho phép truy cập root đầy đủ, có thể bằng sudo hoặc sử dụng SElinux để hạn chế quyền truy cập vào tệp mật khẩu ... nhưng tôi sẽ không tin tưởng nhiều quyền truy cập vì root thường có quyền truy cập không hạn chế và có thể cập nhật SElinux, hoặc dán lại tệp mật khẩu hoặc chạy một số chương trình được cài sẵn trước để thay đổi mật khẩu.

Nếu bạn không tin tưởng họ đủ để không thay đổi mật khẩu, có lẽ bạn không nên cho họ quyền truy cập root. Nếu không tôi sẽ đoán bạn đang cố gắng tránh tai nạn.

Nếu bạn chỉ cố gắng bảo vệ quyền truy cập của mình vào root, hãy thiết lập một chương trình có thể khôi phục mật khẩu gốc, vì vậy ngay cả khi nó bị thay đổi, nó vẫn có thể được khôi phục với quyền truy cập tối thiểu. (sudo tự làm tốt)

Yêu cầu của bạn là:

Chúng tôi đang gặp một vấn đề nhỏ trên máy chủ [...] đó là đảm bảo rằng chúng tôi vẫn có thể đăng nhập vào máy chủ đó và trở thành root bất kể người dùng khác sẽ làm gì.

Từ câu hỏi của bạn, có vẻ như bạn không phải đối mặt với những người dùng độc hại ngẫu nhiên có ý định phá hủy hệ thống của bạn, nhưng thay vào đó, có những người dùng bán đáng tin cậy có thể gây ra sự nghịch ngợm ngay bây giờ (có lẽ là sinh viên?). Đề xuất của tôi giải quyết tình huống đó, không phải là một cuộc tấn công toàn diện của người dùng độc hại.

1. Chạy máy chủ trong một môi trường ảo. Bạn sẽ có thể gắn hệ thống tệp của máy chủ và thay thế các tệp đã thay đổi bằng các phiên bản đã biết. Tùy thuộc vào thiệt hại có thể bạn dự đoán, bạn có thể chụp nhanh tất cả các thư mục quan trọng (/ bin, / sbin, / etc, / usr, / var, v.v.) và mở rộng ảnh chụp nhanh để ghi đè lên các tệp bị hỏng trong khi phần còn lại của hệ thống nguyên vẹn.

2. Chạy hệ thống chỉ đọc, ví dụ từ DVD-R. Nếu bạn có thể sống với hầu hết các phần của hệ thống ở trạng thái tĩnh cho đến lần khởi động lại tiếp theo, đây là một lựa chọn tốt. Bạn cũng có thể sử dụng cửa hàng sao lưu chỉ đọc với môi trường ảo hoặc tải hệ thống cơ bản qua mạng, thực hiện thay đổi giữa các lần khởi động lại dễ dàng hơn nhiều so với việc ghi DVD-R mới.

3. Mô-đun hạt nhân. Các mô-đun bảo mật Linux (LSM) của hạt nhân cung cấp cơ sở để tạo các mô-đun bảo mật. LSM được sử dụng bởi SELinux, nhưng cũng được sử dụng bởi một số hệ thống ít được biết đến và đơn giản hơn, chẳng hạn như Smack, TOMOYO và AppArmor. Bài viết này có một cái nhìn tổng quan tốt về các tùy chọn. Cơ hội là một trong những cơ hội có thể được cấu hình ngoài hộp để ngăn truy cập ghi vào / etc / passwd, / etc / bóng hoặc bất kỳ tệp nào bạn muốn, thậm chí bằng root.

4. Ý tưởng tương tự như số 1, nhưng khi máy chủ không ở trong môi trường ảo. Bạn có thể tải chuỗi máy chủ vào một hệ điều hành chỉ đọc như đĩa CD trực tiếp, nó sẽ tự động gắn hệ thống tập tin của máy chủ và ghi đè hệ thống cơ sở trên mỗi lần khởi động bằng các bản sao tốt. HĐH chỉ đọc sau đó sẽ khởi động vào HĐH chính.

5. Một lần nữa, giả sử đây là những người dùng bán đáng tin cậy có trách nhiệm với một người cao hơn (giáo viên / sếp), câu trả lời tốt nhất có thể là Kiểm toán Linux . Bằng cách này, bạn sẽ biết mọi hành động liên quan đến bảo mật được thực hiện và ai đã thực hiện (bạn sẽ biết ai đã thực hiện vì ngay cả khi tất cả người dùng chia sẻ tài khoản root, họ sẽ bị xóa từ tài khoản người dùng trước). Trong thực tế, bạn thậm chí có thể phân tích nhật ký kiểm toán trong thời gian thực và thay thế các tệp bị hỏng. / etc / bóng đè lên? Không có vấn đề gì, chỉ cần có máy chủ giám sát ngay lập tức thay thế nó bằng một phiên bản nổi tiếng.

Các công nghệ khác bạn có thể muốn điều tra dựa trên nhu cầu của bạn:

• Kiến trúc đo lường toàn vẹn Linux / Mô đun xác minh mở rộng (IMA / EVM) và
• Mô-đun nền tảng đáng tin cậy (TPM).

Để bổ sung cho các câu trả lời khác, tôi sẽ giả sử kịch bản là bạn nhận thấy việc mất quyền kiểm soát root là một tình huống hiếm gặp và trong những trường hợp đó, việc khởi động lại máy chủ được cho phép. (Rốt cuộc, nếu bạn tin rằng máy đã bị xâm nhập, bạn sẽ muốn mang nó ngoại tuyến.)

Ưu điểm lớn của việc này là không có gì để cấu hình. Câu hỏi của bạn trở thành: " Tôi đã quên mật khẩu root, làm cách nào để tôi quay lại? " Và câu trả lời cho điều đó là khởi động lại và chọn chế độ một người dùng khi máy xuất hiện. Điều đó cung cấp cho bạn một shell root mà không cần biết mật khẩu. Tại thời điểm đó, bạn có thể thiết lập một mật khẩu mới. (Cũng như đi và sửa chữa bất kỳ thiệt hại ...)

Nếu bạn sao chép máy chủ của mình vào máy ảo (như VirtualBox ), bạn có thể cấp quyền truy cập gốc cho mọi người và vẫn đảm bảo rằng bạn sẽ luôn có quyền truy cập trực tiếp vào (các) phân vùng của hệ điều hành khách, và do đó duy trì quyền kiểm soát cuối cùng đối với /etc/passwdvà Giống như, vì bạn sẽ có root trên hệ thống máy chủ.

Tất nhiên, việc cấp quyền truy cập root không bị chặn vẫn có thể không phải là giải pháp phù hợp: nếu bảo mật dữ liệu hoàn toàn là vấn đề hoặc trách nhiệm của bạn, bạn không thể cấp quyền truy cập root.

Yêu cầu là không thể về mặt kỹ thuật. Như đã nhận xét một cách hùng hồn, việc cấp quyền không giới hạn hoặc thậm chí hạn chế hơn sudocho người dùng có nghĩa là bạn tin tưởng người dùng đó. Ai đó có ý định xấu xa và đủ khả năng kỹ thuật và sự kiên trì có thể vượt qua bất kỳ trở ngại nào được đưa ra.

Tuy nhiên, giả sử bạn có thể tin tưởng người dùng của mình không có ý đồ xấu, bạn có thể hạn chế mật khẩu thay đổi vấn đề chính sách . Bạn có thể tạo một trình bao bọc cho passwdchương trình sẽ nhắc nhở họ "vui lòng không thay đổi mật khẩu gốc". Điều này giả định nguồn gốc của vấn đề là người dùng đang thay đổi mật khẩu gốc đang thực hiện do hiểu lầm (như có thể nghĩ rằng họ đang thay đổi mật khẩu của chính mình sau khi thực hiện sudo bash).

Trong trường hợp đặc biệt (hiếm), nếu không thể tin tưởng hoàn toàn và không thể phá vỡ sudoquyền truy cập vào các phần đầy đủ nhưng hợp lý an toàn, bạn có thể xem xét thiết lập các biện pháp trừng phạt của tổ chức đối với việc thay đổi mật khẩu (hoặc bất kỳ hình thức giả mạo hệ thống cụ thể nào khác), sắp xếp giám sát các tài nguyên quan trọng để không dễ bị phát hiện xung quanh các chính sách đã đặt - và công khai và minh bạch về các quy tắc sử dụng và giám sát.

Khía cạnh giám sát và khám phá là vấn đề kỹ thuật cứng được hưởng lợi từ một câu hỏi khác mà bạn nên chọn để đi trên con đường đó. Dường như với tôi, chúng ta sẽ cần phải

1. phát hiện khi người dùng thay đổi danh tính thành root và theo dõi mọi quá trình đã tạo;
2. đăng nhập các sáng tạo quy trình từ đó trở đi để xem ai là người dùng ban đầu chịu trách nhiệm cho mỗi quy trình và sử dụng máy chủ từ xa nơi người dùng nửa tin cậy không có quyền truy cập để gửi nhật ký;
3. sử dụng một số loại theo dõi hệ thống để ghi lại những gì đang xảy ra và sau đó có thể khám phá ra ai là người đứng sau vi phạm chính sách.

Chúng tôi ít nhất sẽ cần phải đăng nhập mở các tập tin khác ngoài tập tin an toàn để ghi, tạo quy trình exec()và tất nhiên mọi nỗ lực thay đổi mạng.

Việc thực hiện có thể được thực hiện bằng cách sửa đổi libc hoặc theo dõi cuộc gọi hệ thống (tốt hơn nhiều).

Tất nhiên, không thể thực hiện theo dõi và ghi nhật ký như vậy chính xác 100%, không dễ thực hiện và nó cũng đòi hỏi các tài nguyên bổ sung để hoạt động. Điều này sẽ không ngăn chặn việc thay đổi mật khẩu hoặc giả mạo hệ thống không mong muốn khác, nhưng nó sẽ giúp tìm ra người dùng có tội hoặc ít nhất là tạo ra ảo tưởng rằng có sự giám sát và làm cho nó ít mời hơn đối với một số người dùng có đầu óc xấu xa (nhưng một số vấn đề yêu thích tin tặc nhìn thấy sự vô ích cơ bản của các biện pháp kỹ thuật được đưa ra có thể cảm thấy được khuyến khích chấp nhận thách thức và cố gắng phá vỡ hệ thống chỉ để giải trí).

Các câu hỏi ban đầu công thức là vô ích. Có vẻ như mục tiêu chính là "vẫn có thông tin đăng nhập" vì vậy nói về một số mục nhập khẩn cấp luôn hoạt động chắc chắn ngay cả với quyền truy cập root được cấp cho người khác. Chúc mừng Anony-Mousse, người đầu tiên ghi nhận nó một cách rõ ràng.

Vấn đề là: Nếu chủ sở hữu có quyền truy cập vật lý vào hộp Nó có thể dễ dàng khôi phục các điểm hợp lý cho hệ thống (miễn là nó vẫn còn sống :). Nếu không - việc giữ mật khẩu root sẽ không cứu được, ví dụ như sshd xuống hoặc thiết lập mạng xấu, do đó hệ thống vẫn không thể truy cập được.

Chủ đề về cách ngăn hệ thống khỏi thiệt hại bởi một người có đặc quyền quản trị dường như quá rộng để phù hợp với định dạng câu hỏi SE.

Nói về giải pháp nhập khẩn cấp từ xa, cách tốt nhất là IPMI (tôi nghĩ) nếu có sẵn. Chủ sở hữu hệ thống có thể tùy chỉnh ổ đĩa ảo bất cứ lúc nào, khởi động từ Nó và được phục hồi với hệ thống phục hồi.

Nếu IPMI không có sẵn, bất kỳ công nghệ ảo hóa phù hợp nào cũng có thể hoạt động được, như đã được đề xuất ở trên.

Bạn có thể giới hạn quyền truy cập vào sudo trong /etc/sudoerstệp của bạn

Để giải thích đầy đủ cú pháp của / etc / sudoers, chúng tôi sẽ sử dụng quy tắc mẫu và chia nhỏ từng cột:

jorge  ALL=(root) /usr/bin/find, /bin/rm

Cột đầu tiên xác định người dùng hoặc nhóm quy tắc sudo này áp dụng cho. Trong trường hợp này, nó là jorge người dùng. Nếu từ trong cột này đứng trước ký hiệu%, thì từ đó chỉ định giá trị này là một nhóm thay vì người dùng, vì một hệ thống có thể có người dùng và các nhóm có cùng tên.

Giá trị thứ hai (ALL) xác định những gì lưu trữ quy tắc sudo này áp dụng cho. Cột này hữu ích nhất khi bạn triển khai môi trường sudo trên nhiều hệ thống. Đối với hệ thống Ubuntu trên máy tính để bàn hoặc hệ thống mà bạn không có kế hoạch triển khai các vai trò sudo cho nhiều hệ thống, bạn có thể thoải mái để giá trị này được đặt thành TẤT CẢ, là ký tự đại diện phù hợp với tất cả các máy chủ.

Giá trị thứ ba được đặt trong ngoặc đơn và xác định người dùng hoặc người dùng nào mà người dùng trong cột đầu tiên có thể thực thi lệnh như. Giá trị này được đặt thành root, có nghĩa là jorge sẽ được phép thực thi các lệnh được chỉ định trong cột cuối cùng với tư cách là người dùng root. Giá trị này cũng có thể được đặt thành TẤT CẢ ký tự đại diện, cho phép jorge chạy các lệnh như bất kỳ người dùng nào trên hệ thống.

Giá trị cuối cùng (/ usr / bin / find, / bin / rm) là danh sách các lệnh được phân tách bằng dấu phẩy mà người dùng trong cột đầu tiên có thể chạy như (các) người dùng trong cột thứ ba. Trong trường hợp này, chúng tôi cho phép jorge chạy find và rm với quyền root. Giá trị này cũng có thể được đặt thành TẤT CẢ ký tự đại diện, cho phép jorge chạy tất cả các lệnh trên hệ thống dưới dạng root.

Với suy nghĩ này, bạn có thể cho phép các lệnh X theo cách phân cách bằng dấu phẩy và miễn là bạn không thêm passwdvào điều này, bạn sẽ ổn thôi

Không có 1/2 root :) Một khi bạn cung cấp quyền root, họ có thể làm bất cứ điều gì họ muốn. Ngoài ra, bạn có thể sử dụng sudo để chạy shell bash bị hạn chế hoặc chạy rbash mà không có quyền root.

Nếu bạn muốn có một cơ chế không an toàn để đăng nhập vào máy chủ với quyền root, bạn có thể tạo một người dùng khác bằng uid=0hoặc tạo một cron đơn giản sẽ đặt lại mật khẩu gốc theo định kỳ.

Hãy thử thêm một nhóm bánh xe thay vì sử dụng sudo. sudo cho phép người dùng thực thi như thể họ là root, điều đó có nghĩa là nó không khác gì chạy:

su -

để trở thành root. Các uid gốc = 0; bánh xe uid = 10. Mọi người sử dụng tên nhưng hệ điều hành sử dụng uid. Một số lệnh nhất định không thể được chạy bởi một thành viên của nhóm bánh xe. (Nếu bạn sử dụng bánh xe, đừng phạm sai lầm khi thêm root làm thành viên nhóm bánh xe). Hãy xem tài liệu của Red Hat nếu bạn không biết bánh xe là gì.

Một tùy chọn khác là sử dụng khóa ssh thay vì mật khẩu. Giả sử bạn có thể chắc chắn rằng những người sử dụng sudo không thêm khóa công khai của họ vào tệp ~ / .ssh / ủy quyền, điều này sẽ xoay quanh bất kỳ mối lo ngại nào về việc thay đổi mật khẩu gốc vì mật khẩu gốc bị bỏ qua một cách hiệu quả.

Nếu bạn muốn mở rộng lòng tin cho những người dùng này (không thêm khóa công khai của riêng họ), hãy thử sử dụng các thuộc tính tệp mở rộng và sử dụng bit Không thay đổi. Sau khi tạo tệp ~ / .ssh / ủy quyền của bạn và sau khi định cấu hình / etc / ssh / sshd_config và / etc / ssh / ssh_config như bạn muốn, hãy đặt bit Bất biến. Chắc chắn, có nhiều cách để giải quyết vấn đề đó - không có gì là hoàn hảo.

Trong bất kỳ hệ thống nào, người trong cuộc là rủi ro cao nhất. Người điều hành chương trình nằm ở đầu đống. Một suy nghĩ liên quan liên quan đến hợp đồng. Luật sư sẽ nói với bạn, "Không bao giờ làm kinh doanh với người mà bạn cần hợp đồng để làm kinh doanh". Tâm lý chung cho chúng ta, "Không bao giờ kinh doanh mà không có hợp đồng". Khi bạn tìm thấy một người mà bạn đủ tin tưởng để làm kinh doanh, hãy viết hợp đồng dựa trên nhu cầu của nhau.

Tất cả các câu trả lời được gửi, bao gồm cả của tôi, không giải quyết được quyền truy cập vật lý. Bất cứ ai có nó, có quyền kiểm soát. Nếu đó không phải là bạn thì có khả năng bạn sẽ có được người truy cập vật lý vào máy trong trường hợp ai đó tìm cách ngăn bạn đăng nhập hoặc nếu họ tìm cách đăng nhập ngay cả sau bạn Tôi đã cố gắng ngăn điều đó xảy ra. Tất nhiên, nếu bạn có quyền truy cập vật lý hơn thì có thể không cần bất kỳ điều gì trong số này mặc dù việc thực hiện một cặp đôi vẫn nên được xem xét, nếu bạn quan tâm đến việc KHÔNG bị bất tiện.

-John Crout

Một cách sẽ là đảm bảo rằng /etckhông thể ghi được. Bởi không ai, miễn là có thể có một sudoerxung quanh.

Điều đó có thể được thực hiện bằng cách gắn nó qua mạng và đảm bảo ở phía bên kia rằng thiết bị không thể được viết.

Điều đó có thể được thực hiện bằng cách sử dụng một thiết bị cục bộ ngăn chặn truy cập ghi vào nó. (Tra cứu write blockerphần cứng)

Phần quan trọng là hạn chế phải áp dụng bên ngoài khái niệm gốc của máy đó. Một hacker sáng tạo sẽ tìm đường đi xung quanh tất cả các chướng ngại vật bạn đặt trên môi trường mà anh ta có thể kiểm soát. Vì vậy, nếu root có thể thay đổi mật khẩu của nó, thì có thể a sudoer.

Để chắc chắn rằng người dùng cũng không thể tăng khả năng đăng nhập của bạn, bạn phải gắn kết chỉ đọc /binvà /sbin.

Và bạn sẽ phải có một tập lệnh khôi phục kết nối mạng định kỳ.

(Là một sidenote: Nếu bạn cho phép các sudoer chỉ là một tập hợp rất hạn chế về các lệnh và cho mỗi người trong số họ đảm bảo rằng họ không thể thoát ra khỏi chúng / thay thế chúng, vv, sau đó bạn có thể ngăn chặn nó trong khi có /etcthể ghi ..)