diff --git a/handbook/ctm.sgml b/handbook/ctm.sgml index cfc2f35214..4339f91561 100644 --- a/handbook/ctm.sgml +++ b/handbook/ctm.sgml @@ -1,266 +1,261 @@ CTM

Contributed by &a.phk;. Updated 19-October-1997. Why should I use

. What do I need to use

You will need two things: The ``/usr/src/usr.sbin/ if you have a copy of the source online. If you are running a pre-2.0 version of FreeBSD, you can fetch the current The ``deltas'' you feed or see section . FTP the relevant directory and fetch the /etc/aliases if you want to have the process run in a fully automated fashion. Check the Starting off with

Before you can start using Using

To apply the deltas, simply say: cd /where/ever/you/want/the/stuff ctm -v -v /where/you/store/your/deltas/src-xxx.*

Keeping your local changes

As a developer one would like to experiment with and change files in the source tree. CTM supports local modifications in a limited way: before checking for the presence of a file foo, it first looks for foo.ctm. If this file exists, CTM will operate on it instead of foo.

This behaviour gives us a simple way to maintain local changes: simply copy the files you plan to modify to the corresponding file names with a .ctm suffix. Then you can freely hack the code, while CTM keeps the .ctm file up-to-date. Other interesting CTM options Finding out exactly what would be touched by an update

You can determine the list of changes that CTM will make on your source repository using the ``-l'' option to CTM.

This is useful if you would like to keep logs of the changes, pre- or post- process the modified files in any manner, or just are feeling a tad paranoid :-). Making backups before updating

Sometimes you may want to backup all the files that would be changed by a CTM update.

Specifying the ``-B backup-file'' option causes CTM to backup all files that would be touched by a given CTM delta to backup-file. Restricting the files touched by an update

Sometimes you would be interested in restricting the scope of a given CTM update, or may be interested in extracting just a few files from a sequence of deltas.

You can control the list of files that CTM would operate on by specifying filtering regular expressions using the ``-e'' and ``-x'' options.

For example, to extract an up-to-date copy of lib/libc/Makefile from your collection of saved CTM deltas, run the commands: cd /where/ever/you/want/to/extract/it/ ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.*

For every file specified in a CTM delta, the ``-e'' and ``-x'' options are applied in the order given on the command line. The file is processed by CTM only if it is marked as eligible after all the ``-e'' and ``-x'' options are applied to it. Future plans for

Tons of them: Use some kind of authentication into the CTM system, so as to allow detection of spoofed CTM updates. Clean up the options to The bad news is that I am very busy, so any help in doing this will be most welcome. And do not forget to tell me what you want also... Miscellaneous stuff

All the ``DES infected'' (e.g. export controlled) source is not included. You will get the ``international'' version only. If sufficient interest appears, we will set up a `` There is a sequence of deltas for the Thanks!

diff --git a/handbook/kerberos.sgml b/handbook/kerberos.sgml index 37e1bcd2d6..38a380fff6 100644 --- a/handbook/kerberos.sgml +++ b/handbook/kerberos.sgml @@ -1,480 +1,480 @@ - + Kerberos

Contributed by &a.markm; (based on contribution by &a.md;). Kerberos is a network add-on system/protocol that allows users to authenticate themselves through the services of a secure server. Services such as remote login, remote copy, secure inter-system file copying and other high-risk tasks are made considerably safer and more controllable. The following instructions can be used as a guide on how to set up Kerberos as distributed for FreeBSD. However, you should refer to the relevant manual pages for a complete description. In FreeBSD, the Kerberos is not that from the original 4.4BSD-Lite, distribution, but eBones, which had been previously ported to FreeBSD 1.1.5.1, and was sourced from outside the USA/Canada, and is thus available to system owners outside those countries. For those needing to get a legal foreign distribution of this software, please DO NOT get it from a USA or Canada site. You will get that site in big trouble! A legal copy of this is - available from skeleton.mikom.csir.co.za, which is in South - Africa. + available from ftp.internat.freebsd.org, which is in South + Africa and an official FreeBSD mirror site. Creating the initial database

This is done on the Kerberos server only. First make sure that you do not have any old Kerberos databases around. You should change to the directory /etc/kerberosIV and check that only the following files are present: grunt# cd /etc/kerberosIV grunt# ls README krb.conf krb.realms

If any additional files (such as principal.* or master_key) exist, then use the kdb_destroy command to destroy the old Kerberos database, of if Kerberos - is not running, simply delete the extra files with rm. + is not running, simply delete the extra files. You should now edit the krb.conf and krb.realms files to define your Kerberos realm. In this case the realm will be GRONDAR.ZA and the server is grunt.grondar.za. We edit or create the krb.conf file: grunt# cat krb.conf GRONDAR.ZA GRONDAR.ZA grunt.grondar.za admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov

In this case, the other realms do not need to be there. They are here as an example of how a machine may be made aware of multiple realms. You may wish to not include them for simplicity. The first line names the realm in which this system works. The other lines contain realm/host entries. The first item on a line is a realm, and the second is a host in that realm that is acting as a ``key distribution centre''. The words ``admin server'' following a hosts name means that host also provides an administrative database server. For further explanation of these terms, please consult the Kerberos man pages. Now we have to add grunt.grondar.za to the GRONDAR.ZA realm and also add an entry to put all hosts in the .grondar.za domain in the GRONDAR.ZA realm. The krb.realms file would be updated as follows: grunt# cat krb.realms grunt.grondar.za GRONDAR.ZA .grondar.za GRONDAR.ZA .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU

Again, the other realms do not need to be there. They are here as an example of how a machine may be made aware of multiple realms. You may wish to remove them to simplify things. The first line puts the specific system into the named realm. The rest of the lines show how to default systems of a particular subdomain to a named realm. Now we are ready to create the database. This only needs to run on the Kerberos server (or Key Distribution Centre). Issue the kdb_init command to do this: grunt# kdb_init Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key:

Now we have to save the key so that servers on the local machine can pick it up. Use the kstash command to do this. grunt# kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE!

This saves the encrypted master password in /etc/kerberosIV/master_key. Making it all run

Two principals need to be added to the database for each system that will be secured with Kerberos. Their names are kpasswd and rcmd These two principals are made for each system, with the instance being the name of the individual system. These daemons, kpasswd and rcmd allow other systems to change Kerberos passwords and run commands like rcp, rlogin and rsh. Now let's add these entries: grunt# kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt , Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt , Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Creating the server file

We now have to extract all the instances which define the services on each machine. For this we use the ext_srvtab command. This will create a file which must be copied or moved by secure means to each Kerberos client's /etc/kerberosIV directory. This file must be present on each server and client, and is crucial to the operation of Kerberos. grunt# ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'....

Now, this command only generates a temporary file which must be renamed to srvtab so that all the server can pick it up. Use the mv command to move it into place on the original system: grunt# mv grunt-new-srvtab srvtab

If the file is for a client system, and the network is not deemed safe, then copy the <client>-new-srvtab to removable media and transport it by secure physical means. Be sure to rename it to srvtab in the client's /etc/kerberosIV directory, and make sure it is mode 600: grumble# mv grumble-new-srvtab srvtab grumble# chmod 600 srvtab Populating the database

We now have to add some user entries into the database. First let's create an entry for the user jane. Use the kdb_edit command to do this: grunt# kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: , Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- enter a secure password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Testing it all out

First we have to start the Kerberos daemons. NOTE that if you have correctly edited your /etc/rc.conf then this will happen automatically when you reboot. This is only necessary on the Kerberos server. Kerberos clients will automagically get what they need from the /etc/kerberosIV directory. grunt# kerberos & grunt# Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: GRONDAR.ZA grunt# kadmind -n & grunt# KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE!

Now we can try using the kinit command to get a ticket for the id jane that we created above: grunt$ kinit jane MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane" Password:

Try listing the tokens using klist to see if we really have them: grunt$ klist Ticket file: /tmp/tkt245 Principal: jane@GRONDAR.ZA Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA

Now try changing the password using passwd to check if the kpasswd daemon can get authorization to the Kerberos database: grunt$ passwd realm GRONDAR.ZA Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. Adding su privileges

Kerberos allows us to give each user who needs root privileges their own separate supassword. We could now add an id which is authorized to su to root. This is controlled by having an instance of root associated with a principal. Using kdb_edit we can create the entry jane.root in the Kerberos database: grunt# kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root , Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- enter a SECURE password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit

Now try getting tokens for it to make sure it works: grunt# kinit jane.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane.root" Password:

Now we need to add the user to root's .klogin file: grunt# cat /root/.klogin jane.root@GRONDAR.ZA

Now try doing the su: [jane@grunt 10407] su Password: grunt# and take a look at what tokens we have: grunt# klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@GRONDAR.ZA Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA Using other commands

In an earlier example, we created a principal called jane with an instance root. This was based on a user with the same name as the principal, and this is a Kerberos default; that a <principal>.<instance> of the form <username>.root will allow that <username> to su to root if the necessary entries are in the .klogin file in root's home directory: grunt# cat /root/.klogin jane.root@GRONDAR.ZA

Likewise, if a user has in their own home directory lines of the form: [jane@grunt 10543] cat ~/.klogin jane@GRONDAR.ZA jack@GRONDAR.ZA

This allows anyone in the GRONDAR.ZA realm who has authenticated themselves to jane or jack (via kinit, see above) access to rlogin to jane's account or files on this system (grunt) via rlogin, rsh or rcp. For example, Jane now logs into another system, using Kerberos: [jane@grumble 573] kinit MIT Project Athena (grunt.grondar.za) Password: [jane@grumble 574] rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 [jane@grunt 10567]

Or Jack logs into Jane's account on the same machine (Jane having set up the .klogin file as above, and the person in charge of Kerberos having set up principal jack with a null instance: [jack@grumble 573] kinit [jack@grumble 574] rlogin grunt -l jane MIT Project Athena (grunt.grondar.za) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 [jane@grunt 10578]