Przeglądając sobie FAQ dotyczący urządzeń USB natknąłem się na punkt, który opisywał parametr max_sectors . Niby nic wielkiego, w linux'ie jest przecie pełno przeróżnych opcji, przy pomocy których jesteśmy w stanie zmienić szereg aspektów pracy naszego systemu operacyjnego. Rzecz w tym, że parametr max_sectors potrafi nawet dość znacznie poprawić wydajność urządzeń USB, w tym tych wszystkich pendrive'ach, w których prędkość zapisu pozostawia wiele do życzenia. W tym wpisie postaramy się nieco dostosować ten parametr, tak by przyśpieszyć transfer kopiowanych plików.

Budowanie samych profili dla AppArmor'a nie jest jakoś szczególnie trudne, zwłaszcza, gdy do tego celu wykorzystujemy narzędzia dostępne w pakiecie apparmor-utils . Dobrze jest jednak prześledzić sobie manual AppArmor'a oraz to, co twórcy piszą na swojej stronie w oficjalnej dokumentacji projektu. Poniższy wpis powstał w celu zrozumienia składni profili AppArmor'a, tak by jeszcze bardziej uprościć proces ich budowania.

Opis składni znajdujący się poniżej został zaczerpnięty z wiki AppArmor'a. Część z poniższych informacji może nie mieć zastosowania w przypadku starszych wersji samego AppArmor'a.

Całkowite usuwanie plików (shred) jak i zerowanie całych nośników ma na celu nieodwracalne zniszczenie danych. W tych podlinkowanych artykułach próbowaliśmy zatrzeć ślady po skasowanych plikach. W tym wpisie zaś prześledzimy sobie co tak naprawdę się dzieje po utworzeniu i skasowaniu pliku, a także spróbujemy odzyskać te z nich, które już nie istnieją w naszym systemie. Ten artykuł będzie dotyczył jedynie systemu plików z rodziny ext , głównie ext4 .

Chciałem dziś wypakować sobie kilka plików, które były zebrane w paczkę .zip . Problem w tym, że ta osoba, co te pliki pakowała, najwyraźniej robiła to na widnowsie no i nie użyła standardowego kodowania, które jest wykorzystywane na każdym innym systemie, tj. UTF-8. Wobec tego, wszystkie pliki mają w swoich nazwach znaczek � w miejscu polskich liter. Jako, że tych plików jest dość dużo, to odpada ręczna edycja nazw i trzeba pomyśleć nad jakimś innym rozwiązaniem. Zmiana kodowania nazw plików, to nie jest to samo co zmiana kodowania zawartości tych plików. Na szczęście w linux'ie mamy do dyspozycji narzędzie convmv , które jest w stanie, jak sama nazwa mówi, przepisać nazwy plików ustawiając przy tym odpowiednie kodowanie.

W pewnych skrajnych przypadkach może się nam zdarzyć tak, że zapomnimy hasła do konta administratora systemu. Jak wiadomo bez użytkownika root w naszych linux'ach nie da się zbytnio nic zrobić. Na pewno nie da się przeprowadzić żądnych prac administracyjnych. Zwykle w takim przypadku moglibyśmy przeinstalować system i ustawić nowe hasło ale to wydaje się lekką przesadą. Poza tym, co w przypadku gdy nie możemy zwyczajnie zainstalować na nowo systemu lub nie mamy akurat pod ręką płytki czy pendrive live? Czy w linux'ie jest w ogóle możliwość odzyskania hasła użytkownika root bez rozkręcania komputera biorąc pod uwagę te wszystkie mechanizmy bezpieczeństwa, które czynią ten system tak bezpiecznym? Oczywiście zmiana hasła do konta administratora jest możliwa i nawet nie trzeba się przy tym zbytnio wysilać.

Zerowanie dysku twardego ma na celu usunięcie wszystkich znajdujących się na nim danych. Generalnie chodzi o zapisanie całej powierzchni danego nośnika samymi zerami. Ten proces różni się znacząco of formatowania dysku, czyli utworzenia nowego systemu plików, gdzie praktycznie wszystkie dane można bez większego problemu odzyskać. Zerowanie dysku (czy też pendrive) może w pewnych przypadkach naprawić logiczne błędy sektorów na dysku. Niemniej jednak, nie usuniemy za jego pomocą fizycznych bad'ów. Generalnie rzecz biorąc, mamy do wyboru dwie techniki zerowania. Jedna jest dokonywana na poziomie programowym, np. przy pomocy dd , druga zaś na poziomie sprzętowym, np. w hdparm . W tym wpisie postaramy się wyzerować przykładowy dysk.

