Khi Ubuntu hỏi mật khẩu người dùng của quản trị viên, làm thế nào để quyết định người dùng quản trị nào sẽ yêu cầu?


11

Tôi đang thiết lập một máy Ubuntu (10.10) sẽ được sử dụng bởi nhiều người. Nó là một máy dùng chung trong một văn phòng nhỏ. Vai trò chính của nó là lưu trữ các máy ảo với VirtualBox và phục vụ các tệp với Samba.

Đối với Samba, một số tài khoản người dùng cần được thiết lập để nhiều người có thể kết nối với cổ phiếu Samba từ các máy trạm của riêng họ. Tuy nhiên, cũng có một tài khoản dành riêng cho việc chỉ chạy các máy ảo, mà nhiều người sẽ sử dụng. Đôi khi mọi người cố gắng thực hiện mọi thứ với tài khoản này yêu cầu các đặc quyền nâng cao - điều này khiến hộp thoại "vui lòng nhập mật khẩu của người dùng quản trị" của Gnome bật lên. Tuy nhiên, hộp thoại này yêu cầu mật khẩu của tôi - khi tôi thiết lập máy, tài khoản của tôi là tài khoản đầu tiên được tạo, do đó dường như tôi cho rằng tôi là người dùng duy nhất được cấp quyền sudo.

Tôi muốn chỉ định một người dùng khác là "quản trị viên của khu nghỉ dưỡng đầu tiên", có thể nói, và đó không thể là người dùng tài khoản dùng chung, vì mọi người đều phải biết mật khẩu của tài khoản đó, vì vậy tôi muốn các đặc quyền của nó bị hạn chế nghiêm ngặt. Đó không thể là tài khoản của tôi, vì tôi không nói cho người khác biết mật khẩu của mình và tôi sẽ không có mặt tại trang web đủ để tự nhập. Tuy nhiên, có một người có thể làm điều này trực tiếp, vì vậy tôi đã thêm họ vào /etc/sudoers. Làm thế nào tôi có thể nói với Ubuntu rằng khi cần nâng cao đặc quyền cho một thứ gì đó, trước tiên nên yêu cầu tài khoản của họ ?

Để tóm tắt:

  • Tài khoản trên máy: Alice, Bob, Carol, Dave, Eliza.
  • Khi Ubuntu được cài đặt, Alice là người dùng đầu tiên, được thêm vào trong quá trình cài đặt.
  • "Dave" thực sự là một tài khoản được nhiều người sử dụng, những người không thể vào được /etc/sudoersvì mật khẩu của nó là kiến ​​thức công khai.
  • Bob đã được thiết lập là một tài khoản "Hành chính" trong Gnome và được nhập một cách thích hợp /etc/sudoers- Bob là ông chủ tại văn phòng này.
  • Khi các hành động cần đặc quyền nâng cao được thử trong khi đăng nhập như Bob, Carol, Eliza hoặc Dave, hệ thống sẽ yêu cầu thông tin đăng nhập của Bob.
  • Khi các hành động cần đặc quyền nâng cao được cố gắng khi đăng nhập với tư cách là Alice, hệ thống sẽ yêu cầu thông tin đăng nhập của Alice (mặc dù Alice là một loại sysadmin của buckaroo và có thói quen sử dụng su -để thực hiện các tác vụ quản trị mở rộng).

Những thay đổi cấu hình nào tôi cần thực hiện để mang lại trạng thái mong muốn ở đây?


Một cách khác là cho phép các lệnh liên quan đến ảo hóa tự động sử dụng các đặc quyền của quản trị viên. Tôi chắc chắn tôi đã đọc một câu hỏi về điều đó, nhưng tôi đã quên.
Oxwivi

Googling nhanh chóng cho tôi biết bạn làm điều đó từ cùng một sudoerstệp, bạn có thể kiểm tra trang này để biết thêm thông tin.
Oxwivi

Tôi đã cân nhắc điều đó khi tôi chỉnh sửa sudoers: đó không phải là một khu nghỉ mát đầu tiên vì những lo ngại về an ninh. Cũng xem câu trả lời của enzotib - một phần của vấn đề là sự nhầm lẫn giữa sudovà PolicyKit.
Brighid McDonnell

Câu trả lời:


9

Trước hết hãy chỉ ra rằng các hành động đặc quyền được phép cho người dùng không root thông qua hai cơ chế khác nhau.

  1. sudo

  2. Chính sách

Cái đầu tiên được sử dụng khi bạn chạy một lệnh rõ ràng với sudohoặc một mục menu có lệnh được gói gksu(như Trình quản lý gói Synaptic ).
Trong trường hợp này, mật khẩu bắt buộc là của người dùng gọi, thường là người dùng đăng nhập.

Cái thứ hai được sử dụng khi một ứng dụng nhận biết Chính sách cố gắng thực hiện một hành động đặc quyền. Trong trường hợp như vậy, ứng dụng sẽ hỏi Cơ quan cục bộ chính sách (thông qua D-Bus) nếu hành động có thể được thực thi. Chính quyền địa phương sau đó, thông qua một Đại lý xác thực, yêu cầu người dùng hoạt động chứng minh danh tính của mình. Các cửa sổ hộp thoại giống như sau (không may có văn bản bằng tiếng Ý :)

