Przechowywanie użytkowników w ich katalogu domowym


-1

Mam nową instalację CentOS i aktualnie konfiguruję użytkowników. Ich domowe katalogi znajdują się wewnątrz /home/username/ i chcę sprawić, żeby nie mogły ls lub cd poza tym obszarem, gdy używają openSSH, SFTP itp.

Czytałem przez chroot dokumentacji i nie mogę sprawić, żeby działało. Wszelkie pomysły i pomoc będą mile widziane.


Nie temat tutaj. Ale dlaczego chcesz zabronić użytkownikom odczytywania plików od innych osób (np. Z katalogu domowego osób z tej samej grupy, chętnych do udostępnienia)? I dlaczego użytkownicy nie mogli wyświetlić listy, np. pliki wewnątrz /usr/bin lub inne katalogi systemowe?
Basile Starynkevitch

2
Jeśli użyjesz chroot w ten sposób wszystko, czego potrzebuje użytkownik (pliki wykonywalne, biblioteki itp.) musi znajdować się wewnątrz chroot ed katalog. Widziałem skonfigurowane w ten sposób serwery ftp, ze statycznymi plikami wykonywalnymi skopiowanymi do pliku bin informator. Ther musi działać /devi prawdopodobnie wiele innych rzeczy, o których nie myślałem. Szczerze mówiąc, cały pomysł wydaje się masowym przesadą. Dlaczego system ma być tak mocno zamknięty i dlaczego zwykłe zabezpieczenia Linuksa nie wystarczą?
Keith Thompson

@Basile i Keith Przyczyną uniemożliwienia każdemu użytkownikowi czytania innych plików użytkownika jest to, że niektórzy użytkownicy mają swoje własne pliki "config.php", które zawierają poufne informacje, podczas gdy niektórzy użytkownicy nie lubią pomysłów innych, którzy mogą zobaczyć strukturę plików i źródło kod ich systemów zarządzania treścią, dlatego próbuję stworzyć system, w którym użytkownik ma dostęp do swojego katalogu domowego jako folderu najwyższego poziomu. To znaczy. nie można "cd /" i zobaczyć plików innych osób ani folderów systemowych. Zgaduję z komentarzy, że nie jest to takie proste. Mimo wszystko, dziękuję za twoją pomoc.
Undefined

1
Ci użytkownicy powinni chmod go-rwx ich poufne pliki.
Basile Starynkevitch

Sprawdź podobne pytanie w witrynie Server Fault: "Ogranicz użytkowników Linuksa do plików, które posiada" .
Cristian Ciupitu

Odpowiedzi:


0

Rozwiązaniem może być użycie powłoki ograniczonej bash. Pamiętaj jednak, aby zezwolić na wykonywanie tylko bezpiecznych poleceń z tej powłoki. Przykład: jeśli less jest dozwolone, użytkownik może opuścić zastrzeżoną powłokę za pomocą ! dowództwo. Aby tego uniknąć, ustaw opcję LESSSECURE zmienna środowiskowa na 1.


Jestem sceptycznie nastawiony, że możesz się zablokować wszystko "niebezpieczne" polecenia w zależności od przypadku. A to przeszkadza użytkownikowi w rozbrajaniu $LESSSECURE?
Keith Thompson

Uniemożliwienie użytkownikowi wyzerowania zmiennej jest łatwe: wyłącz opcję export wbudowany w enable -n export. I z kontrolą do PATH, możliwe jest zablokowanie wykonywania tylko niektórych poleceń. Nie jest w 100% kuloodporny, ale może łatwo ograniczyć 98% niepożądanego dostępu.
jfg956

Dzięki za opinie, myślę, że dam ci tę ideę, ponieważ wydaje się zbyt skomplikowana i niebezpieczna.
Undefined

@jfgagne Bez problemu. export LESSSECURE=1 następnie enable -n export następnie less /etc/passwd, całkiem dobrze ! daje "Polecenie niedostępne". Jednak, LESSSECURE="" less /etc/passwd czyni ! dostępne i dość zdolne do wpuszczenia mnie w skorupę, gdzie nawet export jest dostępny.
a CVn

0

Przyczyną uniemożliwienia każdemu użytkownikowi odczytania innych plików użytkownika jest to niektórzy użytkownicy mają własne pliki "config.php", które zawierają poufne informacje, podczas gdy niektórzy użytkownicy nie lubią pomysłów innych, którzy mogą zobaczyć strukturę plików i kod źródłowy swoich systemów zarządzania treścią, dlatego próbuję stworzyć system, w którym użytkownik ma dostęp do swojego katalogu domowego jako folderu najwyższego poziomu. To znaczy. nie można "cd /" i zobaczyć plików innych osób ani folderów systemowych. Zgaduję z komentarzy, że nie jest to takie proste.

W przeciwieństwie do stwierdzenia problemu w samym pytaniu, w rzeczywistości jest to rozsądne rozpuszczalny problem. Poniżej jest jeden możliwość rozwiązania tego problemu.

Po pierwsze, uczyń każdy katalog domowy dostępny tylko dla jego właściciela i nikogo innego. Innymi słowy, tryb 0700.

Po drugie, ustaw wartość umask użytkownika na 0077. Oznacza to, że domyślnie pliki będą tworzone z bitami praw grupy i świata ustawionymi na zero, pozwalając tylko na dostęp właściciela.

Jeśli dany plik musi być dostępny w jakimś innym procesie (jest to plik .php, więc może serwer WWW?), Nadaj temu procesowi własne członkostwo w grupie, ustaw własność grupową w katalogach domowych do tej grupy i ustaw tryb do 0710. Bit "execute" w katalogu umożliwia dostęp, jeśli zna się konkretną nazwę podkatalogu lub pliku, do którego dostęp jest pożądany, ale nie pozwala na wpisanie zawartości katalogu (to jest "przeczytane" w katalogu).

Wszelkie podkatalogi w katalogach domowych użytkowników, które powinny być dostępne dla tego samego procesu, mogą mieć względnie permisywne bity uprawnień światowych. (Na przykład pliki 0644 i katalogi 0755 lub 0751.)

Jeśli jest to pożądane, daj użytkownikom obszar "udziału", być może poza ich katalogami domowymi, który ma bardziej permisywny zestaw uprawnień. Może dla każdego użytkownika ma / home / $ USER i / share / $ USER, gdzie katalog under / share ma 0755 uprawnień i jest własnością odpowiedniego użytkownika. Ewentualnie dodaj dowiązanie symboliczne w katalogu domowym użytkownika wskazujące na katalog "share" i powiedz im, że pliki udostępnione innych użytkowników znajdują się w / share / $ USER. Jeśli wybierasz tę trasę, możesz zamiast tego użyć umask 0022, która będzie domyślnymi plikami, które będą tylko do odczytu przez osoby nie będące właścicielami. Pamiętaj, aby poinformować użytkowników, że pliki, które przechowują w katalogu / share, mogą być odczytywane przez wszystkich użytkowników systemu.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.