Ogranicz użytkownika systemu Linux do plików, które posiada

Wyobraź sobie konfigurację serwera współdzielonej firmy hostingowej, w której wielu (~ 100) klientów ma dostęp shellowy do jednego serwera.

Wiele internetowych „programów” zaleca pliki chmod 0777 . Niepokoi mnie to, że nasi klienci nierozsądnie postępują zgodnie z tymi samouczkami, otwierając swoje pliki przed innymi naszymi klientami. (Z pewnością sam nie używam cmod 0777niepotrzebnie!) Czy istnieje sposób, aby upewnić się, że klienci mają dostęp tylko do własnych plików i uniemożliwiają im dostęp do plików czytelnych dla świata od innych użytkowników?

Zajrzałem do AppArmor , ale jest to bardzo ściśle powiązane z procesem, który wydaje się zawodzić w tym środowisku.

Umieść ograniczony i niezmienny katalog między światem zewnętrznym a chronionymi plikami, np

/
 ├─ bin
 ├─ home
 │  └─ joe <===== restricted and immutable
 │     └─ joe <== regular home directory

lub /home/joe/restricted/public_html.

Ograniczony oznacza, że ​​tylko użytkownik i być może serwer sieciowy może go odczytać (np. Tryby 0700/ 0750lub niektóre listy ACL ).

Niezmienność można wykonać za pomocą chattr +ilub poprzez zmianę własności na coś podobnego root:joe.

Łatwym sposobem na utworzenie tej hierarchii na Ubuntu byłoby edytowanie /etc/adduser.confi ustawienie GROUPHOMESna yes.

Istnieje opcja, którą możesz rozważyć (w zależności od tego, ile pracy chcesz w tym celu wykonać).

Jak już napisali inni, „normalnie” nie można uniemożliwić komuś z dostępem do powłoki dostępu do plików do odczytu.

Jednak możesz chrootować je do ich własnego domu, po prostu ograniczając dostęp do powłoki, po pierwsze, tylko do katalogu głównego, który chcesz (AKA katalog domowy), a po drugie, uniemożliwić użytkownikom wykonywanie wszystkiego, czego nie chcą.

Podjąłem podobne podejście, gdy miałem jednego użytkownika, aby mieć dostęp do plików internetowych, ale nie chciałem, aby widział inne pliki poza folderem internetowym.

Miało to duży narzut, było bałaganem w konfiguracji i za każdym razem, gdy coś aktualizowałem, zrywało się.

Ale na dziś myślę, że można to osiągnąć dość łatwo dzięki opcji chroot OpenSSH :

WikiBooks OpenSSH

Odkryłem, że listy kontroli dostępu POSIX pozwalają, jako administrator systemu, chronić użytkowników przed najgorszym ich niewiedzą, zastępując zwykłe uprawnienia systemu plików grupy użytkowników, bez dużej szansy na złamanie czegoś kluczowego .

Mogą być szczególnie przydatne, jeśli na przykład (fi) potrzebujesz, aby katalogi domowe były dostępne na całym świecie, ponieważ zawartość WWW musi być dostępna dla apache ~/public_html/. (Chociaż za pomocą list ACL można teraz zrobić odwrotnie, usunąć dostęp dla wszystkich i użyć konkretnej skutecznej listy ACL dla użytkownika apache).

Tak, znający się na rzeczy użytkownik może je ponownie usunąć / zastąpić, są po prostu tak rzadkie, że jest to mało prawdopodobne, a ci użytkownicy, którzy zazwyczaj nie są tymi, którzy chmod -R 777 ~/tak wygodnie, tak?

Musisz zamontować system plików z aclopcją zamontowania:

 mount -o remount,acl /home

W wielu dystrybucjach domyślnie jest tworzenie grup użytkowników, każdy użytkownik ma swoją grupę podstawową, a ja ustawiłem wszystkich użytkowników w grupie dodatkowej o niewyobrażalnej nazwie users.

Korzystanie z list ACL jest teraz trywialne, aby uniemożliwić innym użytkownikom dostęp do katalogów domowych:

Przed:

 chmod 0777 /home/user* 

 ls -l /home/user*
 drwxrwxrwx.  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx.  2 user2  user2  4096 Jul 11 15:24 user2

Teraz ustaw efektywne uprawnienia do katalogu dla członków usersgrupy na 0brak odczytu, zapisu i dostępu:

 setfacl setfacl -m g:users:0 /home/user*

 ls -l 
 drwxrwxrwx+  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx+  2 user2  user2  4096 Jul 11 15:24 user2

+Znak oznacza obecność tam ustawienia ACL. I getfaclmoże potwierdzić, że:

