You are not logged in.
Hello,
I'm going to buy a new laptop and i'd like to install Archlinux into it.
Ubuntu 9.10 gives you the choice to encrypt your home directory during installation.
Is it possible to do the same with Arch?
I read the WIKI about encryptions and it looks pretty "hard" to do it...?
Thanks in advance for your answers!
Offline
Its not hard, is very easy! The wiki have info about the method I use Luks and dm-crypt http://wiki.archlinux.org/index.php/LUKS
Offline
Ubuntu 9.10 gives you the choice to encrypt your home directory during installation. Is it possible to do the same with Arch?
Ubuntu encrypted $HOME is done with eCryptfs, which is possible to setup in Arch but not during the installation.
There is a guide that explains how to do it. I wrote it after spending a lot of time with the Ubuntu eCryptfs developer, and I tried to make the setup as close as possible as it is in Ubuntu. If you only want an ecrypted ~/Private directory (also same as in Ubuntu) there is a guide for that too.
eCryptfs and $HOME on Arch
eCryptfs and ~/Private on Arch
You need to install an RTFM interface.
Offline
Its not hard, is very easy! The wiki have info about the method I use Luks and dm-crypt http://wiki.archlinux.org/index.php/LUKS
that information is outdated. Since 2009.08 you can do encryption and lvm with the arch installer.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
that information is outdated. Since 2009.08 you can do encryption and lvm with the arch installer.
I did not see that while installing - the encrypted $HOME with ecryptfs I mean.
Did I overlook it?
(I used the netinstall.iso)
anyway - with the help of the two guides mentioned by anrxc (and another post on the subject here in the forums) I got it working.
After setting up a group "ecryptfs", adding the user to it, then having the PAM-Rules ready and the ecryptfs module loaded it was then as simple as typing:
ecryptfs-migrate-home -u $USER
The PAM-Rules as they are now:
/etc/pam.d/login
#%PAM-1.0
auth required pam_securetty.so
auth requisite pam_nologin.so
auth required pam_unix.so nullok
auth optional pam_ecryptfs.so unwrap
auth required pam_tally.so onerr=succeed file=/var/log/faillog
# use this to lockout accounts for 10 minutes after 3 failed attempts
#auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog
account required pam_access.so
account required pam_time.so
account required pam_unix.so
#password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password optional pam_ecryptfs.so
#password required pam_unix.so md5 shadow use_authtok
session required pam_unix.so
session optional pam_ecryptfs.so unwrap
session required pam_env.so
session required pam_motd.so
session required pam_limits.so
session optional pam_mail.so dir=/var/spool/mail standard
session optional pam_lastlog.so
/etc/pam.d/gdm
#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_env.so
auth required pam_unix.so
auth optional pam_ecryptfs.so unwrap
auth optional pam_gnome_keyring.so
account required pam_unix.so
session required pam_limits.so
session required pam_unix.so
session optional pam_ecryptfs.so unwrap
session optional pam_gnome_keyring.so auto_start
password required pam_unix.so
password optional pam_ecryptfs.so
Seems to work well so far - only compiling software from AUR has failed sometimes - maybe some mount-options not suitable for "fakeroot"?
I just put the build-directory outside of the encrypted $HOME and symlinked to it - then it worked.
...my first 4 days with ARCH - coming from Gentoo, which I used solely for at least the last 4 years - and I like it and intend to stay with it
I did try Mint (Ubuntu) - thats how I came to want to have my $HOME encrypted with ecryptfs.
But I was not quite happy with it and now I'm here with ARCH.
Cheers
Last edited by jomen (2010-03-18 03:11:06)
Offline
Dieter@be wrote:that information is outdated. Since 2009.08 you can do encryption and lvm with the arch installer.
I did not see that while installing - the encrypted $HOME with ecryptfs I mean.
Did I overlook it?
(I used the netinstall.iso)
Well, the installer does encryption with dm_crypt (luks), not with ecryptfs.
you will see the dm_crypt options if you do manual partitioning and filesystems.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
Well, the installer does encryption with dm_crypt (luks), not with ecryptfs.
you will see the dm_crypt options if you do manual partitioning and filesystems.
Thanks - I knew and saw that one, but I specifically wanted to use ecryptfs instead.
Now I do
Cheers
Offline
Hmmm. this is new to me. Looks nice.
http://ecryptfs.sourceforge.net/ecryptf … ml#compare
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
Seems to work well so far - only compiling software from AUR has failed sometimes - maybe some mount-options not suitable for "fakeroot"?
Please provide more information. You know that using -i when mounting will mount with noexec (and nosuid, nodev)? If that is your problem you can add exec to your fstab entry for encrypted home.
You need to install an RTFM interface.
Offline
Please provide more information. You know that using -i when mounting will mount with noexec (and nosuid, nodev)? If that is your problem you can add exec to your fstab entry for encrypted home.
I don't have an fstab entry - I just did the changes to PAM you see above.
The wiki (mostly by you - thank you for that) mentions changes to
/etc/security/pam_mount.conf.xml
to change default mount options.
I should try that I suppose?
I also suppose it wouldn't work on
~/.pam_mount.conf.xml
since it is inside the encrypted directory.
I worked around the problem by symlinking the build-directory to a non-encrypted directory outside of my $HOME and did not bother further until now.
May I ask what is meant by:
To avoid wasting time needlessly unwrapping the passphrase...
in the wiki?
What good does it do?
Thanks and Cheers
Offline
I worked around the problem by symlinking the build-directory to a non-encrypted directory outside of my $HOME and did not bother further until now.
My main concern is that there is a bug in eCryptfs, so I wanted to know what exactly did not work, where there any segfaults and so on.
I don't have an fstab entry - I just did the changes to PAM you see above.
Since you must mount somehow, and you are not doing it your self (?), and you are not using pam_mount (?) that only leaves one possibility - eCryptfs PAM module mounts for you. In that case it is very likely your home was mounted with nosuid,noexec,nodev (and likely reason you had problems building packages).
The wiki (mostly by you - thank you for that) mentions changes to
/etc/security/pam_mount.conf.xml
to change default mount options.
I should try that I suppose?
I didn't write that part, but it's simple, that section describes using the pam_mount package for automatic mounting. If you did not install pam_mount, do not use it... don't concern your self with that section.
May I ask what is meant by:
To avoid wasting time needlessly unwrapping the passphrase...
in the wiki? What good does it do?
The author probably wanted to save (mili)seconds in situations when your home is already mounted (was not unmounted when your previous session ended), or when it is not but your key is still in the keyring (the ecryptfs_unlink_sigs option was not enabled).
You need to install an RTFM interface.
Offline
My main concern is that there is a bug in eCryptfs, so I wanted to know what exactly did not work, where there any segfaults and so on.
no segfaults or such - it was only related to default mount options
There where no problems apart from that.
(...aside from "trackerd", which was quite often using about 100% CPU - will see if having its database now in unencrypted storage actually changes that...)
...that only leaves one possibility - eCryptfs PAM module mounts for you. ...
That was the way I went.
Since I did not really understand what the documentation on ecryptfs had to say on changing the default mount options ... and was annoyed not even being able to start a shell-script from somewhere in $HOME ... I just reverted it to unencrypted - will maybe do it later again and until then only use an encrypted directory inside $HOME
Thank you for the other explanations.
Cheers
Offline
That was the way I went. Since I did not really understand what the documentation on ecryptfs had to say on changing the default mount options ... and was annoyed not even being able to start a shell-script from somewhere in $HOME ... I just reverted it to unencrypted
PAM module calls /sbin/mount.ecryptfs_private which is a suid executable exactly so that a user can mount without ever needing superuser priviledges to update the fstab. If you read my $HOME tutorial you know that I don't favour this way, any why.
You need to install an RTFM interface.
Offline
PAM module calls /sbin/mount.ecryptfs_private which is a suid executable exactly so that a user can mount without ever needing superuser priviledges to update the fstab.
aha
this must be (the) way Ubuntu does it, then - I don't have it running anymore to check, but I have a backup copy of the system (Linux Mint - which I tried before I opted for arch - coming from Gentoo, I might add...).
I doubt they are using default mount options.
What did they change to allow things like shellscripts in $HOME.
They are using the PAM module (I guess, I did not find any sign of the other ways described in the HOWTOS)
Actually - not even a visible mention of ecryptfs anywhere in their equivalent of /etc/pam.d/* ... like I had to do to make it (sort of) work here.
If you read my $HOME tutorial you know that I don't favour this way, any why.
actually - I did
But I must have missed that...
Are you referring to the login-passphrase usually being much weaker than the key which is unwrapped by it?
setuid to make it work - that is reason enough though not to favour it
Offline