ďťż
 
 
   [+] skrypt bash, nie wszystkie polecenia działają
 
 

Tematy

 
    
 

 

 

 

[+] skrypt bash, nie wszystkie polecenia działają





robero - 14-05-2010 01:06
Mam dwa proste skrypty dla touchpada: wlacz.sh i wylacz.sh.
Np. wylacz.sh #!/bin/bash

kdesu  rmmod psmouse
perl -pi -e 's/#rmmod psmouse/rmmod psmouse/' /etc/rc.local Pierwsze polecenie ładnie się wykonuje ale drugie już nie, a zależy mi na tym żeby zmiany zostawały na stałe.
Polecenie jest dobre bo w konsoli roota działa.
Skrypt ma być uruchamiany przez użytkownika.
Jak poprawić ten skrypt?



kaworu - 14-05-2010 01:52
Zobacz tak #!/bin/bash

kdesu  rmmod psmouse && perl -pi -e 's/#rmmod psmouse/rmmod psmouse/' /etc/rc.local



robero - 14-05-2010 01:56
Niestety bez zmian



xmaster - 14-05-2010 10:27
Problem leży więc w uprawnieniach użytkownika, pewnie nie ma uprawnień do pliku.



robero - 14-05-2010 11:31

Problem leży więc w uprawnieniach użytkownika, pewnie nie ma uprawnień do pliku. Użytkownik jest właścicielem pliku, plik jest wykonywalny.



Yuji - 14-05-2010 11:58
Ale nie masz uprawnień do usunięcia modułu (rmmod) i załadowania (pewnie modprobe) (potrzeba uprawnień admina). Odpalasz program z sudo na początku

sudo ./skrypt Ja mam takie coś aby wyłączać/włączać touchpada.
#!/bin/bash