nhập mô tả hình ảnh ở đây

Bạn có thể xác định Chính sách từ tam giác đen nhỏ và Chi tiết nhãn . Như bạn có thể thấy, nếu có thêm một người dùng trong adminnhóm, bạn có thể chọn từ danh sách người dùng sẽ sử dụng để xác thực.

Với tất cả những điều này, cả Chính sách sudovà Chính sách đều phức tạp hơn nhiều, liên quan đến các cấu hình có thể đạt được: bạn có thể định cấu hình hành động có thể được thực thi mà không cần mật khẩu, chỉ được thực hiện bởi một người dùng hoặc nhóm cụ thể, v.v.

Đến với câu hỏi của bạn, khi cơ chế được ứng dụng sử dụng là PolicyKit, độc lập với người dùng đã đăng nhập hiện tại, mật khẩu bắt buộc sẽ là của Bob hoặc Alice (hai người dùng quản trị viên duy nhất, nếu tôi hiểu chính xác) và bạn có thể thay đổi từ danh sách người dùng bạn muốn sử dụng để xác thực.

Khi cơ chế được ứng dụng sử dụng là sudo(đối với các tác vụ quản trị viên được thực hiện thông qua GUI, điều này sẽ trở nên ít thường xuyên hơn), bạn không có ý nghĩa đơn giản và ngay lập tức để chọn người dùng để xác thực.


1
Tôi cảm thấy như bây giờ tôi đã hiểu rõ hơn về tình hình. Cảm ơn bạn.
Brighid McDonnell

6

Rõ ràng, sudosẽ là lựa chọn đầu tiên cho tôi trong trường hợp như vậy. Các xuất hiện điểm lớn là hầu hết các quản trị viên (thực tế) không thực sự sử dụng /etc/sudoersđến mức độ có thể tối đa của nó ( User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias).

Hầu hết các quản trị viên cuối cùng chỉ sử dụng một số quy tắc hiện có và thêm người dùng hoặc tệ hơn là chỉ cần thêm người dùng vào sudonhóm mà quy tắc thường tồn tại trên các thiết lập Ubuntu ( %sudo...). Điều này, tất nhiên, cung cấp cho người dùng tương ứng trị vì miễn phí và toàn bộ sức mạnh của tài khoản superuser.

Đưa ra nhận xét của bạn:

vì vậy tôi đã thêm chúng vào /etc/sudoers

Tôi nghĩ bạn cũng không sử dụng nó đến mức có thể.

