If you are using LUKS encryption, simply use the same password for both drives.
Luks knows to try using the same password for each drive, and if that works it will not ask you again.
In my opinion, NO, not much.
Most of the config files related to your DE and such reside there in your /home/[user] dir but these are small, and usually cached in memory. Your Bulk storage of media will be fast enough for all practical purposes as well.
It makes very little sense to encrypt your system drive. Not saying it makes NO sense, just not a lot of sense, There aren't a lot of passwords stored in cleartext there, but some cached file fragments might be there in /tmp (but even these are encoded with permissions).
Also having swap on SSD (either as a partition or as a file) allows fast hibernation, as well as using the fast SSD swap space to keep as much memory free as possible. Swapping onto ssd is fast enough that you may want to make some settings adjustment to encourage swapping. Post back if interested.
So reserving the HDD for all of /home and keeping your media and other private files in there, and encrypting ONY it serves to protect your files against snooping, as well as allowing you to re-install the OS with reckless abandon, a long as you don't touch /home.
I think this way you get the most bang for your buck with a mix of SSD and HDD.
Without /home on the HDD you can treat it more like a removable device if it is easy to remove. Otherwise good points.
Changing my HDD to a SSD in my current system made a HUGE performance diffenrence, that's why I am wondering if leaving /home on a HDD would affect system performance noticably.
But there are some passwords in clearetext? Like Browser sync, Cloud storage programs like megasync or seafile?
If that's the case a full disk encryption would be needed.
The notebook comes with 16GB of RAM, I don't think the system will ever need to use the swap partition. My current system has 4GB and I never ran out of ram.
Thanks for this tip, I will take it into my consideration.
Also thought about selling both discs and buying a bigger SSD but realisticly I don't need a SSD for storing movies and so on. It's just for fast boot times and opening programs faster...
No, those are all USER specific and stored under your home drive.
Mega stores all its stuff in /home/[user]/.local/share/data/Mega Limited/MEGAsync/
because each account on the linux machine can have their own megasync account.
There might be SOME things stored /etc in some poorly configured applications, but these are either encrypted or protected by permissions.
All passwords for browsers or browser syncing are stored in your user account.
Linux is a well thought out system that was designed from the ground up with security in mind. And it was done before whole disk encryption was even a thing. If you don't give up root's password its pretty safe.
I've generally stopped encrypting my system drive. It makes recovery almost impossible when something goes wrong. I always keep /home on a separate partition or a separate drive, and that's the only think I encrypt.
From what I understand, ecrypting the system partition removes the attack vector that a local attacker can install s.th. (spyware) on your system. For example boot with a live USB and do what they want with your system.
All the user applications passwords are stored in /home/user.
I think i will do it that way. /home on the hdd and only encrypt that. Seems like a good alternative for my initial plan.
The only thing I am still wondering is: Can I use the gui installer and just "click" use second disc for /home or something similar or do I have to do the partitionig part by myself?
To avoid surprises I would always use the Manual Partitioning option. There you first selsect the SSD, then mount one of its partitions (which number can be 1) on /. Then select the HDD and mount one of its partitions on /home and click the checkbox "Encrypt".
Another tip, as you plan to have /home on a HDD. Consider using profile-sync-daemon from AUR for your browser profile. https://wiki.archlinux.org/index.php/Profile-sync-daemon
Otherwise the browser always writing and reding the HDD might feel sluggish, but I don't know if it actually will.
I did that same installation (root on SSD no encryption, home on HDD LUKS encryption) using the 17.0.1 live image earlier this year, The graphical installer can be used to encrypt the partition using LUKS but there was a small glitch where the fstab didn't have the right drive name to mount at boot but it's easy to fix if you know where to look and wouldn't give me the time to enter the encryption password (see thread: https://archived.forum.manjaro.org/t/create-encrypted-home-partition/20583 ). This issue might of been fixed with the 17.0.2 live image.
Not having your home partition on the SSD will have some impact depending on what you do with the computer, for example is the Steam library is located within your home folder (but you are also spreading the load over on 2 drives instead of the single ssd)
Before you do anything I'd read this first to make sure you understand all your options.
Could be you just need a couple of directories encrypted with something like veracrypt, instead of mulitple disk full dm-crypt encryption of both system and non system partitions.
If you do decided to go down the LUKS encryption route then make sure you read
which contain workarounds for multiple disks and only entering a single password.
Better to take the time now to read and understand the technology you are using, rather than rush in and accidently lose data down an encrypted black hole later.
What ever solution you decide to go with test it (ie make all your mistakes) on a VM install first would be my advice. Once you've worked out all the kinks and avoided all the pitfalls then commit to a bare metal install.
There is also option to do it Ubuntu style with ecryptfs. This would give you encrypted $HOME directory (not a encrypted /home partition), which automatically gets unlocked when your user logs in with their password. Not quite what you were looking for, but it's one more option to consider. Protects your user data, but not your system from being tampered with if someone has physical access.
As always, I recommend to use separate encrypted /data partition that holds your personal data.
In your case, I would put /data on the HDD and all the rest on the SSD. Then just encrypt the HDD and edit crypttab and fstab.
Then you can always put symlinks from /data into your /home folder.
ecryptfs is easier to handle though for just an encrypted /home partition, and has a more or less automatic setup routine.
Note that your (unencrypted) home might contain some private stuff, like caches and the thumbnails.
1 Is there a way you can prevent partition deletion of an encrypted partition?
2 Is there a way you can prevent disk formatting of an encrypted drive?
No, I don't think so. Why?
It's the admin's responsibility to pay attention. And the admin (i.e. root) can always do everything.
Here is a scenario.
Evil invader copies drive/partition into other medium, then replaces it with an "empty" one with same kind of encryption. Sets a pseudo passphrase and installs a program which will accept the entry of the password as a new one to replace the encrypted volume's one with the new. At the same time triggers a mechanism to record the keystrokes and communicate them to the evil party who has the actual encrypted volume and the passphrase. You can improvise by not accepting the passphrase the first time around and ask for a retry to verify it is the correct one and matches.
When the victim goes in finds an empty partition and the program has deleted itself leaving no evidence. The victim blames LUKS, the evil invader has decrypted the copy.
What I am trying to say is if it has to be encrypted it better fit in your pocket at all times, even in a ziplock while swimming or taking a bath.
Specific to this scenario is also the case of disrupting all physical networking before you enter the passphrase, and only go online when you have verified the validity of all running processes.
TBH I'm not really concerned by that scenario.
Wouldn't it be much easier to install a hidden camera somewhere in the room, pointing to the keyboard?
Or use a "bad USB" like device to intercept the keystrokes?
Or manipulate the bootloader?
I get your point, but I don't fear such a scenario.
So I have read some stuff about encryption and these are my results:
- My main concern is when my laptop gets stolen or I loose it. So an encrypted /home would be enough because all my data like photos etc. would be still safe.
- BUT since full disc encryption is really easy to do with the gui installer and does not affect performance noticably I would prefer a full disc encryption. This would also cover any scenarios where a (foreign) goverment would confiscate my laptop for example on a trip. I know this is most likely not to happen but whatever.
So I run a disc encrypted setup on my current system and had no problems with it in over 2 years. Can you please be more specific what could go wrong and why you can't recover data in that case?
Really important stuff is stored and synced in an encrypted seafile cloud (private and work), so in a case where I can't acess my drives anymore I would still be able to access these.
If I install manjaro using the gui installer and use my SSD to install the full system encrypted, how do I manage to automount the HDD which should then be also encrypted? Do I have to use the same password as the disc encryption or as the user password?
I really like the idea to have the HDD as a media storage and treat it like an external drive, but with the extra of automounting and not having to enter another password.
So what would be the difference between full disk and /home encryption in this case?
Automounting is done by fstab, decryption at boot by crypttab.
@fungilife, the category is Technical issues, not Off-topic.
There is no reason for Fttk to edit anything. He defines what attacker he sees the most relevant for his situation.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.