Typowy przypadek użycia hasła grupy

Sprawdziłem ponad pół wieku doświadczenia w Uniksie i ani moi koledzy, ani ja nigdy nie ustawiliśmy hasła do grupy ( sgi gpasswd). Jaki byłby typowy przypadek użycia hasła grupowego, czy raczej jest tam tylko z powodów historycznych?

Ja też nigdy nie widziałem tej funkcji, nawet raz. Większość SA nawet nie zdaje sobie sprawy z istnienia tego obiektu. Patrząc na stronę podręcznika, gpasswdbyła tam ta notatka:

Uwagi na temat haseł grupowych

  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.

Dlaczego oni istnieją?

Myślę, że to naturalny pomysł naśladowania modelu posiadania haseł przez użytkownika, że ​​powielanie tego modelu przypadków użycia również dla grup ma sens. Ale w praktyce nie są tak przydatne do niczego.

Pomysł z hasłem grupy polega na tym, że jeśli chcesz uzyskać dostęp do określonej grupy (takiej, której nie wymieniono jako członka), możesz to zrobić za pomocą newgrppolecenia i otrzymać hasło dostępu do tych alternatywnych grup.

Dużym problemem jest to, że dla każdej grupy jest tylko jedno hasło, co zmusza ludzi do udostępniania tego jednego hasła, gdy wiele osób wymaga dostępu do tej konkretnej grupy.

Grupy

Większość środowisk, z którymi się spotkałem, zazwyczaj umieszcza ludzi w grupach drugorzędnych, a następnie daje tym grupom dostęp do plików w systemie plików, co zaspokoi prawie całe użycie, które musi nastąpić.

sudo

Wraz z nadejściem sudododatkowych uprawnień można by w razie potrzeby przekazywać grupom, co dodatkowo podważa wszelkie przypadki użycia, które mogły podać hasła grupy. Jeśli trzeba było zezwolić użytkownikom na więcej uprawnień, znacznie łatwiej było utworzyć role, sudoa następnie po prostu zezwolić na nazwę użytkownika lub grupę, w której się znajdowali, uprawnienia na podniesienie uprawnień, aby mogli wykonać określone zadanie.

ACL

Wreszcie możliwość tworzenia list kontroli dostępu (ACL) naprawdę dawała ostatnią odrobinę elastyczności, której model uprawnień Użytkownik / Grupa / Inne nie był w stanie zapewnić sam, przenosząc wszelką potrzebę hasła grupy do zapomnienia.

Oto praktyczne zastosowanie dla haseł grupowych, które zaimplementowałem dla siebie na naszym serwerze roboczym, ponieważ dzienniki wskazały, że moje konto zostało brutalnie wymuszone (lub mogło być atakiem słownikowym).
Użyłem ssh-keygeniz puttygenszacunkiem wygenerowałem pary kluczy do użycia ze stacji roboczej i komputera domowego. Klucz, którego używam z domu, wymaga hasła. Dodałem oba klucze publiczne do .ssh/authorized_keys, utworzyłem grupę marionettez hasłem i nie ma członków. Jako root visudododałem następujące wiersze.

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

Wyłączyłem hasło do mojego konta, nikt nie może się do niego zalogować w ten sposób. Teraz loguję się tylko za pomocą moich kluczy i wchodząc w grupę chronioną hasłem za pomocą newgrp marionettepozwala mi na rootowanie sudo -i.
Bez tej NOPASSWD:opcji będzie to wymagać hasła do konta użytkownika. Jeśli jest wyłączona, a ta grupa nie ma NOPASSWD, nie będziesz w stanie tego zrobić sudo -i. Wymagane będzie również hasło do konta użytkownika, jeśli lista poleceń nie ma /bin/bashdomyślnej powłoki używanej przez użytkownika root.

Chociaż powoduje to, że ścieżka do sudo jest o kilka kroków dłuższa, dodaje dobrą warstwę bezpieczeństwa. Jeśli zdecydujesz się na utworzenie wszystkich takich kont, utwórz jedno konto lokalne z hasłem i uprawnieniami sudo, ale nie zezwalaj na wpis ssh /etc/ssh/sshd_config, dodając coś takiego:

DenyUsers root caan
DenyGroups root daleks

Jest to konieczne w przypadku lokalnego dostępu na wypadek ponownej instalacji i zapomnienia kopii zapasowej kluczy dostępu.

Nigdy też nie widziałem przypadku użycia tego hasła. A to około 20 lat * doświadczenia Nix.

Jedyny przypadek, jaki przychodzi mi do głowy, to ustawienie go na „!” - zablokowane, więc nikt, nie będąc członkiem tej grupy, nie może zmienić na nią newgrpkomendy.

Jeśli zajrzę do / etc / group na SLES lub / etc / gshadow w systemach opartych na RedHat, wydaje się, że jest to „typowy” przypadek użycia. SLES nawet nie zadał sobie trudu stworzenia mechanizmu cienia dla tego hasła.

Pozwól, że zasugeruję przypadek użycia.

Najpierw powiem, że jesteśmy tak przyzwyczajeni do terminu „użytkownik”, że nawet o tym nie myślimy. Ale „użytkownik” tak naprawdę nie jest użytkownikiem . Na przykład w domu mamy trzy komputery - laptop mojej żony, mój laptop i wspólny komputer stacjonarny. Kiedy korzystam z laptopa mojej żony, loguję się na jej konto użytkownika. Kiedy używa mojego laptopa, loguje się na moje konto użytkownika. Jeśli ktoś potrzebuje pulpitu, korzysta z jednego wspólnego konta. Widzimy tutaj, że rzecz, którą system komputerowy nazywa „użytkownikiem”, nie jest tak naprawdę użytkownikiem, ale przepływem pracy - zestawem działań.

Oto pytanie: Dlaczego nie mogę mieć więcej niż jednego działania - jednego dla każdej innej pracy, którą mam? Mogę. Na moim komputerze roboczym stworzyłem (eksperymentalnie) wielu różnych użytkowników, dzięki czemu mogę skupić się na bieżącym zadaniu. Umieszczam wszystkich tych użytkowników w tej samej grupie, dzięki czemu mogę uzyskać dostęp do moich plików bez względu na to, jakiego użytkownika aktualnie używam.

Gdzie więc pasuje do tego gpasswd?

Domyślne zachowanie Ubuntu polega na utworzeniu specjalnej grupy dla każdego użytkownika.

Co się stanie, jeśli zdecydujemy się myśleć o tych grupach podstawowych jako użytkownikach, a użytkowników systemu - o przepływach pracy ?

Niż ci nowi użytkownicy potrzebowaliby hasła do logowania, prawda? Oto miejsce gpasswd. Nadal muszę wymyślić, jak zalogować się do grupy (do tego momentu wiem, że możesz przełączać grupy za pomocą gpasswd, jeśli jesteś już zalogowany).