Daj użytkownikowi dostęp do odczytu / zapisu tylko do jednego katalogu

Korzystam z serwera i muszę przyznać dostęp do odczytu / zapisu do konkretnego katalogu jednemu użytkownikowi. Próbowałem następujące:

sudo adduser abcd
sudo groupadd abcdefg
chown -R .abcdefg /var/www/allowfolder
chmod -R g+rw /var/www/allowfolder
usermod -a -G comments abcd

Powyższe wydaje się działać, ale daje użytkownikowi dostęp tylko do odczytu do reszty serwera.

Jak skonfigurować uprawnienia, aby użytkownik mógł tylko czytać i zapisywać w określonym folderze? Użytkownik powinien również mieć możliwość uruchamiania programów takich jak mysql.

permissions files account-restrictions

— Manishearth
źródło

Krótka odpowiedź: użyj chroota.

— Chris Down,

@Chris Chcesz wyjaśnić to w odpowiedzi? Manish i ja borykamy się z tym i wydaje się, że nie mogę tego zrobić.

— Cofnij

Gdzie byłby mysqlzlokalizowany program? Użytkownik musi być w stanie go odczytać oraz wszystkich potrzebnych bibliotek i plików danych.

— Gilles 'SO - przestań być zły'

@Gilles Hmm. Jest to standardowa instalacja mysql z apt-get, o ile mogę stwierdzić (nie mój system, to Cofnij).

— Manishearth,

Odpowiedzi:

Ujemne listy ACL

Możesz uniemożliwić użytkownikowi dostęp do niektórych części systemu plików, ustawiając listy kontroli dostępu . Na przykład, aby upewnić się, że użytkownik abcdnie może uzyskać dostępu do żadnego pliku w /home:

setfacl -m user:abcd:0 /home

To podejście jest proste, ale musisz pamiętać, aby zablokować dostęp do wszystkiego, do czego nie chcesz abcdmieć dostępu.

Chroot

Aby uzyskać pozytywną kontrolę nad tym, co abcdmożna zobaczyć, skonfiguruj chroot , tj. Ogranicz użytkownika do poddrzewa systemu plików.

Musisz wykonać wszystkie pliki, których potrzebuje użytkownik (np. mysqlI wszystkie jego zależności, jeśli chcesz, aby użytkownik mógł uruchomić mysql) w chroocie. Powiedz, że ścieżka do chroot jest /home/restricted/abcd; mysqlprogram musi być dostępny pod /home/restricted/abcd. Dowiązanie symboliczne wskazujące poza chrootem nie jest dobre, ponieważ na dowiązanie symboliczne ma wpływ więzienie chroot. Pod Linuksem możesz dobrze wykorzystać montowania opraw:

mount --rbind /bin /home/restricted/abcd/bin
mount --rbind /dev /home/restricted/abcd/dev
mount --rbind /etc /home/restricted/abcd/dev
mount --rbind /lib /home/restricted/abcd/lib
mount --rbind /proc /home/restricted/abcd/proc
mount --rbind /sbin /home/restricted/abcd/sbin
mount --rbind /sys /home/restricted/abcd/sys
mount --rbind /usr /home/restricted/abcd/usr

Możesz także kopiować pliki (ale wtedy musisz zadbać o ich aktualność).

Aby ograniczyć użytkownika do chroot, dodaj ChrootDirectorydyrektywę do /etc/sshd_config.

Match User abcd
    ChrootDirectory /home/restricted/abcd

Możesz to przetestować za pomocą: chroot --userspec=abcd /home/restricted/abcd/ /bin/bash

Ramy bezpieczeństwa

Możesz także użyć struktur bezpieczeństwa, takich jak SELinux lub AppArmor. W obu przypadkach musisz napisać dość delikatną konfigurację, aby upewnić się, że nie pozostawiasz żadnych dziur.

— Gilles „SO- przestań być zły”
źródło

Czy o wiele łatwiejszym sposobem nadawania uprawnień do odczytu i zapisu do określonego katalogu jest tworzenie grup? Na przykład mógł utworzyć nową grupę i użyć chown, aby właściciel grupy katalogów był grupą, która została utworzona, i dodać użytkownika do grupy. Na koniec daj katalogowi uprawnienia do odczytu i zapisu do grup.

— Qasim

@Qasim To wymaga, aby wszystkie pliki miały swoje uprawnienia i prawa własności ustawione zgodnie z potrzebami. Jest tak wiele rzeczy, które mogą pójść nie tak (pliki skopiowane z innego miejsca lub wyodrębnione z archiwum z zachowanymi uprawnieniami, pliki, które muszą należeć do innej grupy, pliki, które nie powinny być czytelne dla grupy, użytkownicy, którzy popełniają błędy lub mogą „ troszczyć się o to, aby dostępność grupy pozostała zgodnie z oczekiwaniami…), że grupy tak naprawdę nie rozwiązują tego problemu.

