Kolejny wyjazd na urlop i znowu dostęp do internetu sponsoruje Aero2. Oczywiście w wariancie z kompresowanym tunelem i proxy cache’ującym. Pewnie gdyby nie to rozwiązanie, to po prostu kupiłbym pakiet w Aero2, bo są naprawdę tanie. A jak testowałem przy okazji awarii netu u mojego ISP – śmiga to bardzo dobrze. Tak czy inaczej, gołe Aero2 jest nieprzyzwoicie wolne do WWW. Po włączeniu ww. proxy śmiga na tyle dobrze, że stwierdziłem, że nie ma sensu kupować. Tym bardziej, że nie pamiętam, czy aktywują od razu itp., a po włączeniu rozwiązania z tunelem wszystko działało. Przy czym najwięcej czasu przy włączaniu zajęło odszukanie wpisu z opisem.
W związku z użyciem ww. proxy WWW pojawia się jeden problem: nie działa przekierowanie. Co za tym idzie, podstawowa przeglądarka nie wyświetla w takiej konfiguracji pytania o captcha. Zresztą, nawet gdyby przekierowanie działało, to mało ono pomaga przy czynnym korzystaniu z internetu, tj. nie przy biernym przeglądaniu, ale np. podczas pisania komentarza na jakiegoś bloga. Co prawda dzięki dodatkowi Lazarus do przeglądarki (polecam!; dead link) treść komentarza nie zginie nawet jeśli funkcja cofnij w przeglądarce nie działa i nastąpi przekierowanie. Postanowiłem jednak sprawę ułatwić, przez napisanie prostego skryptu w Perlu, który sprawdzi dostępność zdefiniowanych hostów. A przy braku dostępności zadanej ilości wyświetli wyskakujące powiadomienie (xmessage). Przy czym sprawdza dość często (co 15 sekund), a jak brak łączności, to przerwa jest dłuższa.
Wyszło trochę ciekawiej, niż się spodziewałem. Wiadomo, że mocną stroną Perla są moduły, więc postanowiłem oprzeć się na dedykowanym module. Po pierwsze, okazało się, że Net::Ping domyślnie korzysta z TCP, nie ICMP, którego planowałem użyć, ale wydało się nawet lepsze. Niestety tylko do czasu, gdy okazało się, że przy podaniu hostów w formie domen i sprawdzaniu portu 80, za sprawą mechanizmu przekierowania Aero2, strona nadal jest dostępna. Tyle, że jest to strona mówiąca o konieczności wpisania captcha.
Rozwiązania są trzy. Pierwsze, to sprawdzanie zawartości strony, tj. czy nie pojawił się tekst mówiący o konieczności wpisania kodu captcha. Po pierwsze komplikuje to budowę skryptu. Po drugie, zmniejsza jego uniwersalność (będzie działał tylko dla Aero2), po trzecie, możliwe, że przestanie działać przy jakiejś zmianie komunikatu. Drugie rozwiązanie, to podanie IP zamiast nazw domenowych. Przy takim rozwiązaniu przekierowanie dokonywane przez Aero2 nie będzie miało wpływu. Mniej czytelne i… zwyczajnie nie wpadłem w pierwszej chwili.
Zamiast tego postanowiłem skorzystać z wersji najoczywistszej i pierwotnie zamierzonej: wykorzystać jednak ICMP do sprawdzania osiągalności hostów. I tu największa niespodzianka: Net::Ping (ogólnie Perl) do wykorzystania ICMP wymaga uprawnień roota. Zdziwiłem się, ale po prostu tak jest i nie jest to feature Perla, a systemu. Zwykli użytkownicy nie mają dostępu do tworzenia socketów. Z tego co znalazłem w sieci, polecane/najprostsze rozwiązanie na obejście tego to… wykorzystanie systemowego polecenia ping, do którego zwykle użytkownicy mają dostęp (SUID). Tak też uczyniłem.
Efekty można zobaczyć na mojej ulubionej sieci społecznościowej (hrhrhr), czyli w repo aero2-watch na GitHubie. Grupa potencjalnych użytkowników bardzo wąska (Linux + Aero2), ale może się komuś przyda…
Gdyby ktoś się zastanawiał, czemu klepię skrypty/siedzę na necie na urlopie to: lubię i zawsze to robię. Poza tym, do porannej kawy jak znalazł; robię też inne, typowo urlopowe rzeczy; napisanie ~50 linii w Perlu trwa znacznie krócej, niż napisanie tego wpisu.
Setuid-owane binarki to przeszłość nie spotkasz już ich w żadnej bardziej nowoczesnej dystrybucji. Używa się `man 7 capabilities` jak się chce nadać jakieś właściwości w stylu CAP_NET_BIND_SERVICE. Xorg też również obywa się bez tego.
Używanie socketów PF_INET, SOCK_DGRAM, IPPROTO_ICMP nie wymaga uprawnień root-a od około 2011 roku.
lwn.net/Articles/422330/
sturmflut.github.io/linux/ubuntu/2015/01/17/unprivileged-icmp-sockets-on-linux/
Chroot też od kernela 3.8 (USER_NS) nie wymaga tak nadzwyczajnych uprawnień. Moż
e czynić to i zwykły użytkownik. Kontenery uruchamiane przez użytkowników to już codzienność.
raw.githubusercontent.com/sabotage-linux/sabotage/master/KEEP/super_chroot.c
Ogólnie warto stosować izolację procesów w każdym możliwym zadaniu (nawet najbardziej trywialnym) i wykorzystwać całość dostępnych ku temu sposobów na poprawę bezpieczeństwa. Jednym z takich prostych narzędzi wykorzystującym większość nowości jest NsJail.
github.com/google/nsjail
Tak, SUID to raczej zaszłość, choć wydaje mi się, że niedawno któryś program (coś związanego z siecią właśnie) w Debianie pytał, czy ustawiać SUID, czy nie. Przy czym niedawno może oznaczać „we Wheezy”, Debian niekoniecznie musi być „bardziej nowoczesną dystrybucją”, i w końcu sam dialog box mógł być ze starszej wersji, niekoniecznie odzwierciedlającej środki techniczne. Bardziej wyrażam zdziwienie, że moduł mający ping w nazwie nie daje tak po prostu dostępu do… pinga. TBH spodziewałem się raczej, że to wrapper na systemowy ping.
Co do koncepcji „w każdym zadaniu, całość środków” to się nie zgodzę, zwł. jeśli domyślnie to nie przychodzi gotowe do izolacji. Komplikacja topologii i strata czasu, a tak naprawdę zysk niekoniecznie istotny. Przykład: blog na WordPressie powiedzmy w topologii baza, serwer WWW, varnish na froncie. Teoretycznie można to podzielić per proces, ale jeśli cały system (VMka/kontener) tylko do tego służy to… nie widzę sensu.
Za linka do nsjail dzięki, ciekawy projekt. 🙂