Size: 10909
Comment:
|
Size: 19019
Comment: fixed tags for inclusion in translated pages
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
{X} 2012-02-21: Document currently in draft, process to be re-tested on separate machine to ensure it is repeatable. = Transparent Encryption for a Home folder = The following steps have been completed on a Debian Squeeze setup to allow users on a desktop to encrypt their Home directory. === Problem Statement === Many organisations are requesting users encrypt their laptop to protect confidential information (customer names, internal contact details, etc). On many Windows systems this is problematic and intrusive. This procedure is to help Debian users configure their systems to encrypt/decrypt their Home folder auto-magically. === Process === On an up to date Debian system, install the following packages:- |
#language en ~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[it/TransparentEncryptionForHomeFolder|Italiano]]-~ ---- = Transparent Encryption For the User's Home Folder = The following steps have been completed on a fresh Debian Squeeze install to allow users on a desktop to encrypt their Home directory. <<TableOfContents()>> == Introduction == Many organisations are requesting users to encrypt their laptop to protect confidential information (customer names, internal contact details, etc.). On many Windows systems this is problematic and intrusive. This page is meant to help Debian users in configuring their systems to encrypt/decrypt their Home folder auto-magically using [[WikiPedia:EncFS|EncFS]]. == Install Debian Squeeze == The steps described in this page are based on a "Debian Live CD Gome Desktop", but any installation media should do. For more details on installing Debian, go to the [[http://www.debian.org/releases/stable/installmanual|Debian website]]. === Dummy User Account === When setting up the first user (during the installation process), I suggest you create a dummy account (e.g. "Dummy User"). This will allow the configuration to be completed for the 'real' user. === Disk Setup === For the disk setup, choose "Guided - use entire disk" or "Guided - use entire disk and setup LVM". We are NOT setting up encryption using the Debian installer method. The recommendation is to select "All files in one partition" and accept the defaults. When the installation is complete, log in with the dummy user created during the installation. This user will be able to get root privileges for the rest of the process. After installing Debian always make sure your system is up to date so run the following:{{{ aptitude update ; aptitude safe-upgrade }}} == Setup Encrypted Home Directories == Move the dummy user to a directory which is not managed by encfs (i.e. not under /home) {{{ mkdir -p /home.original/ cp -a /home/<username> /home.original/ }}} Edit `/etc/passwd` so the dummy user's home directory path is setup correctly (e.g. /home.original/<username>) Then logout and login. Remove the dummy user's old home directory: {{{ rm -rf /home/<username> }}} On an up to date Debian system, install the DebianPkg:encfs, DebianPkg:libpam-encfs, and DebianPkg:libpam-mount packages: |
Line 17: | Line 51: |
=== Update configuration files === I have pasted the contents of my configuration files as the order of the insertions into the files is important and when I set this up the articles I referred to only had the file additions. |
=== Edit the Configuration Files === I have pasted the contents of my configuration files as the order of the various entries inside the files is important and, when I set this up, the articles I referred to only had the file additions. |
Line 21: | Line 55: |
##TAG:PAM_ENCFS_START | |
Line 25: | Line 60: |
#If this is specified program will attempt to drop permissions before running encfs. | #If this is specified, program will attempt to drop permissions before running encfs. |
Line 29: | Line 64: |
#This specifies default encfs options | #This specifies the default encfs options |
Line 45: | Line 80: |
##TAG:PAM_ENCFS_END | |
Line 47: | Line 83: |
This change is required to remove the annoying message "Cannot update ICEauthority /home/(user)/.ICEauthority. The last line of this example contains the change. | This change is required to remove the annoying message "Cannot update ICEauthority /home/(user)/.ICEauthority. The last line of this example contains the change. ##TAG:PAM_ENV_START |
Line 126: | Line 163: |
##TAG:PAM_ENV_END | |
Line 128: | Line 166: |
##TAG:FUSE_START | |
Line 140: | Line 179: |
##TAG:FUSE_END | |
Line 142: | Line 182: |
##TAG:PAM_COMMONSESSION_START | |
Line 172: | Line 213: |
##TAG:PAM_COMMONSESSION_END | |
Line 174: | Line 216: |
##TAG:PAM_COMMONAUTH_START | |
Line 206: | Line 249: |
=== Create the encrypted Home folder === ! Don't reboot until you're sure everything's working! Make the following changes from a standard command line (outside of a Gnome/X-session). Log off from your Gnome Session (Quit | Log out) and switch to a VT (Ctrl-Alt-F1) Create necessary directories and set permissions (replace "username" with your username) {{{ sudo mv /home/username /home/username.original sudo mkdir -p /home/.encfs/username /home/username sudo chown username.username /home/username /home/.encfs/username }}} Create encrypted folder (Problems with Permissions? See next section) {{{ encfs -v /home/.encfs/username /home/username }}} Accept default options, or tinker with the encryption settings. I just used the default security rather than paranoid mode because paranoid mode doesn't support hard links apparently. |
##TAG:PAM_COMMONAUTH_END === Create the Encrypted Home Directory === The configuration will setup encfs for a new "real" user. Now create your "real" user and ensure they're added to the fuse group. {{{ adduser <username> usermod -aG fuse <username> }}} Move their home directory/files out of the way: {{{ mkdir /var/backups/<username_home> mv /home/<username>/.* /var/backups/<username_home>/. rmdir /home/<username> mkdir -p /home/.encfs/<username> /home/<username> chown <username>.<username> /home/.encfs/<username> /home/<username> }}} Create the encrypted directory (If you encounter problems with permissions, see the [[#permissions|Section on permissions]]): {{{ encfs -v /home/.encfs/<username> /home/<username> }}} Accept the default options, or tinker with the encryption settings. Paranoia mode works, but won't support hard links. The author has used paranoia mode successfully. |
Line 230: | Line 279: |
Copy or move your home folder into the encrypted folder. Check your disk space first as you will need to have enough free space to copy the files. {{{ rsync -a --progress /home/username.original/ /home/username/ }}} If things go wrong here you can be stuck with a system you cannot log in. You must test it before doing anything else. First, check you can run `encfs /home/.encfs/username /home/username` as a normal user (not sudo), as well as `/bin/fusermount -u /home/username`. If it does, use Ctrl-Alt-F2 to change to another VT and see if you can log in without any problems (make sure you're in the encrypted home directory!). Use Ctrl-Alt-F7 to go back to Gnome and test it there. If you're extra-paranoid, consider adding another user and test it with that user first (you'll have to manually add him to the admin and fuse groups). OK, if you're sure it works, you can reboot. If it does, log in and delete your username.original folder. ==== Permissions ==== If you get problems with permission, you might want to check this: - Can you read /etc/fuse.conf without sudo? If not, then run "sudo chgrp fuse /etc/fuse.conf" - Can you run fusermount (or /bin/fusermount) as normal user? You should test this before logging off by running encfs to mount your encrypted home directory manually. If not, run `sudo chgrp fuse /bin/fusermount` and `sudo chmod 4750 /bin/fusermount` |
Check that encrypted filesystem is mounted correctly: {{{ mount }}} This should output something like the following: {{{ encfs on /home/<username> type fuse.encfs (rw,nosuid,nodev,default_permissions) }}} Move the home directory/files back: {{{ mv /var/backups/<username_home>/* /home/<username>/. }}} === Reboot === You will need to reboot to reload all the PAM libraries, etc. Now you can test if it all works with your 'real' user. If you have a problem, then you may need to login as the dummy user to resolve any issues. If everything works as expected, then simply comment out the dummy user from the password file and the shadow password file. To prove you are encrypting writes to your home directory, create a junk file in your home directory and see if there is a corresponding file in the encrypted home directory. Get the time stamp for the file, and check for files/directories created in the encrypted home directory (e.g. `/home/.encfs/<username>`). {{{ cp /etc/passwd $HOME/. ls -l /home/<username>/passwd ls -ltra /home/.encfs/<username> }}} ==== Potential issues ==== If things go wrong here you can be stuck with a system you cannot log in. You must test it before doing anything else. First, check you can run `encfs /home/.encfs/<username> /home/<username>` as a normal user (not sudo), as well as `/bin/fusermount -u /home/<username>`. If you can, use Ctrl-Alt-F2 to change to another virtual terminal and see if you can log in without any problems (make sure you're in the encrypted home directory!). Use Ctrl-Alt-F7 to go back to Gnome and test it from there. If you're extra-paranoid, consider adding another user and make a test with that user first (you'll have to manually add him/her to the admin and fuse groups). OK, now, if you're sure it all works, you can reboot. If it does, log in and delete your <username>.original directory. <<Anchor(permissions)>> == Permissions == If you get problems with permission, you might want to check these things: * Can you read /etc/fuse.conf without sudo? If not, then run "sudo chgrp fuse /etc/fuse.conf" * Can you run fusermount (or /bin/fusermount) as a normal user? You should test this before logging off by running encfs to mount your encrypted home directory manually. If not, run `sudo chgrp fuse /bin/fusermount` and `sudo chmod 4750 /bin/fusermount` |
Line 249: | Line 321: |
== Changing the User's Password == The encrypted filesystems password and the user's password are synchronised. Therefore to change the user's password, it's necessary to change their personal password with the `passwd` command: {{{ passwd }}} And change the encrypted volume's password to match: {{{ encfsctl passwd /home/.encfs/<username> }}} === Password Utility === There are some significant challenges in automating this process as the user must be able to change their own password, this requires the passwd utility to be used (as it's the only suid binary). However, it's possible to overcome this issue with the use of an expect script. Therefore install the DebianPkg:expect package: {{{ aptitude install expect }}} Then copy the following code to `/usr/local/bin/passwd`. The normal Debian user's PATH is set to execute this passwd utility before the system one in `/usr/bin`. ##TAG:PASSWD_UTILITY_START {{{#!highlight text #!/usr/bin/expect -f # # What: /usr/local/bin/passwd # When: 6/Mar/2012 # Who: Philip Jensen (partially generated by autoexpect - refer expect-dev) # Why: To keep a user's password in sync with their encfs password # which needs to be unlocked when the user logs in. set force_conservative 0 ;# set to 1 to force conservative mode even if ;# script wasn't run conservatively originally if {$force_conservative} { set send_slow {1 .1} proc send {ignore arg} { sleep .1 exp_send -s -- $arg } } # Tell the user they aren't using the real passwd utility. puts "###############################################################" puts "# #" puts "# This 'passwd' utility overrides the original. #" puts "# #" puts "# It is used to change the user's UNIX password #" puts "# as well as their encrypted file system password. #" puts "# #" puts "# The original password changing utility is /usr/bin/passwd #" puts "# #" puts "###############################################################" # Who is the user we are changing the password for. # (actually this is needed for encfsctl - see below) set user [exec whoami] puts "\nChanging password for $user. If this is incorrect press Ctrl + C\r" # Get the user's current password. send_user "\nCurrent password: " stty -echo expect_user -re "(.*)\n" set curr_password $expect_out(1,string) stty echo # Get their new password send_user "\nNew password: " stty -echo expect_user -re "(.*)\n" set new_password_one $expect_out(1,string) stty echo send_user "\nRe-enter new password: " stty -echo expect_user -re "(.*)\n" set new_password_two $expect_out(1,string) stty echo puts "\n" # Do the *NEW* passwords match? if {$new_password_one!=$new_password_two} { puts "Passwords don't match, exiting!\n" exit 2 } else { set new_password "$new_password_one" } # Debug output #puts "Changing password from: $curr_password\nto: $new_password\n" # Hide output from the screen (operate in silent mode). # Of course this may not hide any potential output from the command line. # Beware of background process watchers. log_user 0 set timeout -1 spawn /bin/sh match_max 100000 # begin changing passwords puts "\nChanging user's password." send -- "/usr/bin/passwd\r" expect -exact "/usr/bin/passwd\r Changing password for $user.\r (current) UNIX password: " send -- "$curr_password\r" # we need to handle the user entering an incorrect current password. expect { "Authentication token manipulation error" {puts "Current User password incorrect!" ; exit } "Enter new UNIX password: " { send -- "$new_password\r" } } expect -exact "Retype new UNIX password: " { send -- "$new_password\r" } expect -exact "\r passwd: password updated successfully\r" send_user "User password changed successfully." # If we get this far, changing the user's password succeeded, # therefore we can proceed to change the encfs password. puts "\nChanging encfs password." expect -exact "\$ " send -- "/usr/bin/encfsctl passwd /home/.encfs/$user\r" expect -exact "\r Enter current Encfs password\r EncFS Password: " send -- "$curr_password\r" # what if the current encfs password didn't match the current user's password # Of course now we have a very BIG problem as the transparent login won't work. # But if they've used this utility, then they should be fine. ;-) expect { "Invalid password\r" { puts "Current encfs password incorrect!" ; exit } "New Encfs Password: " { send -- "$new_password\r" } } expect -exact "\r Verify Encfs Password: " send -- "$new_password\r" expect -exact "\r Volume Key successfully updated.\r \$ " puts "Password change complete!" send -- "exit\r" expect eof }}} ##TAG:PASSWD_UTILITY_END ---- CategoryDesktop CategoryQuickIntroduction |
Translation(s): English - Italiano
Transparent Encryption For the User's Home Folder
The following steps have been completed on a fresh Debian Squeeze install to allow users on a desktop to encrypt their Home directory.
Contents
Introduction
Many organisations are requesting users to encrypt their laptop to protect confidential information (customer names, internal contact details, etc.). On many Windows systems this is problematic and intrusive. This page is meant to help Debian users in configuring their systems to encrypt/decrypt their Home folder auto-magically using EncFS.
Install Debian Squeeze
The steps described in this page are based on a "Debian Live CD Gome Desktop", but any installation media should do. For more details on installing Debian, go to the Debian website.
Dummy User Account
When setting up the first user (during the installation process), I suggest you create a dummy account (e.g. "Dummy User"). This will allow the configuration to be completed for the 'real' user.
Disk Setup
For the disk setup, choose "Guided - use entire disk" or "Guided - use entire disk and setup LVM". We are NOT setting up encryption using the Debian installer method.
The recommendation is to select "All files in one partition" and accept the defaults.
When the installation is complete, log in with the dummy user created during the installation. This user will be able to get root privileges for the rest of the process.
After installing Debian always make sure your system is up to date so run the following:
aptitude update ; aptitude safe-upgrade
Setup Encrypted Home Directories
Move the dummy user to a directory which is not managed by encfs (i.e. not under /home)
mkdir -p /home.original/ cp -a /home/<username> /home.original/
Edit /etc/passwd so the dummy user's home directory path is setup correctly (e.g. /home.original/<username>)
Then logout and login. Remove the dummy user's old home directory:
rm -rf /home/<username>
On an up to date Debian system, install the encfs, libpam-encfs, and libpam-mount packages:
aptitude install encfs libpam-encfs libpam-mount
Edit the Configuration Files
I have pasted the contents of my configuration files as the order of the various entries inside the files is important and, when I set this up, the articles I referred to only had the file additions.
/etc/security/pam_encfs.conf
#Note that I dont support spaces in params #So if your for example gonna specify idle time use --idle=X not -i X. #If this is specified, program will attempt to drop permissions before running encfs. # (will not work with --public for example) drop_permissions #This specifies the default encfs options #encfs_default --idle=1 encfs_default #Same for fuse, note that allow_root (or allow_other, or --public in encfs) is needed to run gdm/X. fuse_default allow_root,nonempty #- means match all, put any overrides over it. #if - is in username it will take source path + "/$USER", and mount to $HOME #USERNAME SOURCE TARGET PATH ENCFS Options FUSE Options #user /home/.enc/user /home/user -v,--idle=1,-test,-test2 allow_root #- /home/.enc - -v allow_other #- /home/.enc - -v allow_root - /home/.encfs - -v -
/etc/security/pam_env.conf
This change is required to remove the annoying message "Cannot update ICEauthority /home/(user)/.ICEauthority. The last line of this example contains the change.
# # This is the configuration file for pam_env, a PAM module to load in # a configurable list of environment variables for a # # The original idea for this came from Andrew G. Morgan ... #<quote> # Mmm. Perhaps you might like to write a pam_env module that reads a # default environment from a file? I can see that as REALLY # useful... Note it would be an "auth" module that returns PAM_IGNORE # for the auth part and sets the environment returning PAM_SUCCESS in # the setcred function... #</quote> # # What I wanted was the REMOTEHOST variable set, purely for selfish # reasons, and AGM didn't want it added to the SimpleApps login # program (which is where I added the patch). So, my first concern is # that variable, from there there are numerous others that might/would # be useful to be set: NNTPSERVER, LESS, PATH, PAGER, MANPAGER ..... # # Of course, these are a different kind of variable than REMOTEHOST in # that they are things that are likely to be configured by # administrators rather than set by logging in, how to treat them both # in the same config file? # # Here is my idea: # # Each line starts with the variable name, there are then two possible # options for each variable DEFAULT and OVERRIDE. # DEFAULT allows and administrator to set the value of the # variable to some default value, if none is supplied then the empty # string is assumed. The OVERRIDE option tells pam_env that it should # enter in its value (overriding the default value) if there is one # to use. OVERRIDE is not used, "" is assumed and no override will be # done. # # VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]] # # (Possibly non-existent) environment variables may be used in values # using the ${string} syntax and (possibly non-existent) PAM_ITEMs may # be used in values using the @{string} syntax. Both the $ and @ # characters can be backslash escaped to be used as literal values # values can be delimited with "", escaped " not supported. # Note that many environment variables that you would like to use # may not be set by the time the module is called. # For example, HOME is used below several times, but # many PAM applications don't make it available by the time you need it. # # # First, some special variables # # Set the REMOTEHOST variable for any hosts that are remote, default # to "localhost" rather than not being set at all #REMOTEHOST DEFAULT=localhost OVERRIDE=@{PAM_RHOST} # # Set the DISPLAY variable if it seems reasonable #DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY} # # # Now some simple variables # #PAGER DEFAULT=less #MANPAGER DEFAULT=less #LESS DEFAULT="M q e h15 z23 b80" #NNTPSERVER DEFAULT=localhost #PATH DEFAULT=${HOME}/bin:/usr/local/bin:/bin\ #:/usr/bin:/usr/local/bin/X11:/usr/bin/X11 # # silly examples of escaped variables, just to show how they work. # #DOLLAR DEFAULT=\$ #DOLLARDOLLAR DEFAULT= OVERRIDE=\$${DOLLAR} #DOLLARPLUS DEFAULT=\${REMOTEHOST}${REMOTEHOST} #ATSIGN DEFAULT="" OVERRIDE=\@ # # set the ICEAUTHORITY file location to allow GNOME to start on encfs $HOME ICEAUTHORITY DEFAULT=/tmp/.ICEauthority_@{PAM_USER}
/etc/fuse.conf
# Set the maximum number of FUSE mounts allowed to non-root users. # The default is 1000. # #mount_max = 1000 # Allow non-root users to specify the 'allow_other' or 'allow_root' # mount options. # #user_allow_other user_allow_other
/etc/pam.d/common-session
# # /etc/pam.d/common-session - session-related modules common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of modules that define tasks to be performed # at the start and end of sessions of *any* kind (both interactive and # non-interactive). # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) session [default=1] pam_permit.so # here's the fallback if no module succeeds session requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around session required pam_permit.so # and here are more per-package modules (the "Additional" block) session required pam_encfs.so session required pam_unix.so session optional pam_mount.so session optional pam_ck_connector.so nox11 # end of pam-auth-update config
/etc/pam.d/common-auth
# # /etc/pam.d/common-auth - authentication settings common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. auth sufficient pam_encfs.so auth [success=1 default=ignore] pam_unix.so use_first_pass nullok_secure #auth required pam_unix.so use_first_pass nullok_secure #auth required pam_unix.so nullok_secure use_first_pass # here are the per-package modules (the "Primary" block) #auth [success=1 default=ignore] pam_unix.so nullok_secure # here's the fallback if no module succeeds auth requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around auth required pam_permit.so # and here are more per-package modules (the "Additional" block) auth optional pam_mount.so # end of pam-auth-update config
Create the Encrypted Home Directory
The configuration will setup encfs for a new "real" user.
Now create your "real" user and ensure they're added to the fuse group.
adduser <username> usermod -aG fuse <username>
Move their home directory/files out of the way:
mkdir /var/backups/<username_home> mv /home/<username>/.* /var/backups/<username_home>/. rmdir /home/<username> mkdir -p /home/.encfs/<username> /home/<username> chown <username>.<username> /home/.encfs/<username> /home/<username>
Create the encrypted directory (If you encounter problems with permissions, see the Section on permissions):
encfs -v /home/.encfs/<username> /home/<username>
Accept the default options, or tinker with the encryption settings. Paranoia mode works, but won't support hard links. The author has used paranoia mode successfully.
SET THE PASSWORD TO BE THE SAME AS YOUR LOGIN PASSWORD
Check that encrypted filesystem is mounted correctly:
mount
This should output something like the following:
encfs on /home/<username> type fuse.encfs (rw,nosuid,nodev,default_permissions)
Move the home directory/files back:
mv /var/backups/<username_home>/* /home/<username>/.
Reboot
You will need to reboot to reload all the PAM libraries, etc.
Now you can test if it all works with your 'real' user. If you have a problem, then you may need to login as the dummy user to resolve any issues. If everything works as expected, then simply comment out the dummy user from the password file and the shadow password file.
To prove you are encrypting writes to your home directory, create a junk file in your home directory and see if there is a corresponding file in the encrypted home directory. Get the time stamp for the file, and check for files/directories created in the encrypted home directory (e.g. /home/.encfs/<username>).
cp /etc/passwd $HOME/. ls -l /home/<username>/passwd ls -ltra /home/.encfs/<username>
Potential issues
If things go wrong here you can be stuck with a system you cannot log in. You must test it before doing anything else. First, check you can run encfs /home/.encfs/<username> /home/<username> as a normal user (not sudo), as well as /bin/fusermount -u /home/<username>. If you can, use Ctrl-Alt-F2 to change to another virtual terminal and see if you can log in without any problems (make sure you're in the encrypted home directory!). Use Ctrl-Alt-F7 to go back to Gnome and test it from there.
If you're extra-paranoid, consider adding another user and make a test with that user first (you'll have to manually add him/her to the admin and fuse groups).
OK, now, if you're sure it all works, you can reboot. If it does, log in and delete your <username>.original directory.
Permissions
If you get problems with permission, you might want to check these things:
- Can you read /etc/fuse.conf without sudo? If not, then run "sudo chgrp fuse /etc/fuse.conf"
Can you run fusermount (or /bin/fusermount) as a normal user? You should test this before logging off by running encfs to mount your encrypted home directory manually. If not, run sudo chgrp fuse /bin/fusermount and sudo chmod 4750 /bin/fusermount
ref: http://wiki.geteasypeasy.com/Transparent_Encryption_for_home_folder
Changing the User's Password
The encrypted filesystems password and the user's password are synchronised. Therefore to change the user's password, it's necessary to change their personal password with the passwd command:
passwd
And change the encrypted volume's password to match:
encfsctl passwd /home/.encfs/<username>
Password Utility
There are some significant challenges in automating this process as the user must be able to change their own password, this requires the passwd utility to be used (as it's the only suid binary). However, it's possible to overcome this issue with the use of an expect script. Therefore install the expect package:
aptitude install expect
Then copy the following code to /usr/local/bin/passwd. The normal Debian user's PATH is set to execute this passwd utility before the system one in /usr/bin.
1 #!/usr/bin/expect -f
2 #
3 # What: /usr/local/bin/passwd
4 # When: 6/Mar/2012
5 # Who: Philip Jensen (partially generated by autoexpect - refer expect-dev)
6 # Why: To keep a user's password in sync with their encfs password
7 # which needs to be unlocked when the user logs in.
8
9 set force_conservative 0 ;# set to 1 to force conservative mode even if
10 ;# script wasn't run conservatively originally
11 if {$force_conservative} {
12 set send_slow {1 .1}
13 proc send {ignore arg} {
14 sleep .1
15 exp_send -s -- $arg
16 }
17 }
18
19 # Tell the user they aren't using the real passwd utility.
20 puts "###############################################################"
21 puts "# #"
22 puts "# This 'passwd' utility overrides the original. #"
23 puts "# #"
24 puts "# It is used to change the user's UNIX password #"
25 puts "# as well as their encrypted file system password. #"
26 puts "# #"
27 puts "# The original password changing utility is /usr/bin/passwd #"
28 puts "# #"
29 puts "###############################################################"
30
31 # Who is the user we are changing the password for.
32 # (actually this is needed for encfsctl - see below)
33 set user [exec whoami]
34 puts "\nChanging password for $user. If this is incorrect press Ctrl + C\r"
35
36 # Get the user's current password.
37 send_user "\nCurrent password: "
38 stty -echo
39 expect_user -re "(.*)\n"
40 set curr_password $expect_out(1,string)
41 stty echo
42
43 # Get their new password
44 send_user "\nNew password: "
45 stty -echo
46 expect_user -re "(.*)\n"
47 set new_password_one $expect_out(1,string)
48 stty echo
49 send_user "\nRe-enter new password: "
50 stty -echo
51 expect_user -re "(.*)\n"
52 set new_password_two $expect_out(1,string)
53 stty echo
54 puts "\n"
55
56 # Do the *NEW* passwords match?
57 if {$new_password_one!=$new_password_two} {
58 puts "Passwords don't match, exiting!\n"
59 exit 2
60 } else {
61 set new_password "$new_password_one"
62 }
63
64 # Debug output
65 #puts "Changing password from: $curr_password\nto: $new_password\n"
66
67 # Hide output from the screen (operate in silent mode).
68 # Of course this may not hide any potential output from the command line.
69 # Beware of background process watchers.
70 log_user 0
71
72 set timeout -1
73 spawn /bin/sh
74 match_max 100000
75
76 # begin changing passwords
77 puts "\nChanging user's password."
78
79 send -- "/usr/bin/passwd\r"
80 expect -exact "/usr/bin/passwd\r
81 Changing password for $user.\r
82 (current) UNIX password: "
83 send -- "$curr_password\r"
84 # we need to handle the user entering an incorrect current password.
85 expect {
86 "Authentication token manipulation error" {puts "Current User password incorrect!" ; exit }
87 "Enter new UNIX password: " { send -- "$new_password\r" }
88 }
89
90 expect -exact "Retype new UNIX password: " { send -- "$new_password\r" }
91 expect -exact "\r
92 passwd: password updated successfully\r"
93 send_user "User password changed successfully."
94
95 # If we get this far, changing the user's password succeeded,
96 # therefore we can proceed to change the encfs password.
97 puts "\nChanging encfs password."
98 expect -exact "\$ "
99 send -- "/usr/bin/encfsctl passwd /home/.encfs/$user\r"
100 expect -exact "\r
101 Enter current Encfs password\r
102 EncFS Password: "
103 send -- "$curr_password\r"
104
105 # what if the current encfs password didn't match the current user's password
106 # Of course now we have a very BIG problem as the transparent login won't work.
107 # But if they've used this utility, then they should be fine. ;-)
108 expect {
109 "Invalid password\r" { puts "Current encfs password incorrect!" ; exit }
110 "New Encfs Password: " { send -- "$new_password\r" }
111 }
112 expect -exact "\r
113 Verify Encfs Password: "
114 send -- "$new_password\r"
115 expect -exact "\r
116 Volume Key successfully updated.\r
117 \$ "
118 puts "Password change complete!"
119 send -- "exit\r"
120 expect eof