W przypadku zaufanych sieci lokalnych, czy też kontenerów LXC, nie musimy zbytnio się troszczyć o bezpieczeństwo przesyłanych danych. Nikt nam przecież nie założy tutaj podsłuchu. Dlatego też we wpisie poświęconym konfiguracji Wine nie szyfrowaliśmy praktycznie żadnego ruchu sieciowego. Gdyby jednak zaszła potrzeba przesłania pakietów do zdalnego Xserver'a przez internet, to takie rozwiązanie naraziłoby nas na przechwycenie wszystkich danych. By zabezpieczyć się przed tego typu scenariuszem możemy zaszyfrować ruch do Xserver'a forward'ując wszystkie zapytania przy pomocy szyfrowanego tunelu TLS. Możemy to zrobić przy pomocy SSH i w tym wpisie postaramy się skonfigurować ten mechanizm.

Na debianie Xserver domyślnie ma wyłączoną możliwość nasłuchiwania połączeń zdalnych. Chodzi oczywiście o kwestie bezpieczeństwa, bo przecie nie od dziś wiadomo, że akurat to oprogramowanie jest dziurawe jak sito i nikt rozsądny nie chciałby instalować go na swoim serwerze. Należałoby jednak rozgraniczyć wykorzystywanie podatności jakiegoś oprogramowania od możliwości wejścia z nim w interakcję. Jakby nie patrzeć, sam Xserver posiada co najmniej trzy mechanizmy ochrony, a do tego dochodzą jeszcze reguły iptables , czy też pliki /etc/hosts.allow i /etc/hosts.deny . Prawdopodobnie jest ich jeszcze kilka ale te najczęściej wykorzystywane mechanizmy gdy pojawia się słowo Xserver, to -nolisten tcp (domyślnie aktywowany), xhost oraz xauth . Pierwszy z nich wyklucza się z pozostałymi i to tym dwóm ostatnim przyjrzymy bliżej w tym wpisie.

Mechanizmy xhost oraz xauth w żaden sposób nie zabezpieczają informacji przesyłanych do Xserver'a. Wobec czego, całą komunikację można bez problemu podsłuchać. Stwarza to zagrożenie przechwycenia nie tylko obrazu wyświetlanego na monitorze ale także danych dotyczących myszy i przyciskanych klawiszy na klawiaturze.

Każdy kto zmienił architekturę systemu z i386 na amd64 raczej nie dostrzegł większej różnicy w operowaniu na którejś z nich. Czasem jedynie pakiety w nazwie mają 64 zamiast 32. Jest natomiast jedna rzecz, która drażni chyba każdego. Mowa tutaj o projekcie Wine. Wine nie umie obsługiwać natywnie serwera dźwięku PulseAudio. Do tego dochodzi jeszcze problem, który związany jest z tymi wszystkimi pakietami 32 bitowymi, które trzeba zainstalować. I w ten sposób nasz system staje się bardziej multiarch niż amd64. W tym wpisie postaramy się przy pomocy kontenera LXC odizolować Wine od całej reszty systemu operacyjnego, tak by nie musieć wgrywać do niego całej masy zbędnych bibliotek.

Kontenery LXC mają za zadanie odizolować poszczególne usługi od pozostałej części systemu. LXC jest podobny nieco do maszyn wirtualnych, np. tych tworzonych przez VirtualBox. Niemniej jednak, oba mechanizmy różnią się trochę. Zasadnicza różnica między nimi polega na tym, że LXC wykorzystuje środowisko chroot , w którym współdzielone jest jądro operacyjne. Nie trzeba także z góry określać zasobów pod działanie takiego kontenera, tak jak to ma w przypadku maszyn wirtualnych. Rzućmy zatem okiem jak wygląda konfiguracja takich kontenerów na linux'ie.

Ogromna większość ludzi korzysta z jednego profilu swojej przeglądarki internetowej. Niesie to ze sobą spore zagrożenie bezpieczeństwa jak i może godzić w naszą prywatność. Jeśli dzielimy z kimś komputer, to raczej wszyscy domownicy posiadają osobne konta w systemie, a co z tym się wiąże, inny profil przeglądarki. I na tym zwykle podział się kończy ale przecie to nie wszystko. Profil, jak sama nazwa wskazuje, jest w stanie dostosować opcje przeglądarki, np. pod kątem pewnych aktywności. W tym wpisie postaramy się utworzyć kilka profili w Firefox'ie i sprawdzimy korzystanie z nich będzie odczuwalne w jakiś sposób dla przeciętnego użytkownika internetu.