if [ $# -ne 1 ]; then echo "Użycie: $0 {start|stop}"; exit 1; fi

if [ "$(id -gn)" != "root" ]; then echo "Brak uprawień roota. Pa"; exit 1; fi

if [ $1 == "start" ];
then
        modprobe psmouse

        echo -e "\nPsmouse: started"

elif [ $1 == "stop" ]
then
        rmmod psmouse

        echo -e "\nPsmouse: stoped"

elif [ $1 == "restart" ]
then
        $0 stop
        $0 start

        echo -e "\nPsmouse: restarted"

fi Restart zbędny, ale tak zostało i nie chciało mi się kasować ;p

Wrzucasz do /usr/bin (kopiujesz za pomocą sudo cp ./skryptSP /usr/bin/skryptSP)
i zawsze wywołujesz przez sudo skryptPS start lub przez sudo skryptPS stop.

Ew możesz dodać skrypt do sudoers (za pomocą visudo) aby nie wymagał hasła. (w skrypcie dodajesz sudo przed rmmode i modprobe) i kasujesz warunek sprawdzania czy jesteś adminem.



robero - 14-05-2010 13:37
Dzięki za odpowiedzi. Zaczynam wątpić czy znajdę takie rozwiązanie o jakie mi chodziło.
Dodam że to ma być skrypt na pulpicie(w module lancelota), włączany poprzez kliknięcie w plik skryptu i stąd problemy.
Gdybym miał to uruchamiać z konsoli to to już działa.
I nie chcę używać sudo.


Ale nie masz uprawnień do usunięcia modułu (rmmod) i załadowania (pewnie modprobe) (potrzeba uprawnień admina). Włąsnie ta cześć się wykonuje dzięki kdesu, chodziło o tą zamianę w perl.

POSTĘP
Skrypt wlacz.sh:
#!/bin/bash
modprobe psmouse
perl -pi -e 's/rmmod psmouse/#rmmod psmouse/' /etc/rc.local Skrypt wlacz.sh w innym miejscu (inny): #!/bin/bash
su root -c /home/mirko/Programy/touchpad/wlacz.sh Jeśli użytkownik uruchamia z konsoli ten drugi skrypt to działa, jeśli kliknę w plik to już nie, zapewne dlatego że nie wyskakuje monit o hasło.
Jakiś pomysł?



Yuji - 14-05-2010 14:06
dodać skrypt do sudoers?
visudo i dopisujesz:
nickUsera    ALL=NOPASSWD: /sciezka/do/pliku/wlacz
nickUsera    ALL=NOPASSWD: /sciezka/do/pliku/wylacz Wtedy nie powinno pytać o hasło

Tak na szybko to zrobiłbym tak:
Dwa pliki na pulpicie z bitem wykonywania:
wlacz.sh:
#!/bin/sh
sudo modprobe psmouse
sudo perl -pi -e 's/rmmod psmouse/#rmmod psmouse/' /etc/rc.local wylacz.sh:
#!/bin/sh
sudo rmmod psmouse
sudo perl -pi -e 's/#rmmod psmouse/rmmod psmouse/' /etc/rc.local I wpis w sudoers:
silver  ALL=NOPASSWD:  /home/silver/Desktop/wlacz.sh
silver  ALL=NOPASSWD:  /home/silver/Desktop/wylacz.sh I klikając na skrypty na pulpicie włącza i wyłącza mysz (nie wiem czy robi wpisy w rc.local-robiłem bez tych 2 linii - linijki z perl)



robero - 14-05-2010 16:37
Nie wiem dlaczego wpisy w sudoers totalnie nic mi nie dają. W ogóle chyba mam nieskonfigurowane sudo i nie chcę go konfigurować.
Dodatkowo wydaje mi się że stworzenie takiego pliku jak chciałem (taki jak stworzył Yuji) jest skrajnie niebezpieczne, bo przecież teraz dowolny skrypt z prawami użytkownika może dodać do takiego skryptu dowolne polecenia super użytkownika. Stąd moje pytanie: czy to że nowy, obcy skrypt nie ma domyślnie bitu wykonywalności jest wystarczającą ochroną? Czy ktoś może to łatwo obejść?

Problem rozwiązany, choć inaczej niż chciałem. Dodałem te skrypty to /usr/bin, zrobiłem roota właścicielem i teraz z konsoli roota wydaję polecenia o wdzięcznej nazwie: touchpadON.sh i touchpadOFF.sh Dziękuję wszystkim za sugestie.



Yuji - 14-05-2010 16:53
Do końca nie rozumiem co masz na myśli, że niebezpieczne? To, że ktoś zmodyfikuje zawartość pliku to ustaw prawa dostępu aby tylko ten użytkownik mógł modyfikować plik.

No chyba, że zapewne masz na myśli, że komuś dasz usiąść na swoim koncie i zmieni zawartość. Tak to fakt niebezpieczne, dlatego samo sudo z konsoli musi wystarczyć. Ja osobiście mam ustawione tylko plik w /usr/bin (uruchomię z każdego miejsca w konsoli) i z sudo odpalam (start|stop) (bez sudoers).

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.



robero - 14-05-2010 17:40
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.



Yuji - 14-05-2010 18:15
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: bash ./skrypt
sh ./skrypt
... 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.
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 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.
sh ../silver/aaa
sh: Can't open ../silver/aaa Można też zabrać odczyt ,,x'' razem z ,,r'' to już załatwi sprawę (nie odbierając dostępu do katalogu).
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 Ogólnie nie może mieć, żadnych uprawnień do uruchomienia i odczytania, a tym bardziej do zapisu.



robero - 15-05-2010 12:27
Dzięki za wyjaśnienie. Faktycznie ten "x" niewiele daje.



rgl - 15-05-2010 19:05

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. Dlaczego nie?
Przecież w sudoers można ustawić uprawnienia do wykonania określonej komendy razem z parametrami.
user ALL = NOPASSWD: /sbin/rmmod psmouse, /sbin/modprobe psmouse powinno wystarczyć.

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.



Yuji - 15-05-2010 19:36
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ń: modprobe psmouse
rmmod psmouse będzie miał prawo.
Dobrze wiedzieć o parametrach programów w sudoers.
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • minister.pev.pl

  •  

     


     

     
    Copyright 2003. MĂłj serwis