Trường hợp sử dụng điển hình cho mật khẩu nhóm


35

Tôi đã kiểm tra trải nghiệm Unix đáng giá hơn nửa thế kỷ và cả đồng nghiệp của tôi cũng như bản thân tôi chưa bao giờ đặt mật khẩu cho một nhóm ( sggpasswd). Điều gì sẽ là một trường hợp sử dụng điển hình cho mật khẩu nhóm hoặc nó chỉ có khá nhiều vì lý do lịch sử?


4
Có lẽ tôi nên gửi cho Ken một email, yêu cầu anh ấy xem xét trong giai đoạn thiết kế; o)
jippie

Câu trả lời:


26

Tôi cũng chưa bao giờ thấy tính năng này được sử dụng, thậm chí không chỉ một lần. Hầu hết SA thậm chí không biết rằng cơ sở này tồn tại. Khi nhìn vào trang người đàn ông gpasswdđã có ghi chú này:

Ghi chú về mật khẩu nhóm

  Group passwords are an inherent security problem since more than one 
  person is permitted to know the password. However, groups are a useful 
  tool for permitting co-operation between different users.

Tại sao chúng tồn tại

Tôi nghĩ rằng chúng là một ý tưởng tự nhiên trong việc bắt chước mô hình người dùng có mật khẩu, rằng việc sao chép mô hình trường hợp sử dụng đó thành các nhóm cũng có ý nghĩa. Nhưng trong thực tế, chúng thực sự không hữu ích cho bất cứ điều gì.

Ý tưởng với mật khẩu nhóm là nếu bạn cần có quyền truy cập vào một nhóm cụ thể (nhóm mà bạn không được liệt kê là thành viên của nhóm), bạn có thể thực hiện bằng cách sử dụng newgrplệnh và được thử thách với mật khẩu để có quyền truy cập cho các nhóm thay thế.

Vấn đề lớn với họ là chỉ có một mật khẩu duy nhất cho mỗi nhóm, do đó buộc mọi người phải chia sẻ mật khẩu duy nhất này, khi nhiều người yêu cầu quyền truy cập vào một nhóm cụ thể này.

Các nhóm

Hầu hết các môi trường tôi gặp đều thường đưa mọi người vào các nhóm thứ cấp và sau đó cấp cho các nhóm này quyền truy cập vào các tệp trên hệ thống tệp và điều này đã đáp ứng khá nhiều tất cả việc sử dụng cần phải xảy ra.

sudo

Với sự ra đời của sudocác quyền bổ sung có thể được trao trên cơ sở cần thiết cho các nhóm, làm suy yếu thêm bất kỳ trường hợp sử dụng nào mà mật khẩu nhóm có thể đã cung cấp. Nếu bạn cần cho phép người dùng nhiều quyền hơn, việc tạo vai trò sẽ dễ dàng hơn nhiều sudovà sau đó chỉ cho phép có tên người dùng hoặc nhóm mà họ tham gia, quyền nâng cao quyền đó để họ có thể thực hiện một tác vụ cụ thể.

ACL

Cuối cùng, khả năng tạo Danh sách điều khiển truy cập (ACL) thực sự mang lại sự linh hoạt cuối cùng mà mô hình quyền Người dùng / Nhóm / Các quyền khác không thể cung cấp một mình, loại bỏ mọi nhu cầu có thể về mật khẩu nhóm bị che khuất.


Bạn đã đề cập sudovà ACL. Tôi đoán udevđi kèm với một câu chuyện tương tự, tất nhiên tập trung vào các thiết bị. Thú vị đọc.
jippie

11

Đây là một cách sử dụng thực tế cho mật khẩu nhóm, mà tôi đã tự triển khai trên máy chủ công việc của chúng tôi, vì các nhật ký cho thấy tài khoản của tôi bị ép buộc (hoặc có thể là một cuộc tấn công từ điển).
Tôi đã sử dụng ssh-keygenputtygentôn trọng để tạo các cặp khóa để sử dụng từ máy trạm và máy tính ở nhà của tôi. Chìa khóa tôi sử dụng từ nhà yêu cầu mật khẩu. Tôi đã thêm cả hai khóa công khai vào .ssh/authorized_keys, tạo một nhóm marionettecó mật khẩu và không có thành viên. Là root tôi đã sử dụng visudođể thêm các dòng sau.

Cmnd_Alias      SUDOING = /bin/bash, /usr/bin/sudo -i
%marionette     ALL=NOPASSWD:SUDOING

Tôi đã vô hiệu hóa mật khẩu tài khoản của mình, bạn không ai có thể đăng nhập theo cách đó. Bây giờ tôi chỉ đăng nhập bằng các khóa của mình và tham gia nhóm được bảo vệ bằng mật khẩu newgrp marionettecho phép tôi trở thành root bằng cách sử dụng sudo -i.
Nếu không có NOPASSWD:tùy chọn, nó sẽ yêu cầu mật khẩu tài khoản người dùng của bạn . Nếu nó bị vô hiệu hóa và nhóm này không có NOPASSWD, bạn sẽ không thể sudo -i. Nó cũng sẽ yêu cầu mật khẩu tài khoản người dùng của bạn nếu danh sách lệnh của bạn không có /bin/bashhoặc bất kỳ shell nào mà root của bạn đang sử dụng theo mặc định.