SysRq (System Request) to klawisz na klawiaturze, po którego przyciśnięciu można wysłać niskopoziomowe zapytana bezpośrednio do kernela linux'a. Te komendy działają nawet w przypadku pozornego braku kontaktu z systemem operacyjnym, tj. zacięcia dźwięku, nieruchomy kursor myszy, a nawet w przypadku braku możliwości wpisywania znaków z klawiatury. Zwykle po opisanych wyżej symptomach, człowiek jest skłonny przycisnąć przycisk reset na obudowie swojego komputera, no bo jak inaczej odwiesić taki system? Problem z twardym resetem (za pomocą przycisku) jest taki, że praktycznie zawsze po nim występuje uszkodzenie struktury systemu plików na dysku, a czasami uszkodzeniu ulega cała partycja. To niesie ze sobą ryzyko utraty danych. Dlatego też powinniśmy zaprzestać resetowania komputerów przy pomocy przycisków i zacząć korzystać z klawisza SysRq .

Gdy nasz linux napotka z jakiegoś powodu błąd wewnątrz swojej struktury, to istnieją sytuacje, w których obsługa tego błędu czasem nie jest możliwa. Wobec czego, zostaje wyrzucony komunikat systemowy oznajmiający nam, że kernel spanikował (kernel panic), bo nie wie co w takim przypadku zrobić. Gdy tego typu sytuacja się nam przytrafia, nie ma innego wyjścia jak tylko uruchomić system ponownie. Co jednak w przypadku gdy pracujemy zdalnie i nie jesteśmy w stanie zresetować takiej maszyny fizycznie? Na szczęście kernel ma kilka opcji, które mogą zainicjować automatyczny restart w przypadku wystąpienia kernel panic.

W obecnych czasach powoli się odchodzi od stosowania technologi flash w przeglądarkach. Na dobra sprawę, po tym jak google w youtube przesiadł się na html5, to korzystanie z flash player'a nie ma już większego sensu. Są jednak serwisy, które nie nadążają za zmieniającą się rzeczywistością i w ich przypadku przejście z flash'a na html5 może jeszcze zająć kilka lat. Zatem nawet jeśli nie korzystamy z flash'a na co dzień, to i tak większość z nas będzie chciała go mieć w systemie, tak na wszelki wypadek, by nie być pozbawionym możliwości oglądania materiałów video na tych drugorzędnych serwisach. Jako, że wtyczka flash jest bardzo dziurawa, przydałoby się ją nieco skonfigurować i w tym wpisie zostanie przedstawionych szereg opcji, które można umieścić w pliku mms.cfg .

Po wpisaniu w pasku adresu Firefox'a about:config , zostanie nam zwrócona dość długa lista parametrów konfiguracyjnych, które możemy sobie dostosować wedle uznania. Większość z nich ma spory wpływ na zachowanie samej przeglądarki ale są też i opcje, które zostały dodane za sprawą różnych dodatków. Chodzi o to, że za każdym razem gdy instalujemy nowy addon, to ten zwykle ma opcje konfiguracyjne i to właśnie one są widoczne w about:config . W przypadku gdy już nie korzystamy z tego dodatku i wyrzuciliśmy go kompletnie z Firefox'a, wpisy w konfiguracji dalej widnieją. Przydałoby się zatem nieco przeczyścić naszą przeglądarkę i usunąć te wszystkie śmieci.

Przeglądarki mają to do siebie, że każda z nich korzysta z własnych ustawień dotyczących typów MIME (mime type). Do tego dochodzi jeszcze fakt, że często te ustawienia są inne od tych, które mamy w systemie. Może to nie jest jakiś wielki problem, bo w opcjach Firefox'a możemy bez trudu szereg rzeczy poprzestawiać. Natomiast jest jeden problem, którego w prosty sposób się obejść nie da i trzeba się trochę na nim pochylić. Chodzi o dodawanie nowych typów MIME, które nie są pokazane na liście obsługiwanych typów w Preferences -> Applications. Wiąże się z tym tak skonfigurowanie przeglądarki, by automatycznie otworzyła ona jakiś program ilekroć dany typ pliku będzie pobierany.