From owner-p4-projects@FreeBSD.ORG Sun Nov 7 23:06:41 2010 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 81F7310656A4; Sun, 7 Nov 2010 23:06:41 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43CBB1065670 for ; Sun, 7 Nov 2010 23:06:41 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from skunkworks.freebsd.org (skunkworks.freebsd.org [IPv6:2001:4f8:fff6::2d]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE038FC23 for ; Sun, 7 Nov 2010 23:06:41 +0000 (UTC) Received: from skunkworks.freebsd.org (localhost [127.0.0.1]) by skunkworks.freebsd.org (8.14.4/8.14.4) with ESMTP id oA7N6fTi045763 for ; Sun, 7 Nov 2010 23:06:41 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id oA7N6ek4045760 for perforce@freebsd.org; Sun, 7 Nov 2010 23:06:40 GMT (envelope-from rene@FreeBSD.org) Date: Sun, 7 Nov 2010 23:06:40 GMT Message-Id: <201011072306.oA7N6ek4045760@skunkworks.freebsd.org> X-Authentication-Warning: skunkworks.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Precedence: bulk Cc: Subject: PERFORCE change 185496 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 23:06:41 -0000 http://p4web.freebsd.org/@@185496?ac=10 Change 185496 by rene@rene_acer on 2010/11/07 23:06:31 Continue pre-7.X cleanup of Handbook: - remove some 5.X distinctions - add comments to text referring to "older versions" , unclear how old - add a missing "Alpha" in the introduction - remove section about KerberosIV (old 14.7), 5.X only runs Kerberos5 - remove first paragraph of new section 14.7 (Kerberos5) - mail/sylpheed-claws port got renamed (see /usr/ports/MOVED) Affected files ... .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/boot/chapter.sgml#7 edit .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/config/chapter.sgml#12 edit .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml#17 edit .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/security/chapter.sgml#14 edit Differences ... ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/boot/chapter.sgml#7 (text+ko) ==== @@ -788,9 +788,6 @@ Device Hints - This is a FreeBSD 5.0 and later feature which does not - exist in earlier versions. - During initial system startup, the boot &man.loader.8; will read the &man.device.hints.5; file. This file stores kernel boot information known as variables, sometimes referred to as device hints. ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/config/chapter.sgml#12 (text+ko) ==== @@ -897,8 +897,8 @@ those involved with &os;, have taken the latter approach. - Thanks to the contributions of Bill Paul (wpaul), as of - &os; 5.3-RELEASE there is native support + Thanks to the contributions of Bill Paul (wpaul) + there is native support for the Network Driver Interface Specification (NDIS). The &os; NDISulator (otherwise known as Project Evil) takes a &windows; driver binary and basically tricks it into @@ -1901,9 +1901,9 @@ reduce system boot times. The defaults are fairly high and can be responsible for 15 seconds of delay in the boot process. Reducing it to 5 seconds usually - works (especially with modern drives). Newer versions of &os; - (5.0 and higher) should use the kern.cam.scsi_delay - boot time tunable. The tunable, and kernel config option accept + works (especially with modern drives). + The kern.cam.scsi_delay boot time tunable should + be used. The tunable, and kernel config option accept values in terms of milliseconds and not seconds. @@ -2124,7 +2124,7 @@ In older FreeBSD releases, the default value of kern.maxfiles is derived from the option in your - kernel configuration file. kern.maxfiles grows + kernel configuration file. kern.maxfiles grows proportionally to the value of . When compiling a custom kernel, it is a good idea to set this kernel configuration option according to the uses of your system. From @@ -2148,7 +2148,7 @@ /boot/defaults/loader.conf file for some hints) or as described elsewhere in this document. - In older releases, the system will auto-tune + In older releases, the system will auto-tune maxusers for you if you explicitly set it to 0 The auto-tuning algorithm sets @@ -2228,7 +2228,7 @@ use. kern.ipc.nmbclusters loader tunable should - be used to tune this at boot time. Only older versions of &os; + be used to tune this at boot time. Only older versions of &os; will require you to use the NMBCLUSTERS kernel &man.config.8; option. ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml#17 (text+ko) ==== @@ -651,7 +651,7 @@ November 2005. The most recent 6.4-RELEASE came out in November 2008. There will be no additional releases from the RELENG_6 branch. This branch is the last branch to support the - architecture. + Alpha architecture. The RELENG_7 branch was created in October 2007. The first release of this branch was 7.0-RELEASE, which came ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/security/chapter.sgml#14 (text+ko) ==== @@ -56,11 +56,6 @@ - How to set up KerberosIV on &os; - releases prior to 5.0. - - - How to set up Kerberos5 on &os;. @@ -407,7 +402,6 @@ vast majority of break-ins occur remotely, over a network, from people who do not have physical access to your workstation or servers. - KerberosIV Using something like Kerberos also gives you the ability to disable or change the password for a staff account in one place, @@ -944,7 +938,6 @@ Access Issues with Kerberos and SSH ssh - KerberosIV There are a few issues with both Kerberos and ssh that need to be addressed if @@ -1565,496 +1558,6 @@ - - - - - Mark - Murray - Contributed by - - - - - Mark - Dapoz - Based on a contribution by - - - - - <application>KerberosIV</application> - - 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 &os;. However, you should refer to the - relevant manual pages for a complete description. - - - Installing <application>KerberosIV</application> - - MIT - - KerberosIV - installing - - Kerberos is an optional component of &os;. The easiest - way to install this software is by selecting the krb4 or - krb5 distribution in sysinstall - during the initial installation of &os;. This will install - the eBones (KerberosIV) or Heimdal (Kerberos5) - implementation of Kerberos. These implementations are - included because they are developed outside the USA/Canada and - were thus available to system owners outside those countries - during the era of restrictive export controls on cryptographic - code from the USA. - - Alternatively, the MIT implementation of Kerberos is - available from the Ports Collection as - security/krb5. - - - - 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: - - &prompt.root; cd /etc/kerberosIV -&prompt.root; 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, or if Kerberos 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 EXAMPLE.COM and the - server is grunt.example.com. We edit - or create the krb.conf file: - - &prompt.root; cat krb.conf -EXAMPLE.COM -EXAMPLE.COM grunt.example.com 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 center. The words admin - server following a host's name means that host also - provides an administrative database server. For further explanation - of these terms, please consult the Kerberos manual pages. - - Now we have to add grunt.example.com - to the EXAMPLE.COM realm and also add an entry to - put all hosts in the .example.com - domain in the EXAMPLE.COM realm. The - krb.realms file would be updated as - follows: - - &prompt.root; cat krb.realms -grunt.example.com EXAMPLE.COM -.example.com EXAMPLE.COM -.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 Center). Issue the - kdb_init command to do this: - - &prompt.root; kdb_init -Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM -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: - - &prompt.root; 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 - - - KerberosIV - initial startup - - - 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 &man.rcp.1;, - &man.rlogin.1; and &man.rsh.1;. - - Now let us add these entries: - - &prompt.root; 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 - -<Not found>, 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 - -<Not found>, 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 - directory. This file must be present on each server and client, and is - crucial to the operation of Kerberos. - - - &prompt.root; 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 servers can pick - it up. Use the &man.mv.1; command to move it into place on - the original system: - - &prompt.root; 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 directory, and make sure it is - mode 600: - - &prompt.root; mv grumble-new-srvtab srvtab -&prompt.root; chmod 600 srvtab - - - - Populating the Database - - We now have to add some user entries into the database. First - let us create an entry for the user jane. Use the - kdb_edit command to do this: - - &prompt.root; 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: - -<Not found>, 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 automatically get what - they need from the /etc/kerberosIV directory. - - &prompt.root; kerberos & -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: EXAMPLE.COM -&prompt.root; kadmind -n & -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: - - &prompt.user; kinit jane -MIT Project Athena (grunt.example.com) -Kerberos Initialization for "jane" -Password: - - Try listing the tokens using klist to see if we - really have them: - - &prompt.user; klist -Ticket file: /tmp/tkt245 -Principal: jane@EXAMPLE.COM - - Issued Expires Principal -Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM - - Now try changing the password using &man.passwd.1; to - check if the kpasswd daemon can get - authorization to the Kerberos database: - - &prompt.user; passwd -realm EXAMPLE.COM -Old password for jane: -New Password for jane: -Verifying password -New Password for jane: -Password changed. - - - - Adding <command>su</command> Privileges - - Kerberos allows us to give each user - who needs root privileges their own - separate &man.su.1; password. - We could now add an ID which is authorized to - &man.su.1; 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: - - &prompt.root; 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 - -<Not found>, 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: - - &prompt.root; kinit jane.root -MIT Project Athena (grunt.example.com) -Kerberos Initialization for "jane.root" -Password: - - Now we need to add the user to root's - .klogin file: - - &prompt.root; cat /root/.klogin -jane.root@EXAMPLE.COM - - Now try doing the &man.su.1;: - - &prompt.user; su -Password: - - and take a look at what tokens we have: - - &prompt.root; klist -Ticket file: /tmp/tkt_root_245 -Principal: jane.root@EXAMPLE.COM - - Issued Expires Principal -May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM - - - - 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 &man.su.1; to - root if the necessary entries are in the - .klogin file in root's - home directory: - - &prompt.root; cat /root/.klogin -jane.root@EXAMPLE.COM - - Likewise, if a user has in their own home directory lines of the - form: - - &prompt.user; cat ~/.klogin -jane@EXAMPLE.COM -jack@EXAMPLE.COM - - This allows anyone in the EXAMPLE.COM realm - who has authenticated themselves as jane or - jack (via kinit, see above) - to access to jane's - account or files on this system (grunt) via - &man.rlogin.1;, &man.rsh.1; or - &man.rcp.1;. - - For example, jane now logs into another system using - Kerberos: - - &prompt.user; kinit -MIT Project Athena (grunt.example.com) -Password: -&prompt.user; 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 - - 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): - - &prompt.user; kinit -&prompt.user; rlogin grunt -l jane -MIT Project Athena (grunt.example.com) -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 - - - @@ -2075,17 +1578,6 @@ <application>Kerberos5</application> - Every &os; release beyond &os;-5.1 includes support - only for Kerberos5. Hence - Kerberos5 is the only version - included, and its configuration is similar in many aspects - to that of KerberosIV. The following - information only applies to - Kerberos5 in post &os;-5.0 - releases. Users who wish to use the - KerberosIV package may install the - security/krb4 port. - 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 @@ -2860,7 +2352,7 @@ encrypted authentication of mail clients, web based transactions such as credit card payments and more. Many ports such as www/apache13-ssl, and - mail/sylpheed-claws + mail/claws-mail will offer compilation support for building with OpenSSL. @@ -3981,8 +3473,8 @@ File System Access Control Lists - In conjunction with file system enhancements like snapshots, FreeBSD 5.0 - and later offers the security of File System Access Control Lists + In conjunction with file system enhancements like snapshots, FreeBSD + offers the security of File System Access Control Lists (ACLs). Access Control Lists extend the standard &unix;