katalog na hasło bez dostępu roota
Moderatorzy: Moderatorzy, Administratorzy
katalog na hasło bez dostępu roota
Witam,
czy jest możliwość nadania hasła na jakiś katalog by nawet root nie mógł do niego wejść? Chodzi mi o to, że gdy ktoś odpali komputer z LiveCD, nie mógł mieć możliwości otwarcia konkretnego katalogu z poziomu roota, a jednocześnie ja jako użytkownik po podaniu hasła mogę do niego wejść. Chyba zakręciłam coś, ale mam nadzieję, że zrozumiecie
czy jest możliwość nadania hasła na jakiś katalog by nawet root nie mógł do niego wejść? Chodzi mi o to, że gdy ktoś odpali komputer z LiveCD, nie mógł mieć możliwości otwarcia konkretnego katalogu z poziomu roota, a jednocześnie ja jako użytkownik po podaniu hasła mogę do niego wejść. Chyba zakręciłam coś, ale mam nadzieję, że zrozumiecie
Pozdrawiam
Re: katalog na hasło bez dostępu roota
Moze jakies szyfrowanie partycji i wydzielony katalog na tej partycji ?
Re: katalog na hasło bez dostępu roota
maho, na odwrót: wydzielony katalog do montowania zaszyfrowanej partycji lub pliko-partycji.
Error 404 - footer not found
Re: katalog na hasło bez dostępu roota
to ja od razu pomoge linkiem http://linio.terramail.pl/loopaes.html i mam pytanie co do tego, zaszyfrowana partycje oczywiscie mozna normlanie usunac? I tak teoretycznie czy informacje ktore maja zostac na partycji sa szyfrowane czy normlanie zapisywane a potem jakos partycja szyfrowana, chodzi mi o to czy w sensie fizycznym informacja opisujaca jakis plik lezy dalej w jednym miejscu czy bedzie jakos rozzucona po partycji? Czy gdyby laboratoryjnie ktos chcial odzyskac dane sprawdzajac namagnetyzowanie talerzay dysku w danym moglo by mu sie udac?
imposible is nothing
Re: katalog na hasło bez dostępu roota
Szyfrowanie i deszyfrowanie odbywa się w locie. zwierzak, jak wyobrażasz sobie każdorazowe szyfrowanie kilkudziesięciu gigabajtów przy odmontowaniu? Dane z zaszyfrowanej partycji można wyciągnąć bez laboratorium. Brute force, tabletki na długowieczność i lecimy.
O szyfrowaniu było w Linux Magazine z grudnia 2006 r. i nie zalecano loop-AES-a. Jeśli już to DM-Crypt lub TrueCrypt.
O szyfrowaniu było w Linux Magazine z grudnia 2006 r. i nie zalecano loop-AES-a. Jeśli już to DM-Crypt lub TrueCrypt.
Error 404 - footer not found
Re: katalog na hasło bez dostępu roota
wiem ze mozna brutem ale tego nikt nie bedzie stosowac, pytam sie czy laboratoryjnie mozna, tak jakby dysk sie rozchermetyzowal czy uszkodzil to odpowiednie firmy oferuja takie uslugi, czy z tym jest podobnie?
imposible is nothing
Re: katalog na hasło bez dostępu roota
Jeżeli będziesz miał do czynienia z truecryptem a dostęp będzie chroniony przez plik-klucz to możesz o wszystkim zapomnieć. Takim plikiem może być np dowolny plik w formacie jpg i wtedy brutal się chowa.Lizard pisze:Brute force
Właśnie dlatego zawsze się powinno trzymać kopie na cd. Oblewasz betonem , zakopujesz w ziemi i masz spokój.zwierzak pisze:jakby dysk sie rozchermetyzowal
Szczerze wątpię, przynajmniej jeśli chodzi o kontenery truecrypt. Sam kontener ci odzyskaja bo to tylko plik ale jego zawartości chyba nie wyciągną chociaż mogę się mylić.zwierzak pisze:odpowiednie firmy oferuja takie uslugi, czy z tym jest podobnie?
Re: katalog na hasło bez dostępu roota
Dane "na wierzchu" po zaszyfrowaniu wyglądają jak binarny śmietnik. Natomiast te "pod spodem", niezaszyfrowane można odzyskać o ile nie zamazało sie ich stosowną ilość razy (3-35 powtarzając za innymi źródłami).zwierzak pisze:wiem ze mozna brutem ale tego nikt nie bedzie stosowac, pytam sie czy laboratoryjnie mozna
Lone_wolf, wyciągasz moje słowa z kontekstu:
Pisząc powyższe miałem na myśli: "przy odpowiednio długim haśle w rozsądnym czasie nie da się tą metodą uzyskać dostępu".Lizard pisze:Brute force, tabletki na długowieczność i lecimy.
Error 404 - footer not found
Re: katalog na hasło bez dostępu roota
BTW są 2 loop AES /kernelowy i rozwijany poza/...w Linux Magazine napisano o tym pierwszym, nie rozwijanym już w kernelu.Zastąpił go DM-crypt.
Drugi rozwijany jest przez Jari Ruusu nigdy nie doczekał się włączenia go do kernela. O tym w LM nie pisali.
niektórzy mówią ,że jest lepszy niż DM-crypt.
Pozdr...
Drugi rozwijany jest przez Jari Ruusu nigdy nie doczekał się włączenia go do kernela. O tym w LM nie pisali.
niektórzy mówią ,że jest lepszy niż DM-crypt.
Pozdr...
Ostatnio zmieniony 2007-08-03, 20:51 przez PITbull, łącznie zmieniany 1 raz.
Re: katalog na hasło bez dostępu roota
Niektórzy twierdzą, że Jari jako osoba, która umiała wyprowadzić atak[*] na loop-AES-a, crypt via device mappera i na cryptoloopa, wie co robi, a nie można tego do końca powiedzieć o opiekunach dm-crypta.
[*] Chodziło o FS fingerprinting, o wykrycie istnienia specjalnie spreparowanego pliku na zaszyfrowanym filesystemie.
[*] Chodziło o FS fingerprinting, o wykrycie istnienia specjalnie spreparowanego pliku na zaszyfrowanym filesystemie.
-zsh
#!/bin/bash
#!/usr/bin/perl -w
#!/bin/bash
#!/usr/bin/perl -w
Re: katalog na hasło bez dostępu roota
Wrócę do tematu , może komuś się przyda ten przydługi post.
1. Tak. Zgadzam się z Dozzie . Mówimy tu o tzw. wiarygodności implementacyjnej.Developerom jądra nie udawało sie to dobrze z kernelowym loopaes'em , a Jarii , który darł koty z nimi wykazywał ich błędy.Nie kochają go za to.
Pytanie jest takie: czy postawić na ludzi którym nie udało sie zaimplementować prawidłowo szyfrowania w przeszłości . Tutaj plus dla Jarii i loop-AES.To jest podstawa dla której wybrałbym to rozwiązanie.
2. Siła szyfrowania i jej słabości w obu przypadkach są podobne jeśli nie takie same.Oba szyfry stosują szyfrowanie blokowe CBC ESSIV .Na pytanie dlaczego nie zrezygnowć z jego loop-AES na rzecz dm-crypt skoro zapewnia ono już taką samą funkcjonalność/proszę zauważyć która do której dokoptowuje/ Jari odpowiada, że chyba nie do końca
http://groups.google.com/group/nlo.list ... 9d3b80d5e2
3. Kompatybilność w dół do jądra 2.2 plus dla loop-aes.
4. Łatwość w zastosowaniu dzięki rozwojowi razem z jadrem jest po stronie dm-crypt ,ale czy wiąże się to z bezpośrednio z pytaniem czy jest bezpiecznie???
Uważam ,że artykuł LM nie jest do końca obiektywny.
a) benchmarki -OK potwierdzają to inne artykuły
b) brak iteracjii ,ale nie brak "salt" hasła jest prawdą, ale tylko częściową i sprzed dobrych kilku lat. Autor nie dodaje już że ,Jari zamiast rozwijać ,zrezygnował z własnej implementacji polityki z kluczami kryptograficznymi na rzecz połączenia tego z GPG. A ta implementacja ma swoją renomę /sadzę ,że lepszą niż LUKS/ więc zarzut jest zupełnie bezpodstawny.
Obecnie nawet hasło z czystym tekstem w pliku GPG jest dostatecznie bezpieczne więc powoływanie się na ilość obsługiwanych haszy przez dm-crypt z punktu widzenia bezpieczeństwa jest bezpodstawne.
Zastanawiam się jak jest z kluczami w momencie gdy loop lub dm-crypt jest aktywny.
Są na pewno ładowane do pamięci RAM .GPG może zdaje się umieścić je w chronionej pamięci , a w dm-crypt nie piszą czy jest możliwość ich wyłuskania i jakie są mechanizmy ich ochrony.
c) co do braku obsługi innych algorytmów niż AES. Obsługuje jeszcze twofish, blowfish, serpent. A więc te najlepsze.
Dm-crypt obsługuje wsystkie z jadra. Ale trudno ,żeby nie obsługiwał skoro jest oficjalnie w jądrze:-)To chyba oczywiste ,ale przedstawianie tego jako plus w artykule.Chodzi o jakość czy ilość?
d)co do jakości kodu -nie mam zdania,nie jestem programistą.Ale wnosząc ,że autor raczej nieżetelnie napisał artykuł .Co mogę sądzić?????
e) łatwość zastosowania- no wszak jest oficjalnie w jądrze, więc jak ma być gorzej niż loop-Aes. Jeśli kogoś przeraża "straszliwa" kompilacja modułu jądra niech używa Dm-crypt.
Nie namawiam nikogo , ale stawiam na to co było dobre w przeszłości. Jeżeli developerzy wykażą się taką samą historią i znajomością tematu zmienię zdanie. Osobiście uważam ,że te dwa zastosowania są dobre ze wskazaniem na loop-Aes.
Jedyne co moge zarzucić to czy sam mechanizm loop się już nie zestarzał,ale może jest jak wino:-)
Mówią że opisywany w artykule Truecrypt jest od nich lepszy /rock solid/.ale już jeśli się nie mylę nie darmowy.
Pozdr...
[ Komentarz dodany przez: Lizard: 2007-08-27, 21:28 ]
Podawaj aktywne linki. Dzięki temu zostaną skrócone i łatwiej w nie kliknąć.
1. Tak. Zgadzam się z Dozzie . Mówimy tu o tzw. wiarygodności implementacyjnej.Developerom jądra nie udawało sie to dobrze z kernelowym loopaes'em , a Jarii , który darł koty z nimi wykazywał ich błędy.Nie kochają go za to.
Pytanie jest takie: czy postawić na ludzi którym nie udało sie zaimplementować prawidłowo szyfrowania w przeszłości . Tutaj plus dla Jarii i loop-AES.To jest podstawa dla której wybrałbym to rozwiązanie.
2. Siła szyfrowania i jej słabości w obu przypadkach są podobne jeśli nie takie same.Oba szyfry stosują szyfrowanie blokowe CBC ESSIV .Na pytanie dlaczego nie zrezygnowć z jego loop-AES na rzecz dm-crypt skoro zapewnia ono już taką samą funkcjonalność/proszę zauważyć która do której dokoptowuje/ Jari odpowiada, że chyba nie do końca
Szczegóły tutaj:> Since then, dm-crypt has obviously caught up.
No it has not. Loop-AES still has stronger and better IV computation, and
multi-key mode that reduces amount of data encrypted with one encryption
key.
Try modifying last byte of 512 byte sector, and observe how many 128 bit
ciphertext blocks change; loop-AES: 32, dm-crypt: 1
http://groups.google.com/group/nlo.list ... 9d3b80d5e2
3. Kompatybilność w dół do jądra 2.2 plus dla loop-aes.
4. Łatwość w zastosowaniu dzięki rozwojowi razem z jadrem jest po stronie dm-crypt ,ale czy wiąże się to z bezpośrednio z pytaniem czy jest bezpiecznie???
Uważam ,że artykuł LM nie jest do końca obiektywny.
a) benchmarki -OK potwierdzają to inne artykuły
b) brak iteracjii ,ale nie brak "salt" hasła jest prawdą, ale tylko częściową i sprzed dobrych kilku lat. Autor nie dodaje już że ,Jari zamiast rozwijać ,zrezygnował z własnej implementacji polityki z kluczami kryptograficznymi na rzecz połączenia tego z GPG. A ta implementacja ma swoją renomę /sadzę ,że lepszą niż LUKS/ więc zarzut jest zupełnie bezpodstawny.
Obecnie nawet hasło z czystym tekstem w pliku GPG jest dostatecznie bezpieczne więc powoływanie się na ilość obsługiwanych haszy przez dm-crypt z punktu widzenia bezpieczeństwa jest bezpodstawne.
Zastanawiam się jak jest z kluczami w momencie gdy loop lub dm-crypt jest aktywny.
Są na pewno ładowane do pamięci RAM .GPG może zdaje się umieścić je w chronionej pamięci , a w dm-crypt nie piszą czy jest możliwość ich wyłuskania i jakie są mechanizmy ich ochrony.
c) co do braku obsługi innych algorytmów niż AES. Obsługuje jeszcze twofish, blowfish, serpent. A więc te najlepsze.
Dm-crypt obsługuje wsystkie z jadra. Ale trudno ,żeby nie obsługiwał skoro jest oficjalnie w jądrze:-)To chyba oczywiste ,ale przedstawianie tego jako plus w artykule.Chodzi o jakość czy ilość?
d)co do jakości kodu -nie mam zdania,nie jestem programistą.Ale wnosząc ,że autor raczej nieżetelnie napisał artykuł .Co mogę sądzić?????
e) łatwość zastosowania- no wszak jest oficjalnie w jądrze, więc jak ma być gorzej niż loop-Aes. Jeśli kogoś przeraża "straszliwa" kompilacja modułu jądra niech używa Dm-crypt.
Nie namawiam nikogo , ale stawiam na to co było dobre w przeszłości. Jeżeli developerzy wykażą się taką samą historią i znajomością tematu zmienię zdanie. Osobiście uważam ,że te dwa zastosowania są dobre ze wskazaniem na loop-Aes.
Jedyne co moge zarzucić to czy sam mechanizm loop się już nie zestarzał,ale może jest jak wino:-)
Mówią że opisywany w artykule Truecrypt jest od nich lepszy /rock solid/.ale już jeśli się nie mylę nie darmowy.
Pozdr...
[ Komentarz dodany przez: Lizard: 2007-08-27, 21:28 ]
Podawaj aktywne linki. Dzięki temu zostaną skrócone i łatwiej w nie kliknąć.
Ostatnio zmieniony 2007-08-27, 20:27 przez PITbull, łącznie zmieniany 1 raz.
Re: katalog na hasło bez dostępu roota
Gwoli ścisłości, loop-AES nigdy do kernela nie został włączony.PITbull pisze:Developerom jądra nie udawało sie to dobrze z kernelowym loopaes'em ,
O ilość, przecież to widać. Rijndael został uznany za standard przemysłowy. Administrator na ogół nie jest w stanie poprawnie wybrać potrzebnego algorytmu, gdy postawi się przed nim kilka; w końcu nie jest i nie powinien być krytpologiem. Tak więc to żadna zaleta.PITbull pisze:c) co do braku obsługi innych algorytmów niż AES. Obsługuje jeszcze twofish, blowfish, serpent. A więc te najlepsze.
Dm-crypt obsługuje wsystkie z jadra. Ale trudno ,żeby nie obsługiwał skoro jest oficjalnie w jądrze:-)To chyba oczywiste ,ale przedstawianie tego jako plus w artykule.Chodzi o jakość czy ilość?
dm-crypt też wymaga kompilacji modułu. loop-AES potrzebuje wsparcia w postaci patcha na util-linux, więc jeśli ktoś nie ma Slackware, że nie może skorzystać z gotowego załatanego pakietu (xslack), to musi sobie poradzić sam. To jest główny drawback.PITbull pisze:e) łatwość zastosowania- no wszak jest oficjalnie w jądrze, więc jak ma być gorzej niż loop-Aes. Jeśli kogoś przeraża "straszliwa" kompilacja modułu jądra niech używa Dm-crypt.
O ile wiem, to jest darmowy, tylko nie da się tworzyć nowych woluminów pod Linuksem.PITbull pisze:Mówią że opisywany w artykule Truecrypt jest od nich lepszy /rock solid/.ale już jeśli się nie mylę nie darmowy.
-zsh
#!/bin/bash
#!/usr/bin/perl -w
#!/bin/bash
#!/usr/bin/perl -w
Re: katalog na hasło bez dostępu roota
Eee no, z tego co pamiętam to da się tworzyć woluminy:
http://jakilinux.org/howto/truecrypt-pr ... yfrowanie/
http://jakilinux.org/howto/truecrypt-pr ... yfrowanie/
Re: katalog na hasło bez dostępu roota
Nie napisałem, że kiedykolwiek został włączony.Małe nieporozumienie.loop-aes kernelowe /inaczej- cryptoloop/ i Loop-AES Jari to dwie różne rzeczy.PITbull napisał/a:Gwoli ścisłości, loop-AES nigdy do kernela nie został włączony.Developerom jądra nie udawało sie to dobrze z kernelowym loopaes'em ,
OK.Tak jest.PITbull napisał/a:e) łatwość zastosowania- no wszak jest oficjalnie w jądrze, więc jak ma być gorzej niż loop-Aes. Jeśli kogoś przeraża "straszliwa" kompilacja modułu jądra niech używa Dm-crypt.
dm-crypt też wymaga kompilacji modułu. loop-AES potrzebuje wsparcia w postaci patcha na util-linux, więc jeśli ktoś nie ma Slackware, że nie może skorzystać z gotowego załatanego pakietu (xslack), to musi sobie poradzić sam. To jest główny drawback.
Jeszcze parę wątków z listy dyskusejnej na temat dm-crypt vs. loop-AES z tego roku niestety po angielsku /dla ciekawych tematu/.
W skrócie Jari wykazuje krok po kroku wycieki /leak/ informacji w trakcie kolejnych iteracji implementacji szyfrowania CBC ESSIV w dm-crypt.W całym wątku jest też kilka innych informacji.
link1
link2
Pozdr..
PS.Lizard -zbyt rzadko pisze...