W przypadku, gdy musimy pozbyć się jakiegoś pliku, który znajduje się na dysku, to nie jest zalecane korzystanie z narzędzia rm . Usuwa ono jedynie odnośnik do pliku, który go identyfikuje w strukturze systemu plików, tzw. i-węzeł (i-node). To co uzyskujemy za pomocą takich narzędzi jak rm , to jedynie oznaczenie pewnych bloków (tych od pliku) jako wolne, w których system operacyjny będzie w stanie dokonać zapisu danych późniejszym czasie. Podczas tej operacji nie są usuwane żadne informacje z dysku, a mając na uwadze ten fakt, możemy bez problemu tak "usunięty" plik odzyskać. By mieć pewność, że plik zostanie trwale zniszczony, trzeba go ponownie napisać, np. przy pomocy shred, który standardowo jest dostępny w każdej dystrybucji linux'a i to jemu będzie poświęcony ten wpis.

W pliku /etc/passwd jest przechowywana baza danych kont użytkowników w systemie linux. Z kolei w /etc/group mamy wypisane wszystkie grupy oraz powiązanych z nimi użytkowników. Generalnie rzecz biorąc, to te dwa pliki odpowiadają za konfigurację kont. Problem jednak zaczyna się w momencie gdy w grę wchodzą hasła, zarówno do kont jak i do grup. Gdyby były one trzymane w tych plikach, nie byłyby one w żaden sposób szyfrowane. Dlatego też powstał inny mechanizm, który ma na celu przeniesienie zahashowanych haseł do plików /etc/shadow i /etc/gshadow . W debianie użytkownikami i grupami możemy zarządzać przy pomocy odpowiednich narzędzi, które automatycznie dostosują wszystkie powyższe pliki. Nic jednak nie stoi na przeszkodzie aby edytować każdy z nich ręcznie. Problemy mogą się pojawić w momencie, gdy te pliki będą zawierać różne wpisy, np. w pliku passwd będzie określony użytkownik, który jednocześnie nie będzie istniał w pliku shadow , podobnie z grupami. W tym wpisie postaramy się sprawdzić te pliki i upewnimy się czy aby na pewno jest z nimi wszystko w porządku.

Podczas jednej z aktualizacji systemu został mi zwrócony pewien komunikat. Oświadczał on bowiem, że od jakiegoś czasu nazewnictwo interfejsów sieciowych w systemie uległo zmianie, oraz, że w wersji 10 debiana, ten obecny system nazw nie będzie już wspierany. Rozchodzi się o coś co nazywa się Predictable Network Interface Names, czyli przewidywalne nazwy interfejsów sieciowych. Jako, że aktualne wydanie stabilnego debiana ma numerek 8 i w niedalekiej przyszłości zostanie wydana 9, to przydałoby się już zacząć migrować na ten nowy system nazw. W tym wpisie dokonamy takiej migracji i zobaczymy jakie zmiany musimy poczynić, by nie doświadczyć problemów związanych z tą migracją nazw.

Wielu ludzi potrafi się rozpisywać na temat bezpieczeństwa systemu linux jednocześnie nie zauważając jednego bardzo poważnego problemu. Wszyscy wiemy, że linux'y są bezpieczne min. przez fakt rozgraniczenia konta administratora od konta zwykłego użytkownika i nadaniu im różnych praw dostępu do poszczególnych części systemu operacyjnego. O ile konta użytkowników mają różne nazwy, o tyle administrator w praktycznie każdym linux'ie kryje się pod nazwą root . Znając nazwę konta, można próbować złamać hasło. To trochę dziwne, że nie można sobie arbitralnie ustalić nazwy dla tego konta tak by uniknąć wszelkich ataków, które związane są z logowaniem się na określonego użytkownika w systemie. W tym wpisie postaramy się prześledzić całą procedurę zmiany nazwy konta root na jakąś dowolną i zobaczymy czy wpłynie to w jakimś stopniu na pracę naszego systemu.