— Gilles „SO- przestań być zły”

Nie rozumiem, w jaki sposób pliki musiałyby mieć własne uprawnienia, gdyby uprawnienia grupy do katalogu były ustawione w taki sposób, że żaden użytkownik nie mógłby „cd” do katalogu lub „ls” katalogu.

— Qasim

@Qasim Każdy plik poniżej /var/www/allowfolderi jego podkatalogi muszą być dostępne, nie tylko /var/www/allowfoldersame. I odwrotnie, inne pliki nie mogą być dostępne. W rzeczywistości rozwiązanie oparte wyłącznie na uprawnieniach do plików i liście kontroli dostępu nie może całkowicie spełnić wymagań: pozwoliłoby przynajmniej użytkownikowi przetestować, czy dana nazwa istnieje pod /var/www, ponieważ muszą mieć x uprawnienia /var/wwwdostępu /var/www/allowfolder.

— Gilles „SO- przestań być zły”

No dobrze, rozumiem, ale jeśli wykluczymy z tego katalog / var i powiedzmy, że mówimy o normalnym katalogu w katalogu / home / user?

— Qasim

Powinieneś użyć chroot. chrootPolecenie zmienia katalog główny, że wszystkie procesy potomne widzieć. Podam przykład, aby pokazać, jak to działa.

Zostało to napisane na miejscu; Tak naprawdę nie jestem teraz przed komputerem z systemem UNIX. W tym przykładzie jest to katalog o nazwie dirz trzech plików: a, b, c, i ls. Pierwsze trzy to zwykłe pliki. lsjest dowiązaniem twardym do prawdziwego lspliku binarnego, dzięki czemu możemy wyświetlać listę plików w chroot.

Idę chrootdo dir. (Zauważ, że prawdopodobnie zapominam o niektórych katalogach w katalogu głównym).

Oto konfiguracja w postaci danych wyjściowych powłoki:

$ pwd
/home/alex/test
$ l
dir
$ ls dir
a b c ls
$ ./ls dir # does the same thing
a b c ls
$ ls /
bin boot dev etc home mnt media proc sbin sys usr var

Teraz wejdę chrootw dir. W /bin/bashWybiera argumentów co proces ten powinien być prowadzony z nowego katalogu. Domyślnie jest to /bin/sh.

$ chroot /bin/bash dir
$ # this prompt is now from a subprocess running in the new root directory
$ PATH=/ ls
a b c ls
$ pwd
/

Teraz wychodzimy z chroot:

$ exit
$ # this prompt is now from the original bash process, from before the chroot
$ pwd
/home/alex/test

Mam nadzieję, że to ilustruje działanie chrootpolecenia. Zasadniczo, co musisz zrobić, aby rozwiązać problem, to uruchomić chrootpolecenie jako ten użytkownik za każdym razem, gdy się loguje. Być może umieścić go w skrypcie startowym?

Hardlink do pliku będzie nadal działał wewnątrz chroot, nawet jeśli do tego pliku nie można uzyskać dostępu innymi sposobami (działa to, ponieważ hardlinks wskazują na i-węzły, a nie ścieżki). Aby umożliwić użytkownikowi dostęp np. Do mysqlpolecenia, należy wykonać:

ln /usr/bin/mysql /path/to/chroot/target

— strugee
źródło

Ale czy nie wymagałoby to ode mnie stworzenia całego środowiska chroot ze wszystkimi dowiązaniami symbolicznymi? Czy nie byłoby łatwiej uruchomić polecenie, aby nowy użytkownik nie miał dostępu do innych katalogów, ale programy takie jak apache nie tracą do nich dostępu?

— Manishearth,

Zasadniczo, czy jest jakiś sposób (poprzez chmod) spowodowanie, że użytkownik straci dostęp do odczytu do reszty FS bez wpływu na dostęp innych użytkowników?

— Manishearth,

@Manishearth nie ma prostego sposobu chmod. kiedy powiesz „czy nie byłoby łatwiej uruchomić polecenia ... nie tracisz do nich dostępu”, to polecenie brzmi chroot. jeśli wytłumaczysz, co masz na myśli przez „całe środowisko chroot”, lub dlaczego byłby to problem, może zrozumiem lepiej. (uwaga, że można dać dostęp do wszystkich plików wykonywalnych z oneliner: ln /bin/* /path/to/chroot/target)

— strugee

@Manishearth, jeśli mój przykład nie miał sensu, zachęcam do zabawy ze chrootsobą lub daję znać, co nie miało sensu. jeszcze lepiej, zrób obie rzeczy. (i przeczytaj strony).

— strugee,

@Manishearth, jeśli ta odpowiedź pomogła ci w wystarczającym stopniu, aby doprowadzić do odpowiedzi, powinieneś rozważyć jej zaakceptowanie.

— strugee,