Annvix:User Guide/tcb
|
This page contains content from the old Annvix.org wiki and has been moved here to preserve content. These pages have been retained for historical and nostalgic purposes only. |
Using the tcb shadow alternative
The tcb package is a replacement for the traditional method of storing encrypted passwords in the /etc/shadow file. By using tcb, each user gains access to their shadow password, and their shadow password only. There is no need for a setuid root passwd program (instead it is installed setgroupid shadow). The other primary benefit of using tcb is that it uses blowfish passwords by default, rather than the more insecure (yet still widely used) md5 password.
New users who install Annvix 2.0 do not need to do anything to begin using tcb; as of 2.0-CURRENT, tcb and blowfish passwords are the default. Users upgrading from a previous version of Annvix will transparently be using tcb after executing the upgrade script that upgrades 1.2 to 2.0.
Contents |
Before the Upgrade
Before you upgrade to 2.0, be sure you have two consoles or ssh sessions open to the system you are upgrading. One should be as your regular user, the other as root (or your regular user account sudo'd to root). If you do not do this, there is a chance you could completely lock yourself out of the system until the upgrade is complete.
Next, upgrade the system as you normally would using the upgrade script (see the 2.0 release notes for more information and to obtain the upgrade script.
The next sections are largely only for those interested in understanding and tweaking the tcb defaults. If you use the upgrade script, tcb will be working on your system and you need not do anything else in order for it to work. However, if you want to change how tcb works or if you need to incorporate it with LDAP authentication, read on.
Converting /etc/shadow to the tcb format
The first step is to convert your existing shadow password entries into individual tcb entries. The tcb structure for storing passwords does not use a single file, like /etc/shadow but instead a directory structure like /etc/tcb/joe where joe is the user and joe's shadow password is stored in the file /etc/tcb/joe/shadow. To do this, you will need to execute the /sbin/tcb_convert program as root.
The resulting directory structure of /etc/tcb will look like this:
# ls -dl /etc/tcb drwx--x--- 30 root shadow 4096 Jul 6 21:23 /etc/tcb/ # ls -l /etc/tcb/ total 0 drwx--s--- 2 adm auth 19 Jul 6 21:23 adm/ drwx--s--- 2 apache auth 19 Jul 6 21:23 apache/ drwx--s--- 2 bin auth 19 Jul 6 21:23 bin/ drwx--s--- 2 builder auth 19 Jul 6 21:23 builder/ drwx--s--- 2 daemon auth 19 Jul 6 21:23 daemon/ drwx--s--- 2 halt auth 19 Jul 6 21:23 halt/ drwx--s--- 2 joe auth 19 Jul 6 21:23 joe/ drwx--s--- 2 logger auth 19 Jul 6 21:23 logger/ drwx--s--- 2 lp auth 19 Jul 6 21:23 lp/ drwx--s--- 2 mail auth 19 Jul 6 21:23 mail/ drwx--s--- 2 mysql auth 19 Jul 6 21:23 mysql/ drwx--s--- 2 news auth 19 Jul 6 21:23 news/ drwx--s--- 2 nobody auth 19 Jul 6 21:23 nobody/ drwx--s--- 2 operator auth 19 Jul 6 21:23 operator/ drwx--s--- 2 postfix auth 19 Jul 6 21:23 postfix/ drwx--s--- 2 root auth 19 Jul 6 21:23 root/ drwx--s--- 2 rpm auth 19 Jul 6 21:23 rpm/ drwx--s--- 2 rsbadmin auth 19 Jul 6 21:23 rsbadmin/ drwx--s--- 2 rsbdata auth 19 Jul 6 21:23 rsbdata/ drwx--s--- 2 rsbtpmgr auth 19 Jul 6 21:23 rsbtpmgr/ drwx--s--- 2 shutdown auth 19 Jul 6 21:23 shutdown/ drwx--s--- 2 snort auth 19 Jul 6 21:23 snort/ drwx--s--- 2 sshd auth 19 Jul 6 21:23 sshd/ drwx--s--- 2 svn auth 19 Jul 6 21:23 svn/ drwx--s--- 2 sync auth 19 Jul 6 21:23 sync/ drwx--s--- 2 syslogd auth 19 Jul 6 21:23 syslogd/ drwx--s--- 2 vcsa auth 19 Jul 6 21:23 vcsa/ # ls -l /etc/tcb/joe/ total 4 -rw-r----- 1 joe auth 58 Jul 6 21:23 shadow # cat /etc/tcb/joe/shadow joe:$2a$08$abcdefghijklmnopqrstuuz29TNT43FrbrkSgusq0SUVtGQkhH2mm:13112:0:99999:7:::
Lookups with tcb (/etc/nsswitch.conf)
When the new glibc package was installed, it either modified the existing nsswitch.conf file to use tcb shadow entries (if you never originally modified the file) or, if you did modify it (i.e. to use LDAP) then it created a new file: /etc/nsswitch.conf.rpmnew. This file contains the default entry of using tcb for shadow passwords. You will need to either copy this file over the previous file (if you did not make any changes to it), or you will need to manually edit /etc/nsswitch.conf by changing:
shadow: files nisplus nis
to:
shadow: tcb nisplus nis
Once you have made this change, the system will use nss_tcb to do lookups for shadow passwords via the tcb files.
If you are using LDAP for lookups, simply replace "files" with "tcb" on the shadow line, be it before or after the "ldap" entry.
You can test this immediately by executing, as root getent shadow and you will get a list of all the shadow entries for all the users on the system. When you verify that this works, rename /etc/shadow to /etc/shadow.bk and test it again. If it continues to work, delete the moved file and the /etc/shadow- backup file.
Authenticating with tcb (/etc/pam.d/system-auth)
To actually authenticate against tcb, you need pam_tcb installed; the upgrade will have done this for you. As with nsswitch.conf, if you made no changes to the default /etc/pam.d/system-auth file, the new pam will replace the file with calls to pam_tcb instead of pam_unix. Regardless of this change, because pam_tcb understands shadow passwords, if you choose not to convet to tcb, your existing shadow entries will continue to be read. If you have followed the instructions up to this point and have deleted the old shadow files, your system will be using tcb immediately.
If you have made changes to system-auth, you will need to merge back the changes from the newly-created system-auth.rpmnew file. Essentially, the only changes were, again, to switch from pam_unix to pam_tcb, and also switch from pam_cracklib to pam_passwdqc (a much more comprehensive password strength checking module for pam). You must, at the absolutey least, change the pam_cracklib entries because pam_cracklib is no longer shipped with Annvix. You could leave pam_unix as is, because a symlink for compatibility was created, but it is not advised.
The new system-auth file will look like this:
#%PAM-1.0 # $Id: system-auth.pamd 5743 2006-07-04 04:49:31Z vdanen $ auth required pam_env.so auth required pam_tcb.so shadow fork nullok prefix=$2a$ count=8 account required pam_tcb.so shadow fork password required pam_passwdqc.so min=disabled,12,8,6,5 max=40 passphrase=3 match=4 similar=deny \ random=42 enforce=everyone retry=3 password required pam_tcb.so use_authtok shadow write_to=tcb fork nullok prefix=$2a$ count=8 session required pam_limits.so session required pam_tcb.so
Refer to the pam_tcb and pam_passwdqc for the specifics of the options and for ways to tune them. Some notes:
- If you wish to continue using md5 passwords for some reason, you can do so by modifying the password entry to remove "prefix=$2a$ count=8" and replace it with "md5"
- If you wish to continue using /etc/shadow instead of tcb files, remove the "write_to=tcb" portion of the password entry (tcb's default is to write to the shadow file)
Once you have finished the pam modification, you should attempt to use sudo from the unprivileged account to become root. If this succeeds, do a ssh test: ssh into the machine from another machine to ensure you can login remotely. Next, if you have physical access to the system, ensure you can login at the console.
Finally, you should use the passwd program to change your password. Not only will this test to be sure that pam_tcb is properly reading from and writing to the tcb files, it will also ensure that your password is stored as a blowcrypt-based password rather than the undesirable md5-based password. If you so desire, use passwd again to re-enable your old password (although the password will be the same, it will be stored as a blowcrypt password).
tcb and LDAP Together
You can use a /etc/pam.d/system-auth file like the following to use both tcb and LDAP-based logins together (i.e. all local system accounts use tcb and remote accounts use LDAP). If your system is setup correctly to permit users to change their LDAP password with the passwd command, you can continue to permit password changes; the fact that you're now using tcb rather than the shadow password file is of no consequence. However, keep in mind that passwords will be store in the LDAP database with the pre-existing settings (so using either the crypt or md5 password formats); LDAP does not understand or use blowfish passwords.
#%PAM-1.0 # $Id: system-auth.pamd 5743 2006-07-04 04:49:31Z vdanen $ auth required pam_env.so auth sufficient pam_tcb.so shadow fork nullok prefix=$2a$ count=8 auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account sufficient pam_tcb.so shadow fork account sufficient pam_ldap.so account required pam_deny.so password required pam_passwdqc.so min=disabled,12,8,6,5 max=40 passphrase=3 match=4 similar=deny \ random=42 enforce=everyone retry=3 password sufficient pam_tcb.so use_authtok shadow write_to=tcb fork nullok prefix=$2a$ count=8 password sufficient pam_ldap.so use_authtok password required pam_deny.so session required pam_limits.so session sufficient pam_tcb.so session sufficient pam_ldap.so session required pam_deny.so
As well, /etc/nsswitch.conf will look like:
passwd: files ldap nisplus nis shadow: tcb ldap nisplus nis group: files ldap nisplus nis
You must set "tcb" before "ldap" on the shadow entry; just as you would normally do with "files" (essentially, "tcb" is identical to "files" in this context).
Tweaking /etc/login.defs
As with other configuration files, if you have changed /etc/login.defs you will need to manually merge in the changes from the login.defs.rpmnew file. Of particular interest are the following new options:
# # The password hashing method and iteration count to use for group # passwords that may be set with gpasswd(1). # CRYPT_PREFIX $2a$ CRYPT_ROUNDS 8 # # Whether to use tcb password shadowing scheme. # USE_TCB yes # # Whether newly created tcb-style shadow files should be readable by # group "auth". # TCB_AUTH_GROUP yes # # Whether useradd should create symlinks rather than directories under # /etc/tcb for newly created accounts with UIDs over 1000. See tcb(5) # for information on why this may be needed. # TCB_SYMLINKS no
If you are absolutely sure you do not want tcb support and have not enabled it thus far, you need to disable USE_TCB and if you do not want blowcrypt passwords, you should change CRYPT_PREFIX to "$1$" and comment outCRYPT_ROUNDS.
Final Considerations
The normal shadow suite tools that are used to manipulate the shadow file, such as chage, useradd, and so on have all been patched to work with the tcb system and should all work as well as they did before; the only difference is that the individual user's shadow file will be modified rather than the system-wide /etc/shadow file. Also be sure to remove the old shadow file and it's backup; it is no longer required.
We believe that tcb is another step in the right direction of providing more comprehensive system security, and we appreciate the fact that the Openwall team has done such a fantastic job both writing and providing it.
