Halihow,
egy (számomra) kemény dió feltörésében kérném nagyrabecsült közreműködéseteket.
:)
Egy olyan fájl-transzfert kellene összeraknom, ami külső és belső szolgáltatások között csücsül a DMZ-ben és a szolgáltatások közti fájlcserét biztosítja úgy, hogy:
1. a kommunikáció titkosított (kizárólag SSH/SFTP!!),
2. a fájlok tárolása titkosított,
3. a fájlokhoz titkosítatlan formában nem fér hozzá az illetékeseken kívül senki (root se),
4. csak egyszeres hitelesítés (kizárólag ssh kulcs!!) van,
5. egy transzfer tárolóhoz több júzernek kell hozzáférnie (pl. egyik feltölt valamit, a másik letölti ugyanazt).
Jelszó használatával sikerült készre csinálni a szervert (pam-encfs/pam-script használatával), de az ssh kulccsal jelenleg nem tudok megbirkózni (sftp kapcsolat nem tud jelszót "beírni"). Próbáltam a CrushFTP-t is, ami első ránézésre mindent tud, de a gpg kulcs helyi tárolása megborítja a 3. pontot.
Én szeretném ezt Linux alatt megvalósítani, de bármilyen más OS-re és bármilyen sw környezetre vonatkozó ötletet szívesen látok, tényleg!!!
üdv.,
g
update: a saját tapasztalatom és a lenti hozzászólások alapján ez a kérés megoldhatatlannak tűnik, köszönöm a hozzászólásokat!
Hozzászólások
"3. a fájlokhoz titkosítatlan formában nem fér hozzá az illetékeseken kívül senki (root se),"
Ezt az encfs nem tudja.
"4. csak egyszeres hitelesítés (kizárólag ssh kulcs!!) van"
Ezt nem egeszen ertem, akkor itt a file-okat ssh kulccsal titkositva szeretned tarolni?
Az kovetelmeny, hogy file-ok nem tunhetnek el/duplazodhatnak meg eszrevetlenul?
--
"You're NOT paranoid, we really are out to get you!"
De, a 3-as ponthoz direkt jó lenne az encfs, mert userspace-ben fut és megfelelően felcsatolva csak a tulajdonos számára látható, még a root sem fér hozzá. Persze a több felhasználós működés miatt kell egy kicsit trükközni vele (konkrétan az encfs leíró XML-t kell "klónozni" a különböző felhasználók számára és egyedivé tenni a bennük tárolt jelszót), de ez a módszer azon bukik meg, hogy csak jelszóval lehet nyitni, ami az általam leírt hitelesítési folyamatban nem jelenik meg sehol.
Nem, bármi szóba jöhet, de a kliens SFTP-n keresztül rakja fel vagy olvassa a fájljait és a hitelesítés kizárólag kulccsal történhet, a jelszó kizárva!
Gondolom ez mindenhol követelmény! :)
De, a 3-as ponthoz direkt jó lenne az encfs, mert userspace-ben fut és megfelelően felcsatolva csak a tulajdonos számára látható, még a root sem fér hozzá.
Bocs, de ehhez nem értesz eléggé. Az a processz, ami a gépen fut, az a root felügyelete alatt áll. Ergó a root azt tesz a processz "tartalmával", amit csak akar. Bármikor megállíthatja, megnézheti a memóriáját, debuggolhatja, stb. Tehát ha egy kulcs egy processzben megtalálható, akkor azt a root ki is tudja belőle verni.
Kedves vl, ebben tökéletesen igazad van, de jelen esetben ennyire nem kell elrejteni az információt, tökéletesen elég, ha fájl szinten hozzáférhetetlen.
Na most akkor kovetelmeny a 3-as, vagy nem? :)
"Gondolom ez mindenhol követelmény! :)"
Egyaltalan nem, es pl. ha tobb producer-ed / consumer-ed van, akkor eleg bonyolult megoldani.
--
"You're NOT paranoid, we really are out to get you!"
a vl-nek adott válaszomban leírt módon mindenképp! :)
encfs-sel az se fog menni, hogy "csak fájl szinten ne látszódjon".
De továbbra is azt gondolom, hogy a problémának pont a lényegét nem érted.
Az alap problema az, hogy ha az SSH-n keresztul titkositas nelkul mennek at a fajlok, akkor a rendszergazda hozza fog tudni ferni, legrosszabb esetben a memoriabol. Ergo, ha tenyleg komolyan van ez gondolva, akkor a vegponton, feltoltes elott kell titkositani.
--
Pásztor János
Üzemeltető Macik
igen, legvégső esetben ez lesz, de így a végpontokra kell bízni a ki/be titkosítást, amit pont el szeretnék kerülni. Bár ezt egyre reménytelenebbnek látom...
El kell donteni, hogy kell-e a titkositas vagy nem kell? Illetve mi a threat vector, azaz ki ellen akarsz vedekezni? Aki total balf*, annak ugyse lesz root joga, aki meg komolyan meg akarja nezni, az meg fogja tudni nezni. Ugyanaz a jatek, mint a titkositott e-mail szolgaltatoknal. Ha a vegponton nem titkositod, akkor onnantol felejtos a jatek.
--
Pásztor János
Üzemeltető Macik
a dolog annyiban egyszerű, hogy lefektetett szabályok szerint kell kialakítani a szervert. Ezeket a szabályokat az indító hozzászólásomban leírtam és most azzal kiegészíteném, hogy "a szerveren folyó kommunikációt és a tárolt adatokat titkosítani kell". Ez egy általános érvényű policy és ezért -- mert egyszerűen nincs szükség rá -- nem foglalkoztam a vl által leírtakkal, noha tudatában vagyok azoknak, a későbbi üzemeltetők személyére és hozzáértésére (felügyeletére?) pedig nem vagyok hatással.
Ezzel együtt is igazad van és kénytelen vagyok belátni, hogy még ezen a (policy által leírt viszonylag gyenge) szinten sem lehetséges megoldani a leírt problémát. A jelszavas encfs megoldást az buktatja, hogy a mount folyamán a root su-val képes olvasni a fájlokat titkosítatlanul, mert bár a kommunikáció után lehet automatikus umount-t kikényszeríteni, a mount-umount között eltelt időben a fájlok a júzer és a"besúzott" root számára is elérhetőek.
És persze köszönöm az észrevételeiteket, így hamarabb értem a végére a témának, marad a végponti gpg ki/betitkosítás.
:)
A vegponti gpg-zes sem biztositja azt, hogy a file-ok eszrevetlenul nem tuntethetoek el / nem duplazhatoak meg.
Feliratkozas
Kb ezt tudom elképzelni:
- Legyen egy user: crypshare (jelsóval nem tud bejelentkezni, mivel meg van neki pam -ban tiltva)
- A cryptuser $HOME -ja LUKS -al titkostva van.
- A $HOME/share könyvtárat joska, pista, miska sshfs -el felmountolja ssh-agent segtségével, kulcsal azonositja magát
Arra érdemes, oda figyelni, hogy a cryptshare usernek ne legyen loginja és shell -je (asszem shell nélkül is megy a LUKS) és a kulcsokat ne a ~/.ssh/authorized_keys fileban tartsd
[update1]
Nyilván ettől még a file transfer -kor elcsphető a file és nyilván memóriából is ki lehet olvasni, bár ennél egyszerűbb joska -t vagy pistát esetleg miskát megkérni, hogy emailezzen egy másolatot ... :-/
----
올드보이
http://molnaristvan.eu/
A LUKS mountoláshoz honnan fog "megnőni" a jelszó, amit a LUKS kér? Valaki bepötyögi, vagy fájlban van letárolva?
git annex nem jatszik? igaz, ahhoz legalabb ket hitelesites kell, hogy a fileok titkositottan legyenek tarolva... (ssh kulcs + gpg kulcs)
--
|8]
2. a fájlok tárolása titkosított
Ezzel az a baj, hogy ha a szerver végzi a titkosítást, akkor esélyesen amikor jön a (másik) kliens, hogy elvigye az állományt, akkor a szervernek kell elvégeznie a dekódolást is. Ha a szerveren fent van a rutin, amellyel dekódolható az állomány, akkor innen kezdve már nem akadályozható meg a root abban, hogy némi idő ráfordítása árán előcsalogassa a nyers adatokat.
Ha a titkosítást a kliens végzi, akkor viszont már magának a kommunikációs csatornának sem feltétlenül kell titkosítottnak lennie - viszont ezen a ponton a végpontok feladata az egyszerű scp/sftp helyett lényegesen bonyolultabbá válik és persze meg kell oldani a titkos kulcsok cseréjét is.
Esetleg olyan megoldás, hogy GPG/PGP? Ekkor minden kliensnek van egy saját privát/publikus kulcspárja, illetve letöltheti bárki publikus kulcsát. Innen kezdve kliens oldalon két scripttel megoldható lenne a teljes feladat:
- küldés esetén a script paramétere a file és a "címzett" neve. A név alapján megvan a publikus kulcs, ezzel a file kódolható, majd a kódolt állomány a címzett könyvtárába másolható - akár scp-vel
- fogadás esetén a saját könyvtárból scp-vel elhozható a file, ami a saját privát kulccsal dekódolható is.
Extra feature: ha a címzett publikus kulcsa nincs meg, akkor az egy fix helyről elhozható.