Witam i o radę pytam.
Powoli kończę aplikację opartą o FXRuby. Klient ma odpalić ikonkę z pulpitu na linuksie i graficzna aplikacja ma zacząć działać.
Chodzi o to, żeby klient nie miał możiwości podglądnięcia skryptu, w którym jest hasło do bazy danych. Wiadomo, w skypcie jest podana nazwa bazy danych i użytkownik z prawami DELETE, UPDATE etc.
Skypt ruby nie jest binarką a jest interpretowany więc na dobrą sprawę musi mieć atrybut odczytu. A jak tak to ciężko z zabezpieczeniem. Ma ktoś jakieś pomysły?
Zawsze użytkownik może “podsłuchać” takie hasło. Najlepiej to zrealizować projektując aplikację na trzech warstwach - Baza danych / Serwer aplikacji / Klient.
Mógłbyś wtedy np. jako serwer aplikacji postawić Railsy udostępniający mechanizm REST po XML (niekoniecznie RAILS - Sinatra też nie byłaby chyba zła do tego celu.
Miałbyś załatwiony problem uprawnień - klient autoryzowałby się na serwerze aplikacji, utrzymywał sesję, a serwer aplikacyjny nie pozwolilby userowi na robienie brzydkich rzeczy. Baza byłaby względnie bezpieczna
A jak można podsłuchać hasło ze skryptu w linuksie jak się jest zwykłym użytkownikiem?
Aplikacja jest już na ukończeniu jako zwykły skypt .rb działający bez żadnych railsów tylko z biblioteką Fox.
Jakis Hash czy cos, w Fx masz na pewno mozliwosc przy starcie wczytac plik ze skryptem i go jakos odhashowac, np poprzesuwac kazdy znak o 1, czy cokolwiek takiego. Powinno dac rade
trzymac plik z danymi na zewnatrz i go includowac
Może zapisać te hasło jako stala w Fx, i wywoływać skrypt z parametrem, pobierajac go np z ARGV[0]
… kilka innych mozliwości, trzeba by pomyśleć.
Nawet jakiś hash na haśle to już coś. Większość ludzi nie przetrzepie kodu by znależć sposób na odhashowanie tego
[quote=hubertlepicki]$ cat skrypt.rb
i widzisz hasło…[/quote]
No nie do końca. Ty piszesz o sytuacji jak użytkownik ma dojście do skrytpu - wtedy masz rację.
Zadałem to pytane w kontekście, czy da się podglądnąć dane z procesu linuksowego? To tak na marginesie bo aż takie duże zabezpieczenia mi w tym przypadku nie są potrzbne.
Przykłąd tego co miałem na myśli:
ps aux | grep "ruby"
user1 7043 8.9 2.9 46564 30032 pts/0 S+ 19:32 0:04 ruby ./app.rb <-----------!!!!!!!!
user1 7074 0.0 0.0 3004 764 pts/1 R+ 19:32 0:00 grep ruby
Szkoda, że linuks pokazuje przy rubym nazwę skryptu. Wie ktoś jak w linuksie tego się pozbyć, by zamaskować nazwę skryptu? Na dobrą sprawę mogę skasować z systemu polecenie ps i użytkownik chyba wtedy już nie podglądnie.
A swoją drogą chyba wpadł mi do głowy bardzo prosty sposób, a wydaje mi się że zawsze najprostsze rozwiązania są najlepsze. Co sądzicie na temat takiego zabezpieczenia?
napisać w języku C/C++ programik i skompilować pod konkretnym linuxem, przy użyciu G++
programowi dać uprawnienia tylko do wykonywania dla użytkownika - użytkownik nie może ani czytać ani zapisywać tego pliku
program ten wykonywałby sie z prawami roota’ i miałby dostęp do skryptu który też miałby prawa roota.
program ten wywołałby komendę ruby nazwa programu i chyba user nic już nie podglądnie - chyba, że istnieje w linuksie wyciągniecie danych z procesu.
Jak to widzicie? Mógłby ktoś napisać tych parę linijek w C/C++, które by wywołały: ruby moj_program.rb?
#include <stdlib.h>
int main() {
system("./skrypt.rb");
}
masz w linux top jeszcze by pokazac liste procesow
ale źle kombinujesz Linux to nie windows, dajesz prawa userowi tylko takie jakie potrzebuje. Możesz mu nawet shell zabrać. A tym bardziej dostep do wszytskich niepotrzebnych mu komend. Tak by tylko mógł ten programik odpalić i tyle.
A tak na marginesie
mozesz odpalic skrypt potokiem, kolejna fajna rzecz w linuxie
Dobrze kombinujesz, żeby użyć binarki do odpalenia skryptu rubiowego. Jak dorzucisz do tego suid to powinno być względnie bezpiecznie.
Masz 2 pliki:
app.rb - aplikacja ruby, tu masz zaszyte hasło. Prawa tylko dla właściciela
start_app - binarka, zmienia uid i uruchamia app.rb. Prawa dla wszystkich do odczytu/uruchomienia
$ ls -l
-rwx------ 1 rubyfx rubyfx 75 2009-11-26 21:39 app.rb
-rwsr-sr-x 1 foo foo 9257 2009-11-26 21:38 start_app
Teraz każdy user inny niż rubyfx i root mogą uruchomić ./start_app, ale nie mogą odczytać app.rb
#!/usr/bin/env ruby
#app.rb
PASSWORD = "rails scale"
puts "I know password but you cant see it"
$stdout.flush
user@localhost$ cat app.rb
cat: app.rb: Permission denied
user@localhost$ ./start_app
I know password, but you cant see it
Ogólnie to proof of concept i nie jestem pewien czy w 100% to jest bezpieczne, ale na pewno lepsze niż security through obscurity
Ps zamiast Fx który chyba jest płatny jest ciekawy sposób czysto railsowy by go zastąpić w Ruby i Gtk2 można napisać (jets nawet gotowa), prostą przeglądarkę www, i przepuścić ją przez rubyexec czy jak to się nazywa. I masz w sumie to samo. Ale to tez proof of concept, ale myśle nad takim projektem jakiś czas już. Na razie pisze w Gtk2 i rubym odtwarzacz muzyczny.
michmin - dzięki bardzo za gotowy sposób. Jak ukończę skrypt zastosuję to co podałeś.
gotar:
[quote]foxGUIb is open source and redestributable under the terms of the Artistic License.
libGUIb is redistributable for commercial and non-commercial use under the terms of the LGPL.
Source files generated by foxGUIb are free for commercial and non-commercial use.[/quote]
A railsów nie umiem A te kombinacje o których piszesz to dla mnie kosmos.
Staram się używać zawsze rozwiązań najprostszych. Np. jade z czystym w SQL’em w rubym bo na activerecord i poznawanie wszystkiego od początku szkoda mi czasu. Co więcej - eksperymentowanie z zapytaniami do bazy w oparciu o jakieś activerecordy itp. jak dla mnie to porażka - w jednym miejscu się walniesz i skutek może być tragiczny.
Zwłaszcza jeśli chodzi tam o te zależności belongs_to. To trzeba bardzo dobrze zrozumieć żeby stosować. A materiałów niezbyt dużo. Dla przykładu szukałem w sieci jak korzystać z activerecord bez railsów - porażka. Więc odpuściłem.
Co do Foxa - bardzo dobry interfejs właśnie ze względu na darmowość. Jak dla mnie rewelacja.
I do tego stabilny - dużo aplikacji naukowych, na uniwerkach, za granicą powstaje w oparciu o FXRuby.
A te kombinacje o których piszesz to dla mnie kosmos.