getfacl /home/user1
getfacl: Removing leading '/' from absolute path names
# file: home/user1
# owner: user1
# group: user1
user::rwx
group::rwx
group:users:---
mask::rwx
other::rwx

group:users:---Pokazują, że grupa skutecznie bez prawa dostępu, pomimo regularnych uprawnień dla drugiej istotyother::rwx

I testowanie jako użytkownik1:

[user1@access ~]$ ls -la /home/user2
ls: cannot open directory /home/user2: Permission denied

Drugim powszechnym rozwiązaniem w systemach współdzielonych jest posiadanie na żądanie automountera katalogów domowych montowanych na żądanie i serwera dedykowanego do dostępu do powłoki. To nie jest głupi dowód, ale zazwyczaj tylko garstka użytkowników będzie zalogowana jednocześnie, co oznacza, że ​​tylko katalogi domowe tych użytkowników są widoczne i dostępne.

Linux Containers (LXC) może być najlepszą kombinacją chroot i osobnego systemu.

1. Są bardziej jak zaawansowany chroot, a nie wirtualizacja, ale można łączyć różne systemy operacyjne na jednym serwerze.

2. Możesz dać użytkownikowi kompletny system operacyjny i tam go zrootować, więc gdy się zaloguje, idzie do swojego kontenera. Możesz także ograniczyć użycie procesora i pamięci.

Stéphane Graber, autor LXC, ma fajny samouczek, który pomoże Ci zacząć.

Na przykład, jeśli chcesz, aby użytkownik miał dostęp tylko do własnego homekatalogu, powinieneś:

cd /home
sudo chmod 700 *

Teraz /home/usernamejest widoczny tylko dla właściciela. Aby /etc/adduser.confustawić tę opcję jako domyślną dla wszystkich nowych użytkowników, edytuj i ustaw DIR_MODEna 0700zamiast0755 domyślnej.

Oczywiście, jeśli chcesz zmienić domyślny DIR_MODE, zależy to od twojej dystrybucji, na której opublikowałem Ubuntu .

edytować

Jak poprawnie wspomniano @Dani_l , ta odpowiedź jest poprawna, ponieważ NIE są one czytelne dla świata.

Po prostu pedantyczny - Nie, nie ma.
@Marek udzielił poprawnej odpowiedzi , ale twoje pytanie jest niepoprawne - nie możesz uniemożliwić dostępu do plików „czytelnych dla świata”.
Albo są czytelne na całym świecie, albo nie. @ Odpowiedź Marka jest poprawna, aby NIE były czytelne dla świata.

W podanych dotychczas odpowiedziach nie widzę wzmianki o „ograniczonej powłoce”.

ln / bin / bash / bin / rbash

Ustaw to jako powłokę logowania.

Jeśli serwer WWW działa jako ten sam użytkownik i grupa dla każdej hostowanej domeny, trudno jest (jeśli nie niemożliwe) zabezpieczyć konfigurację.

Chcesz, aby niektóre pliki były dostępne dla użytkownika i serwera WWW, ale nie dla innych użytkowników. Ale gdy tylko serwer WWW będzie mógł uzyskać do nich dostęp, inny użytkownik może je odczytać, umieszczając dowiązanie symboliczne do pliku na swojej stronie internetowej.

Jeśli możesz uruchomić każdą witrynę jako osobny użytkownik, stanie się to dość proste. Każdy klient będzie teraz miał dwóch użytkowników w systemie, jednego dla serwera WWW i jednego dla dostępu do powłoki.

Utwórz grupę zawierającą tych dwóch użytkowników. Teraz utwórz katalog z tą grupą i rootem użytkownika. Ten katalog powinien mieć uprawnienia 750, co oznacza, że ​​root ma pełny dostęp, a grupa ma dostęp do odczytu i wykonywania. W tym katalogu możesz utworzyć katalogi domowe dla każdego z dwóch użytkowników. Oznacza to, że katalog domowy użytkownika nie będzie już miał formy /home/username, ale coś z co najmniej jednym dodatkowym składnikiem katalogu. To nie jest problem, nic nie wymaga nazywania katalogów domowych zgodnie z tą konkretną konwencją.

Uruchomienie stron internetowych z różnymi użytkownikami i grupami może być trudne, jeśli używasz vhostów opartych na nazwach. Jeśli okaże się, że separacja może działać tylko z vhostami opartymi na IP i nie masz wystarczającej liczby adresów IP dla każdej witryny, możesz hostować każdą witrynę pod adresem IPv6 i umieścić odwrotne proxy dla wszystkich z nich na Adres IPv4.