http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/Wpisy z dziennika internetowego Jogger, wspomaganego przez JabberaSun, 21 Feb 2016 14:55:06 +0100JoggerPLhttp://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1403780Ten /tmp oraz swap to w sumie nie taki duży problem. Nic nie stoi na przeszkodzie, aby były one szyfrowane przy pomocy DM-Crypt + LUKS. Chociaż faktycznie - w przypadku paranoicznego podejścia można uznać, że to właśnie przed użytkownikami systemu chcemy się ustrzec ;] A co do samego szyfrowania katalogu domowego i EncFS - bajer! Podoba mi się to bardzo. Właśnie takiego rozwiązania oczekiwałem dla systemów, gdzie szyfrowanie całej partycji nie jest wyjściem :DWed, 17 Jun 2009 18:58:42 +0200http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1403780http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1403793Ale ssh bez kluczy to słabo trochę... A jak jest przy zostawieniu sesji screena? Czy wszystko działa jak na normalnym shellu czy utnie wszystko po wylogowaniu się z ssh?Wed, 17 Jun 2009 19:22:54 +0200http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1403793http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1403898Co do normalnego hasła, to przy szyfrowaniu całego katalogu można z niego zrezygnować.Wed, 17 Jun 2009 21:28:08 +0200http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1403898http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1404189Ze stosowania automontowania przy logowaniu wynika oczywisty problem - będzie można po prostu złamać hasło z /etc/shadow, żeby uzyskać dostęp do danych. No ipamiętajcie o http://xkcd.com/538/ :PThu, 18 Jun 2009 13:01:45 +0200http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1404189http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1404240lolek: Oczywiście, można próbować łamać hasło z /etc/shadow (o ile cały FS nie jest szyfrowany - patrz co Zal napisał w pierwszym komentarzu), ale jakie to ma szanse powodzenia w skończonym czasie (i dla jakiej funkcji skrótu?). Poza tym, nic nie stoi na przeszkodzie, by użytkownik miał w katalogu domowym katalog szyfrowany innym hasłem (już nie montowany automagicznie, niestety - coś za coś). Jeśli chodzi o rubber hose method, to oczywiście, działa. Ale to już jest bezpieczeństwo fizyczne i wykracza nieco poza temat tego posta. ;)Thu, 18 Jun 2009 15:10:14 +0200http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1404240http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1405162Kryptografia w służbie wolnościSpoglądam na to, co dzieje się wokół mnie i nie mogę uwierzyć w to, co widzę. Obawiam się, że tam, gdzie wkracza dostatecznie rozwinięta technologia, pojawia się wiele problemów z którymi ludzie nie są w stanie sobie poradzić. I to ty[...]Sat, 20 Jun 2009 15:05:30 +0200http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1405162http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1406213Teraz to rządzi tylko ecryptfs. https://launchpad.net/ecryptfs.Mon, 22 Jun 2009 16:21:09 +0200http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1406213http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1481295Sam encfs jest dla mnie dużo lepszym rozwiązaniem niż jakiekolwiek jednoplikowe szyfrowania. Jego podstawowa zaleta to brak konieczności deklaracji ile będą zajmować nasze dane, co jest niezwykle przydatne w wypadku wieloużytkownikowych systemów. Nie przeszkadza mi problem jawnego stwierdzenia uprawnień plików lub w miarę dokładnego odwzorowania długości pliku, bo jak dla mnie nie są to kwestie bezpieczeństwa. Co napastnika obchodzi, że 4 pliki na 284 spotkanych posiada uprawnienia 760, a pozostałe 640? Co go obchodzi, że jakiś plik nazywa się JrsdgUvfd;33fs3 skoro tej nazwy nie może rozszyfrować bez znajomości hasła? A to, że w tym pliku ważącym dokładnie 702,5MiB znajduje się świeżo pobrany film lub jakiś ważny dokument państwowy nie zdradzi jego zewnętrzne atrybuty, tylko środek. Najważniejsza jest zawartość pliku, która jest bezpieczna dzięki zaszyfrowaniu jej. I jak dla mnie nazwy plików mogą być w 100% jawne, a szyfrowanie by sprawdziło się tak samo. Część osób stosuje podobny sposób nazewnictwa plików do ukrywania swojego porno na dysku, gdzie folder z filmikami przyrodniczymi nosi nazwę w stylu: "Zdjęcia z wesela wujka Staśka" co jak dla mnie niewiele różni się od nazwy "HcfdHdWY22d9;!". A mnie zastanawia treść aktualności tego rozwiązania. Najnowsza wersja encfs pochodzi z września 2008 roku i nie wiem czy jest to spowodowane porzuceniem programu przez developerów czy skończeniem prac nad nim (nie ma co w nim już poprawiać, bo jest wystarczająco dobry i stabilny do codziennego użytku). Odnośnie samego pam_encfs to lepszym rozwiązaniem jest dla mnie pam_mount, który utrzymuje montowanie dysku twardego dopóki jakakolwiek sesja użytkownika jest utrzymywana (czyli nie trzeba się tylko zalogować i wylogować, trzeba także ubić wszystkie screeny). Jest to co prawda słaby punkt, bo wystarczy dobrać się do kompa póki jest włączony, ale jest to tak samo słaby punkt jak ten z podmianą niektórych plików w celu zrzucania treści hasła do pliku.Sun, 27 Dec 2009 01:11:22 +0100http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1481295http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1481326Jeśli chodzi o aktualność, to cóż... Ostatnia wersja faktycznie jest ze września zeszłego roku. Szybki rzut oka na błędy pokazuje, że niewiele jest otwartych i są świeżo zgłaszane. Rzut oka do SVN wypada gorzej - tylko jeden commitujący (nie lubię jednoosobowych projektów, zwł. związanych z security), co prawda ostatnie commity z tego miesiąca, ale blisko roczna przerwa. Co prowadzi do szybkiego wniosku, że projekt jest dojrzały, ale raczej na wymarciu i nie można spodziewać się nowych funkcjonalności. Z drugiej strony, znam parę osób, które z tego korzystają i chwalą, obecna funkcjonalność jest b. ciekawa, a sama architektura jest taka, że większe zmiany raczej nie będą potrzebne. Czyli encfs wygląda na używalny minimum przez najbliższe 3-5 lat.Sun, 27 Dec 2009 11:14:16 +0100http://rozie.jogger.pl/2009/06/17/szyfrowanie-danych-w-linuksie-encfs/#c1481326