Trong một kịch bản như của bạn, tôi thực sự sẽ kịch bản một vài hành động mà Bob sẽ bị hạn chế. Thực tế đây là những gì tôi đã làm trên một máy chủ mà tôi duy trì, để cho phép hai người dùng cụ thể khởi động lại một khách KVM cụ thể trên máy chủ. Các tập lệnh sẽ chứa một hashbang có đường dẫn tuyệt đối đến trình thông dịch (ví dụ #!/bin/dashthay vì #!/usr/bin/env bash) và có thể chạy với trình bao được sử dụng ở nơi khác cho các tác vụ đặc quyền ( /bin/dashhoặc /bin/sh). Đó chỉ là những biện pháp phòng ngừa. Ngoài ra, tôi sẽ đảm bảo mã hóa tất cả các đường dẫn tuyệt đối đến nhị phân và sử dụng càng ít càng tốt. Ví dụ: khi sử dụng bash/ dashtôi thích builtins hơn commands (xem man bash). Bạn có thể làm cho điều này có thể duy trì bằng cách chỉ định một biến là đường dẫn tuyệt đối và tham chiếu đến chương trình dựa trên biến đó ($VIRSHthay vì /usr/bin/virsh). Nếu bạn có thể, hãy kiểm tra mã của bất kỳ tập lệnh bên ngoài nào trước khi gọi chúng. Đặc biệt nếu bạn cần gọi họ trong một bối cảnh đặc quyền. Trong trường hợp của tôi, tôi cũng giới hạn người dùng vào một thư mục gốc cụ thể và một hệ thống con SSH cụ thể vì họ chỉ kết nối với máy thông qua sshdvà xác thực khóa chung. Rõ ràng là bạn không cần điều đó.

Hãy chắc chắn để chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>ngăn chặn bất cứ ai nhưng rootthích hợp để mày mò với nó. Cũng phải cẩn thận với setuidsetgidbit nhị phân kích hoạt trên mục tiêu ( findcó thể được sử dụng để phát hiện ra chúng). Hãy giả sử cho thời điểm mà kịch bản của bạn cư trú /usr/sbin/priv-action.

Bây giờ chỉnh sửa của bạn /etc/sudoers. noexeccó thể được sử dụng để ngăn chặn các nhị phân khác ngoài những thứ được cho phép rõ ràng là tốt. Thực tế có rất nhiều cài đặt bổ sung, không chỉ những cài đặt mà tôi đang mô tả ở đây. Vì vậy, hãy chắc chắn để tham khảo ý kiến man sudoers.

Bây giờ tôi thích đặt tên người dùng ( User_Alias) trong sudoerstệp của mình , nhưng bạn cũng có thể sử dụng một Group_Alias( man sudoers) hoặc một nhóm hệ thống thực tế (ví dụ %sudo):

# The list is comma-separated: bob,alice,...
User_Alias      LIMITED_ADMINS=bob

và sau đó thêm một bí danh lệnh để cho phép thực thi tập lệnh cụ thể đó:

# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias      PRIV_ACTION=/usr/sbin/priv-action

Cuối cùng nhưng không kém phần quan trọng là dòng ma thuật cho phép bob(hay đúng hơn là người dùng được liệt kê bên dưới LIMITED_ADMINS) thực thi các lệnh đặc quyền thông qua tập lệnh:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

Không giống như các định nghĩa bí danh trước đó, dòng yêu cầu một lời giải thích. Vì vậy, trước tiên hãy đi sâu vào các phần trên dòng "Thông số người dùng". Ở đây man sudoersgiúp:

Cấu trúc cơ bản của một đặc tả người dùng là who where = (as_whom) what.

Dòng ví dụ (được tìm thấy trên hầu hết các thiết lập Ubuntu):

root    ALL=(ALL) ALL

Điều này nói rằng một người dùng có tên root (sử dụng #0để buộc nó vào UID 0), trên tất cả các máy chủ, có thể chạy trong bất kỳ bối cảnh người dùng nào nhưng sẽ được yêu cầu nhập mật khẩu (giả sử hành vi mặc định). Thêm NOPASSWDthẻ trước cuối cùng ALLsau đó cũng sẽ cho phép rootthực hiện tương tự mà không cần yêu cầu mật khẩu (như vậy root ALL=(ALL) NOPASSWD:ALL:). ALLlà một bí danh ký tự đại diện cho các loại bí danh khác nhau.

Nhưng trở lại với Bob:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

sẽ cho phép bobvà các thành viên được liệt kê khác của User_Alias LIMITED_ADMINSchạy (trên tất cả các máy chủ, đó là những gì ALLdành cho) như người dùng root(nhóm ngụ ý, nhưng có thể được đưa ra, xem man sudoers) các lệnh được đưa ra trong Cmnd_Alias PRIV_ACTION. Nó trở nên tốt hơn. Vẫn giả sử bạn viết tập lệnh này, bạn có thể cho phép các tham số khác nhau, do đó tránh viết nhiều tập lệnh. /etc/sudoerssẵn sàng lấy các ký tự đại diện giống như vỏ sò để hạn chế khả năng tranh luận được phép thông qua.

Tôi luôn thấy rằng các quản trị viên không sử dụng sudoerscách sử dụng nó, đó là lý do tại sao tôi đánh giá cao "Hack" tương ứng từ hai cuốn sách "Linux Server Hacks" và "Linux Server Hacks Volume Two", điều đó đã giúp tôi bắt đầu sử dụng tinh vi hơn của cơ sở tuyệt vời này.

Bạn có thể đưa ra tất cả các loại phức tạp - có thể không chính xác giúp khía cạnh bảo mật - giải pháp cho trường hợp cụ thể của bạn, nhưng một khi bạn nói được từ vựng cơ bản của /etc/sudoersbạn có thể thực hiện những chiến công kỳ diệu :)

Lưu ý: hãy nhớ rằng bạn cũng có thể tạo một tệp mới bên dưới /etc/sudoers.d/nếu bạn cảm thấy quá nghiêng. Điều này giả sử bạn /etc/sudoerschứa dòng:

#includedir /etc/sudoers.d

-1

Chỉ có một siêu người dùng trong Unix / Linux, tên của nó là root, nhưng sudoers là những người dùng có thể trở thành root. Bạn nên sử dụng các nhóm:

newgrp admins

và sau đó chỉ định người dùng cho nhóm đó:

chgrp alice admins

sau đó thêm nhóm quản trị viên vào tệp cấu hình sudoers như nếu nhóm là người dùng.

Cập nhật

Hoặc bạn có thể thêm bất kỳ người dùng nào vào nhóm quản trị viên:

chgrp alice admin

Xin lỗi tôi nhấn phím tab và gửi nó mà không hoàn thành nó.
Francisco Valdez

Nhận xét Zorched dựa trên câu trả lời không đầy đủ. Đang thử câu trả lời hiện tại. Giả sử rằng giải trình thêm là dành cho độc giả tương lai có lẽ ít làm quen với các công việc sysadmin.
Brighid McDonnell

Tất nhiên tôi không có ý định tự phụ, có một trang stackexchange về sysadmin
Francisco Valdez

Tôi biết ServerFault tồn tại. Tôi đang hỏi ở đây vì đây là hành vi dành riêng cho Ubuntu.
Brighid McDonnell

AFAIK : adduser <user>, addgroup <group>adduser <user> <group>là cách ưa thích trên Debian / Ubuntu.
0xC0000022L
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.