Trong khi điều này làm cho đường dẫn để sudoing một vài bước dài hơn, nó thêm một lớp bảo mật tốt. Nếu bạn chọn tạo tất cả các tài khoản của mình như thế này, hãy tạo một tài khoản cục bộ bằng mật khẩu và quyền sudo, nhưng từ chối mục nhập ssh từ đó /etc/ssh/sshd_configbằng cách thêm một cái gì đó như:

DenyUsers root caan
DenyGroups root daleks

Điều này là cần thiết cho truy cập cục bộ trong trường hợp bạn cài đặt lại và quên sao lưu các khóa truy cập của bạn.


bạn có thể làm điều này tốt hơn nhiều sudonếu không sử dụng newgrplệnh POSIX . vẫn còn, câu trả lời tuyệt vời
mikeerv

Không chính xác là một câu trả lời cho câu hỏi, nhưng một đề xuất tuyệt vời cho việc sử dụng và kết hợp "cũ" ( newgrp) và "mới" ( sudo) với giá trị gia tăng rõ ràng. Điều này xứng đáng một số danh tiếng.
Dirk

1

Tôi cũng chưa bao giờ thấy trường hợp sử dụng cho mật khẩu đó. Và đó là khoảng 20 năm kinh nghiệm * nix.

Trường hợp sử dụng duy nhất nảy ra trong đầu tôi là đặt nó thành "!" - bị khóa, vì vậy không ai, không phải là thành viên của nhóm đó có thể thay đổi nó bằng newgrplệnh.

Nếu tôi xem xét / etc / group trên SLES hoặc / etc / gshadow trên các hệ thống dựa trên RedHat thì đây dường như là trường hợp sử dụng "điển hình". SLES thậm chí không buồn tạo ra một cơ chế tạo bóng cho mật khẩu đó.


Không chắc chắn những gì bạn có ý nghĩa. Ví dụ. Tôi không thể newgrp ntp, làm thế nào để !thay đổi điều đó?
jippie

@jippie - vậy trường mật khẩu cho ntp trên hệ thống của bạn là gì? Nếu đó là một số mật khẩu dễ đoán, bạn sẽ có thể thực hiện newgrp ntp. Với ! bạn không thể
Nils

Đó chỉ là một ví dụ, nó có 'x' và không có thành viên nhóm nào ngoài chính người dùng ntp. Tôi chỉ không hiểu vấn đề bạn đang giải quyết bằng cách đặt trường mật khẩu thành!
jippie

2
Từ man newgrp: Người dùng sẽ bị từ chối truy cập nếu mật khẩu nhóm trống và người dùng không được liệt kê là thành viên.
user2387 6/10/2015

0

Hãy để tôi đề nghị một trường hợp sử dụng.

Trước tiên hãy để tôi nói rằng chúng ta đã quá quen với thuật ngữ "người dùng" đến nỗi chúng ta thậm chí không nghĩ về nó. Nhưng "người dùng" không thực sự là người dùng . Ví dụ, ở nhà chúng tôi có ba máy tính - máy tính xách tay của vợ tôi, máy tính xách tay của tôi và máy tính để bàn thông thường. Khi tôi sử dụng máy tính xách tay của vợ tôi, tôi đăng nhập bằng tài khoản người dùng của cô ấy. Khi cô ấy sử dụng máy tính xách tay của tôi, cô ấy đăng nhập bằng tài khoản người dùng của tôi. Nếu ai đó cần máy tính để bàn, người đó sẽ sử dụng một tài khoản chung. Chúng ta thấy ở đây, thứ mà hệ thống máy tính gọi là "người dùng" không thực sự là người dùng mà là một quy trình làm việc - một tập hợp các hoạt động.

Đây là câu hỏi: Tại sao tôi không thể có nhiều hơn một hoạt động - một hoạt động cho mọi công việc khác nhau mà tôi có? Tôi có thể. Tại máy tính làm việc của tôi, tôi đã tạo (thử nghiệm) nhiều người dùng khác nhau để tôi có thể tập trung vào nhiệm vụ hiện tại. Tôi đặt tất cả những người dùng này vào cùng một nhóm để tôi có thể truy cập các tệp của mình mà không phải là người dùng mà tôi hiện đang sử dụng.

Vì vậy, gpasswd phù hợp với điều này ở đâu?

Hành vi mặc định của Ubuntu là tạo một nhóm đặc biệt cho mọi người dùng.

Điều gì xảy ra nếu chúng ta quyết định nghĩ về các nhóm chính này với tư cách là người dùng và nghĩ về người dùng hệ thống như quy trình công việc ?

Hơn những người dùng mới này sẽ cần mật khẩu để đăng nhập, phải không? Đây là nơi của gpasswd. Tôi vẫn cần tìm ra cách đăng nhập với nhóm (tính đến thời điểm này, điều tôi biết là bạn có thể chuyển đổi nhóm bằng gpasswd nếu bạn đã đăng nhập).


tuy nhiên, mật khẩu nhóm là toàn bộ vấn đề của câu hỏi này mà bạn chưa giải quyết.
Jeff Schaller

Từ quan điểm bảo mật và trách nhiệm, rất phổ biến trong CNTT, sử dụng tài khoản người dùng của người khác là không thể chấp nhận được. Mặc dù nó có thể làm việc cho tình huống gia đình của bạn, nhưng đó là thực tế xấu cho môi trường công ty.
jippie
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.