🚀 go-pugleaf

On 2024-11-30, Jarosław Sokołowski <jaros@lasek.waw.pl> wrote:
> Pan Marcin Debowski napisał:
>
>>> Zatem, jeśli w systemie jest dwóch albo i więcej uprawnionych do sudo 
>>> użytkowników (np. w firmie 24h na 3 zmiany) to prawdopodobieństwo 
>>> atakującego wzrasta proporcjonalnie do liczby uprawnionych, dając mu 
>>> tyle razy większe szanse przechwycenia hasła uprawnionego administratora 
>>> ilu uprawnionych np. poprzez jakąkolwiek inwigilację któregokolwiek z nich.
>
> Nic z tych rzeczy. Jak to ma być poważny serwer, to i tak ma wszystkie
> hasła zablokowane. Logowanie kluczem z innego komputera (który jeśli
> nawet jest wystawiony w Internecie, to w sposób ograniczony, a do tego
> bad guyowi trudno odgadnąć, który to).

To nie musi być poważny serwer. Moje wszystkie śmieszne serwery tak 
właśnie mają. To jest raczej standardowa praktyka. Ale przy 
n-uzytkownikach zdecydowanie wzrasta szansa uzyskania dostępu, bo na 
konsoli czy wewnątrz firmy to nadal może być hasło. Gdzieś, na jakimś 
poziomie nie jest to interakcja wyłącznie maszyna-maszyna. 

>> Nie widzę większego sensu w używaniu sudo jeśli jest 2ch lub więcej 
>> administratorów (doświadczonych) z pełnym prawem dostępu. Sens może
>> być, jeśli mamy konieczność wykonywania tylko wybranych poleceń, przez 
>> wybranych użytkowników, na prawach roota.
>
> Jest dokładnie odwrotnie. Gdy administrator jest jeden, to do nikogo
> o nic nie może mieć pretensji i robi jak uważa. Gdy jest ich więcej,
> to warto znać historię logowań każdego z nich.

Bez bicia informuję, że nie pracowałem nigdy na nieco bardziej ludnym 
serwerze z kilkoma adminami, ale co to miałoby dać? Jak ktoś robi coś 
złego to na prawach roota ma zwykle wystarczające środki aby zatrzeć za 
sobą ślady lub uniemożliwić własną identyfikacje. A jeśli tym innym 
osobom ufamy, i są one profesjonalne, to poinformują nas co robiły, mogą 
być jakieś dzienniki, etc. A jak to jest jakaś infrastruktura krytyczna, 
np. dla firmy, to z lekka dziwne byłoby opierać bezpieczeństwo na 
znajomości historii logowań i sudo. Zresztą w kwestii samej 
identyfikacji, dostęp nie musi być przecież po jednym kluczu, więc i 
identyfikacja może być na poziomie klucza, a nie użytkownia, który 
zrobił sudo.

Nb. chyba w tym watku nie wspomniano, z pradawnych czasów pamiętam też 
pomysły tworzenia dodatkowych użytkowników z uid 0.

>> taki użytkownik działając na powłoce z pełnym dostępem, w którymś
>> momencie się zapomni i narobi szkód.
>
> Określenie SOA#1 (standardowa odpowiedź administratora numer 1: u mnie
> działa) skądś się wzięło. Łatwo coś tak spartaczyć, że działa dla 0:0,
> a dla innych użytkowników niebardzo. Działanie z uprawnieniami 0:0 jest
> po prostu niepraktyczne.

Czym się ta niepraktyczność manifestuje? 

-- 
Marcin