Ograniczenia użytkowników na Ubuntu Server

[pietrek]

Witam wszystkich,
To mój pierwszy post na forum.
Na codzień jestem użytkownikiem minta. System sprawuje się dobrze. Większych problemów nie mam.
Ale na stare lata (50+) zachciało mi się poszerzyć wiedzę. Postawiłem na VitualBoxie Ubuntu server. Działa SSH i FTP.
Mogę się do niego logować z innych kompów w mieszkaniu, z innym systemem (Win10), z telefonu. Oczywiście po ssh.
Teraz zasadnicze na obecną chwilę pytanie.
Jak szybko ograniczyć prawa użytkownika np.:"tester" w taki sposób, żeby nie mógł on "biegać" po sytemie gdy jest zalogowany po SSH np.?
Żeby mógł poruszać się tylko i wyłącznie po katalogu /home/tester, i tam robić co che.
Przyznam że trochę się gubię w tych prawach dostępu.
Dodam, że wspomniany server jest bez środowiska graficznego. Konsoli się nie boję.
Pozdrawiam

[mario_7]

Chcesz dać dostęp jakiemuś użytkownikowi do powłoki, ale żeby nie mógł wychodzić poza dany katalog?
To takie trochę zaprzeczenie - użytkownik musi móc uruchamiać programy (choćby powłokę), ale z drugiej strony nie może wyjść poza swój katalog...
Niemniej coś w tym stylu mógłbyś osiągnąć przez chroot - poczytaj o tym.

Chyba że chodzi o samo kopiowanie plików przez SFTP - to da się załatwić przez odpowiednią konfigurację serwera SSH.

[jacekalex]

Chroot to nie jest prawdziwe zabezpieczenie, jest kilka sposobów na wyskoczenie z chroota, a tak się składa, że kernel w Ubuntu nie ma Grsecurity z funkcjami chroot_protect, które chronią przed najpopularniejszymi atakami na chroot .

Klatkę dla usera można skuteczniej zrobić tworząc np profil Apparmora dla powłoki usera.
http://blog.corporatism.org/RestrictedShellWithAppArmor

Zasoby systemowe najlepiej limitować przez Cgroup.

[pietrek]

Witam,
Dziękuję za odpowiedzi.
mario_7 - Tak, chodziło mi o to aby użytkownik zalogowany do servera mógł przeglądać tylko swój katalog /home. Szczerze mówiąc myślałem że to jest nie takie trudne.
Może mi wytłumacz, dlaczego uzytkownik nie mógłby uruchamiać żadnych programów, jednocześnie nie mógłby oglądać katalogów które nie należą do niego?
Wczoraj zalogowałem się do servera jako tester. Tester należy tylko i wyłącznie do grupy tester. Dlaczogo mogłem bez żadnego problemu wejść do katalogu użytkownika piotr, i swobodnie przeglądać jego zawartość, włącznie z plikami tekstowymi? Wydaje mi się że skoro tester jest tylko w grupie tester, nie powinien mieć takich możliwości.
Ale ja jestem początkujący w te klocki i oczywiście nie wiele rozumiem.
Próbuje pojąć o co chodzi z tym chrootem.

jacekalex - Twoja odpowiedź świadczy o ogromnej wiedzy. Dla mnie to co piszesz jest chyba na tym etapie zbyt trudne. Ale dziękuję serdecznie za każdą pomoc.

Pozdrawiam

[mario_7]

W wielkim skrócie:
Dla każdego pliku w systemie ustawione są jakieś prawa dostępu. Podstawowe to prawo do odczytu, zapisu i uruchamiania. Dalej określa się jak takie prawa są ustawione dla właściciela pliku, grupy przypisanej do pliku i dla pozostałych użytkowników. Pomijając jak ustawia się domyślne prawa dostępu do plików (to da się konfigurować) to zazwyczaj w katalogu domowym pliki mają domyślnie ustawienia pozwalające na odczyt i zapis dla właściciela i grupy oraz odczyt dla wszystkich pozostałych.
Stąd użytkownik tester mógł przeglądać inne pliki, bo miały ustawiony dostęp dla wszystkich.
Polecam zapoznać się z tym artykułem: http://ubuntu.pl/czytelnia/2011/03/02/k ... a-dostepu/

Co do wytłumaczenia dlaczego ograniczenie dostępu do katalogu domowego użytkownika niesie ze sobą konsekwencje...
Gdyby użytkownik mógł przeglądać jedynie pliki w /home/użytkownik, to jak mógłby uruchomić np. powłokę, która jest w katalogu /bin/?
Jak programy mogłyby ładować ustawienia, które są często zapisane w /etc/?
Jak użytkownik mógłby korzystać z różnych zasobów systemowych znajdujących się w katalogach /dev/, /proc/, /sys/, i innych?
Jak sam widzisz - to nie takie proste... W dodatku zwykłe uprawnienia dostępów są niewystarczające aby skonfigurować tak szczegółowy dostęp (per użytkownik) w systemie.

I tutaj faktycznie pojawiają się rozwiązania jak AppArmor, SELinux lub SMACK - korzystają one z rozszerzonych uprawnień dostępów, dochodzi tam mechanizm etykiet, określanie dostępu nie tylko z poziomu użytkownika, ale także z poziomu procesu. I to już pozwala na dokładniejsze określenie kto, co i gdzie może robić.
Ale... Przygotowanie takiej polityki, która byłaby w pełni odporna jest trochę problematyczne - należałoby określić ustawienia dla każdego pliku i procesu w systemie.
To, co podlinkował jacekalex jest rozwiązaniem dosyć ogólnym, acz pewnie skutecznym w stopniu, który może cię zadowolić.

[jacekalex]

To, co podlinkował jacekalex jest rozwiązaniem dosyć ogólnym, acz pewnie skutecznym w stopniu, który może cię zadowolić.

Nie takim ogólnym.

Apparmora można dowolnie konfigurować, składnia profili jest bardzo prosta (chociaż ilość dostępnych opcji wygląda strasznie):
http://wiki.apparmor.net/index.php/AppA ... _Reference
Należy jednak pamiętać, że narzędzia do obsługi Apparmora zatrzymały się na poziomie Apparmora 2.4,
także nie wszystkie funkcje z Apparmora 2.5 - 3.0 będą działały.

Jest też możliwość stworzenia polityki globalnej, czyli objęcie profilem AA programu /sbin/init (profile Apparmora trzeba wtedy wczytać przez initramfs).
http://wiki.apparmor.net/index.php/FullSystemPolicy

Wtedy można łatwo zrobić klatkę dla całego systemu, i kontrolować w ten sposób wszystko, co się w nim dzieje.

Jest też możliwość objęcia pacjenta Apparmorem w momencie zalogowania przez PAM - modułem pam_apparmor:
http://wiki.apparmor.net/index.php/Pam_apparmor_example

Zabawy jest z tym dużo (może nawet aż 30% tego, co z SELinuxem), ale nie nazwałbym tego ogólnym rozwiązaniem.

System może być tylko tak bezpieczny, jak administrator systemu kumaty i pracowity, to jest sprawa podstawowa.


Pozdro

[mario_7]

Nie napisałem, że AppArmor jest rozwiązaniem ogólnym.
Ten konkretny przykład, który podałeś jest dosyć ogólny.
W samym AppArmor możesz skonfigurować wiele szczegółów, ale w tamtym poradniku tego nie było.

[jacekalex]

Tamten poradnik powstał w czasie, jak Apparmor jeszcze nie miał opcji Full System Policy ani biblioteki PAM.