🚀 go-pugleaf

Andrzej Rosa <bakters@yahoo.com> wrote:
> >>  ./test                       
> >>  -su: ./test: /bin/bash: bad interpreter: Permission denied
> >
> > Myślałeś, że to "sh" jest tam bez powodu? :-)
> > Zamiast tego może byc prawie dowolny interpreter, choćby perl.
> >
> > Rozwiązaniem jest danie użytkownikowi "restricted shell" w stylu
> > rbash
> 
> Dałem.  sh datafile nadal działa. 

RTFM. 

> > ale wtedy trzeba uważać co się udostępnia użytkownikowi (np.
> > udostępnienie vim-a nie jest dobrym pomysłem,
> Akurat na to jest wyjście.  Udało mi się uruchomić vima bez dostępu do
> wewnętrznego shella. 

Akurat chodzi o to, żeby nie dało się uruchomić vima _z_ dostępem do
shella i kilkoma innymi funkcjami (RTFM j.w.)

> > lepszy będzie rvim).
> > Jakoś nie widziałem systemu desktopowego z uzytkownikami pracującymi
> > z "restricted shell"...
> 
> Oj, na wszystko jest jakieś obejście.  Twoja argumentacja jest typu,
> "skoro kłódkę można otworzyć spinką do włosów, równie dobrze możesz
> zostawić komórkę zamkniętą na skobel", ale to IMO błędna logika.

Nie. Po prostu mnożysz przeszkody techniczne, które utrudniają życie
w równym stopniu malware/włamywaczowi co użytkownikowi przeciętnego peceta
desktopowego Linuksa (wyobraź sobie, że nagle przestają Ci działać skrypty
startowe w $HOME - wygodne?). Chrome to jakby inna bajak bo zapowiada
się, że niewiele tam bedzie można zrobić poza odpaleniem webaplikacji.

> Za
> każdym utrudnieniem zniechęcasz jakiś procent potencjalnych włamywaczy,
> czyli każde utrudnienie przynosi mimo wszystko efekty.

Chyba, że utrudniasz również życie użytkownikowi. Wtedy będzie się
starał pozbyc tego utrudnienia i tylko wszystkim dodajesz niepotrzebnej
pracy.

> Czyli reasumując, opcja noexec jest skuteczna, nawet jeśli czasami nie
> jest skuteczna. 

Takie UAC for Linux? :>

Pozdrawiam

-- 
Radosław Gancarz                             r a d e k g @ h e l l . p l
http://bugs.from.hell.pl/