+- Maui Forums (https://forums.mauilinux.org)
+-- Forum: Community (https://forums.mauilinux.org/forumdisplay.php?fid=7)
+--- Forum: General Talk (https://forums.mauilinux.org/forumdisplay.php?fid=80)
+--- Thread: [Closed] - Separate, encrypted, shared DATA partition. (/showthread.php?tid=24146)
[Closed] - Separate, encrypted, shared DATA partition. - kdemeoz - 4th December 2016
Question: Do any kind souls here pls have good knowledge about how to have a dedicated separate shared encrypted /DATA partition, which manages itself transparently/automatically, or "at worst" requires manual input from me via a GUI (i don't want to have to use it via CLI]? So far my interim prospective solution uses VeraCrypt. I'd be grateful for anyone's knowledgeable alternatives, or else confirmations of my current direction.
=============================================================================================
WARNING: Lots of words follow, to provide the full context of my enquiry. For anyone allergic to lots of words, pls stop reading here.
==============================================================================================
Background: As per older posts of mine here, when i first adopted Maui [1] in late Sept as my Tower's new OS, I made what in retrospect might have been an error... i formatted my separate / partition, but i retained my separate pre-existing Mint /opt & /home partitions without formatting. Whilst most of the time my Maui is just marvellous, every now & then it throws some weird wobblies [of which i've posted] that on the whole other users with clean installs don't seem to get. This has made me incrementally feel like i possibly should soon do a fully clean install on Tower, to hopefully blow away any remnant Mint configs in /home that might be causing this.
In parallel with all this, on my Lappy [upgraded also from Mint 17.3 KDE4, but ~a month before Tower, & not to Maui but to Mint 18 Xfce], Mint is increasingly annoying me with unreliable unstable WiFi misbehaviour. I've posted about this in these fora, with feedback implying that other Maui users on their own Lappies seem to enjoy good WiFi reliability. Hence i am now also considering putting Maui on Lappy in another clean install... but i don't want to blow away Mint til i prove to my own satisfaction that Maui WiFi really IS my solution.
Thus i am considering converting my single-boot Mint Lappy into a dual-boot Mint + Maui m/c, for which i want to establish a shared separate /DATA partition, which is encrypted. Whilst i intend Tower to remain single-boot Maui, i want to also create a similar separate /DATA partition on it, which is encrypted. Both pc's currently store all my non-OS personal data files, along with all the usual ~/HOME/.config directories & files, in their respective separate ecryptfs-encrypted /home partitions.
Objectives:
1. Separate dedicated /DATA encrypted partition [accessible from either Mint or Maui boot; Lappy only].
2. Clean-installed /home partition will no longer be separate, but will still be ecryptfs-encrypted during Maui installation [both PCs].
3. Mounting of /DATA encrypted partition at boot must be automatic & transparent; i don't want to have to bother with cli mounting at boot, then cli unmounting before SD.
4. During normal session, /DATA encrypted partition must do transparent on-the-fly decryption/encryption; i don't want to have to manually intervene for this.
5. My normal session & intra-session workflow must be preserved -- overnight i typically do not SD pc, but instead Suspend it, with my active docs & pgms still present on my several VDs, for seamless continuation next day after Resume. Whatever method is used for /DATA partition encryption must support this same workflow, ie, any option that needs or causes the partition to unmount prior to or during Suspend [thus closing all affected docs & pgms], is thus rejected.
6. Conversely, in case of power failure, or me forgetting to unmount said partition before a deliberate SD or reboot, the system must safely manage this itself without data loss/corruption.
Interim Prospective Solution:
1. In a Test VM in Tower, i have successfully created a single-boot Mint 18 Xfce install [similar to status currently in Lappy], then converted it to dual-boot Mint + Maui [each with non-separate ecryptfs-encrypted /home partitions], AND a shared separate /DATA partition [initially not encrypted] that is accessible from either boot OS, AND a shared separate Swap partition [ie, this Test VM comprises 4 partitions -- Swap, Mint, Maui, DATA].
2. I have researched these options to encrypt /DATA & try to meet the above-mentioned Objectives; eCryptfs, cryptsetup/luks, DM-Crypt LUKS, EncFs, VeraCrypt, GnuPG.
3. I eliminated eCryptfs as it seems to only allow an encrypted .private/Private directory-pair in /home. An Arch wiki mentions working around this by instead using ecryptfs-simple, available from AUR... but i couldn't find where to get it wrt Maui.
4. None of the others [except VeraCrypt] seemed to meet all my objectives, &/or they made my head explode as i tried to understand them.
5. With VeraCrypt i have been able to create a file container volume ["Docs & Data"] in the /DATA partition, which seems to satisfy Objectives 4, 5 & 6 [albeit after the initial boot, i do first need to mount & open this volume via the VC GUI, but thereafter it manages itself without any manual involvement needed by me].
RE: Separate, encrypted, shared DATA partition. - kdemeoz - 22nd December 2016
Well i've certainly been overwhelmed by the copious replies, but have finally finished evaluating them all.
Based on my further research & testing in my Tower VM, & my subsequent rebuild of Lappy into similar dual-boot configuration, i "un-eliminated" eCryptfs as i discovered this nice tutorial; https://www.unixmen.com/encrypt-directo ... tfs-linux/. So i've now extensively tested two alternatives, VeraCrypt vs eCryptfs, the first on a dedicated container in /DATA, the second on a dedicated directory in /DATA.
1.Neither has advantage wrt my original Objective #3, as unfortunately neither will auto-mount on boot for me. However i’ve deduced a semi-elegant & acceptable workaround via custom launchers to semi-automate the requisite CLI commands.
2.Similarly neither has advantage wrt my unpleasant & irritating discovery that every time i reboot to the other distro, i lose write-permission to /DATA & have to reinstate it via a CLI chown command. Once again however i’ve deduced a semi-elegant & acceptable workaround via custom launchers.
3.They both satisfy Objective #4; both do do transparent on-the-fly decryption/encryption once mounted in a session.
4.Again they both also satisfy Objectives #5 & #6; both do remain mounted during Suspend but auto-dismount for Reboot or power-loss.
5.VeraCrypt has notional disadvantage that i had to guess the necessary size of the encrypted container when i created it, so if in future it fills up, there is no, or no nice practical, way to extend it.
6.Conversely the eCryptFS directory in /DATA needs no advance sizing, & indeed if at some future time it fills up, i can relatively simply expand my /DATA partition with gparted, & the directory will simply grow with it.
7.Despite hours of research i’ve still not been able to conclude if one has cryptographic advantages over the other. They have structural differences by design, but these do not necessarily ipso facto denote advantage / disadvantage, to my limited understanding.
8.Whilst still not finalised, i think at this stage i am now leaning towards eCryptFS of /DATA/docsNdata, rather than the VeraCrypt container.
Does any kind reader have any corroborative or contradictory advice pls?
RE: Separate, encrypted, shared DATA partition. - kdemeoz - 26th December 2016
Well i've ended my few weeks' dalliance with dual-boot Linux distros; too many problems & logistic nuisances occurred to make it justifiable [given i much prefer Maui over Mint Xfce, persisting fighting the problems just seemed silly]. It's now back to single boot, clean-installed Maui. I did however retain the separate /DATA partition, using encrypted /DATA/docsNdata with eCryptFS. For future OS upgrades/major changes, i can now just blow away the entire / partition including /home, thus not potentially contaminating future distro versions with older user config files, but with all my actual data still intact. Project closed.