[+] skrypt bash, nie wszystkie polecenia dzia
Wyjaśniam. Mówi się że linux jest bezpieczny ze względu na to że ważne polecenia można wykonać tylko z poziomu roota, i dlatego też nie ma (no jak się uprzeć to jest ale raczej się tego nie używa) logowania się w X-y jako root. Zawsze się mówi tylko o poziomie root jako zabezpieczeniu. Z tego wnioskować można, że uruchomienie czegoś z poziomu usera jest możliwe, a może nawet łatwe(chodzi mi o ingerencję przez internet, jakiś zainfekowany plik itp.). Dlatego jeśli jest taki plik użytkownika w katalogu domowym, lub innym należącym do usera i można w nim wykonywać polecenia superusera dzięki wpisom w sudoers, to możliwe jest przejecie kontroli nad komputerem już po włamaniu się na konto użytkownika i zmodyfikowaniu tego pliku. Dlatego pytam czy domyślny brak bit wykonywalności dla nowych skryptów jest wystarczającym zbezpieczeniem przed uruchamianiem niechcianych skryptów, czy są tacy którzy to obejdą. Pytam z ciekawości, już nie robię takiego pliku.
No niestety, zostawienie takiego pliku w katalogu użytkownika jest katastrofalne.
Podałem takie rozwiązanie, bo tylko tak można (przynajmniej tak mi się zdaje) zrobić usuwanie i dodawanie modułu psmouse bez hasła.
Niestety jak zauważyłeś, jest to niebezpieczne jeśli ktoś zmieni zawartość takiego skryptu.
Takie coś zaleca się tylko wtedy jeśli wiesz, że nikt nieupoważniony nie ma dostępu do tego pliku.
Np. zastosowanie: pozwolić jakiemuś użytkownikowi zrobić aktualizacje systemu bez dawania mu uprawnień admina.
Panel www administracyjny wymaga dostępu do plików/poleceń systemowych (bez programów z setuid - wymagają uprawnień admina - sudoers) nie zrobisz tego.
Dlatego takie pliki powinny mieć stosowne uprawnienia. Ale właśnie. Jak ktoś się włamie na konto użytkownika i domyśli się, że istnieje taki plik z takim uprawnieniem to szybko zrobi sobie konto z uprawnieniami admina i koniec z nami. Dlatego robiąc wpisy w sudoers miejmy pewność, że nikt nie może wejść na nasze konto. Bo inny użytkownik z tego samego systemu nie będzie miał uprawnień uruchomienia pliku gdyż nie jest jego właścicielem.
Wracając do pytania. Niestety przetestowałem.
Bez bitu grupy spokojnie uruchomisz przez:
Tylko musisz być właścicielem, lub należeć do grupy z uprawnieniami (mieć uprawnienie do wyświetlenie poleceniem cat /ścieżka_do_pliku).
Tak więc zabranie samego x nic nie da, jak skorzysta z bash/sh przed nazwą skryptu.
Tak więc zabranie bitu x nie ratuje. Ale zabranie dostępu do katalogu ze skryptem już tak (musiałem pozwolić mu wejść do /home/silver aby mógł uruchomić, bez dostępu do /home/silver nie uruchomi.
Można też zabrać odczyt ,,x'' razem z ,,r'' to już załatwi sprawę (nie odbierając dostępu do katalogu).
Ogólnie nie może mieć, żadnych uprawnień do uruchomienia i odczytania, a tym bardziej do zapisu.
Podałem takie rozwiązanie, bo tylko tak można (przynajmniej tak mi się zdaje) zrobić usuwanie i dodawanie modułu psmouse bez hasła.
Niestety jak zauważyłeś, jest to niebezpieczne jeśli ktoś zmieni zawartość takiego skryptu.
Takie coś zaleca się tylko wtedy jeśli wiesz, że nikt nieupoważniony nie ma dostępu do tego pliku.
Np. zastosowanie: pozwolić jakiemuś użytkownikowi zrobić aktualizacje systemu bez dawania mu uprawnień admina.
Panel www administracyjny wymaga dostępu do plików/poleceń systemowych (bez programów z setuid - wymagają uprawnień admina - sudoers) nie zrobisz tego.
Dlatego takie pliki powinny mieć stosowne uprawnienia. Ale właśnie. Jak ktoś się włamie na konto użytkownika i domyśli się, że istnieje taki plik z takim uprawnieniem to szybko zrobi sobie konto z uprawnieniami admina i koniec z nami. Dlatego robiąc wpisy w sudoers miejmy pewność, że nikt nie może wejść na nasze konto. Bo inny użytkownik z tego samego systemu nie będzie miał uprawnień uruchomienia pliku gdyż nie jest jego właścicielem.
Wracając do pytania. Niestety przetestowałem.
Bez bitu grupy spokojnie uruchomisz przez:
Kod: Zaznacz cały
bash ./skrypt
sh ./skrypt
...Tak więc zabranie samego x nic nie da, jak skorzysta z bash/sh przed nazwą skryptu.
Kod: Zaznacz cały
silver@silver-laptop:~$ ls -al aaa
-rw-r--r-- 1 silver silver 24 05-14 17:44 aaa
silver@silver-laptop:~$ cat aaa
#!/bin/bash
echo "asd"
silver@silver-laptop:~$ bash ./aaa
asd
silver@silver-laptop:~$ sh ./aaa
asd
tester@silver-laptop:~$ cd ../silver
tester@silver-laptop:~$ sh aaa
asd
Kod: Zaznacz cały
sh ../silver/aaa
sh: Can't open ../silver/aaa
Kod: Zaznacz cały
silver@silver-laptop:~$ ls -al aaa
-rw-r----- 1 silver silver 24 05-14 17:44 aaa
tester@silver-laptop:~$ bash ../silver/aaa
bash: ../silver/aaa: Brak dostępu
Dlaczego nie?Yuji pisze:Zastanawiam się czy nie da się ustawić, że użytkownik może używać tylko rmmod i modprobe dla określonego modułu bez hasła, dla reszty normalnie z hasłem, ale raczej tak nie ma.
Przecież w sudoers można ustawić uprawnienia do wykonania określonej komendy razem z parametrami.
Kod: Zaznacz cały
user ALL = NOPASSWD: /sbin/rmmod psmouse, /sbin/modprobe psmouse
Zresztą nadanie uprawnień do wykonania określonej komendy czy skryptu bez hasła nie jest naruszeniem bezpieczeństwa jeśli właścicielem pliku jest root i nikt inny nie ma uprawnień do zmiany zawartości pliku.
Tyle że skrypt nie powinien być umieszczony w katalogu użytkownika a np. w /usr/local/bin gdzie zwykły użytkownik nie ma prawa do zapisu. Aby uruchamiać skrypt przez kliknięcie wystarczy aktywator na pulpicie, skrypt może być gdziekolwiek.
No właśnie, nie wiedziałem, czy w sudoers można określić polecenie o danych parametrach. Jeśli tak to fajnie (nie zagłębiałem się, aż tak w sudoers).
Taki wpis załatwiłby problem z modyfikacją skryptu, bo tylko do poleceń: będzie miał prawo.
Dobrze wiedzieć o parametrach programów w sudoers.
Taki wpis załatwiłby problem z modyfikacją skryptu, bo tylko do poleceń:
Kod: Zaznacz cały
modprobe psmouse
rmmod psmouseDobrze wiedzieć o parametrach programów w sudoers.