http://selinuxproject.org/w/api.php?action=feedcontributions&user=CraigGrube&feedformat=atom SELinux Wiki - User contributions [en] 2024-03-19T10:59:57Z User contributions MediaWiki 1.23.13 http://selinuxproject.org/page/PipelineDemo PipelineDemo 2009-11-27T18:00:50Z <p>CraigGrube: </p> <hr /> <div>= Overview =<br /> Assured pipelines provide the ability to move data between different information domains by carefully specifying a set of processing steps that must occur. Assured pipelines are simple in nature, having only a small number of properties that must be guaranteed to provide correct operation. Assured pipelines must be non-bypassable, tamperproof, and verifiable.<br /> <br /> SELinux provides mandatory access control mechanisms that are ideal for building assured pipelines. SELinux type enforcement provides fine-grained access control that can express a wide range of information flow policies. This expressiveness is important in situations where policy involves information domains and relationships that aren’t as simple as those provided by traditional MLS policies.<br /> <br /> As opposed to building a single monolithic application that performs all operations necessary to process data, assured pipelines allow smaller standalone applications to be built. Each application performs a single simple operation on the data. The smaller applications are easier to analyze, test, and evaluate for correctness and trustworthiness. It also allows third party applications or COTS applications to be integrated as a pipeline stage without requiring tight integration with other processing.<br /> <br /> In a trustworthy system, when information must pass from one application to another for processing, separation of processing is not sufficient to guarantee that the system policy is being enforced. An assured pipeline can use a mandatory access control (MAC) policy to place tight controls on how processing stages may interact with each other and guarantee that processing occurs in the proper order.<br /> <br /> Traditional MAC policies such as multi-level security (MLS) can be adapted to provide adequate protection for some types of assured pipelines, but cannot easily adapt to all. A more flexible policy, such as type enforcement can provide fine-grained permissions that express a wider range of information flow pipelines. In cases where assured pipelines are established specifically to allow for data label change and downgrades or to permit export to another system with a lesser privilege (such as a cross domain guard), an MLS policy cannot be used. Since the downgrade operation would be a violation of the MLS policy, the pipeline stages must be privileged to allow data “write-down” operations. When many pipeline stages are privileged, it becomes difficult to make assertions about proper information flow. With a type enforcement policy such as SELinux, types can be used to confine input and output data types for each stage in the pipeline and guarantee that data flows only in the appropriate direction.<br /> <br /> Traditionally, limitations in mandatory access control policies and the desire to reduce overall complexity has resulted in assured pipelines that are only serial in nature – all processing is a single set of sequential stages. However, pipelines do not need to be strictly linear. As long as the information flow policy supports it, pipelines can have branches or can loop back to re-process data.<br /> <br /> Type enforcement also allows for more appropriate processing of audit and monitoring information. With an MLS system, audit information from pipeline stages would typically need to perform a write-up operation to the highest-level label for all data processed. Since type enforcement is not a hierarchical policy with an implicit flow direction, audit data can flow in a more natural path that does not necessitate a central trusted log component.<br /> <br /> = Demonstration = <br /> == Overview ==<br /> Most trustworthy Information systems require a mechanism to import data into the system for further analysis, processing, or dissemination. However, trustworthy systems require that extra care be taken to avoid providing a mechanism to introduce content that could be damaging or disruptive to the system.<br /> <br /> While users sometimes may be trusted to import data directly, a more secure system would require data to pass through a set of non-bypassable filters before it may be used. An assured pipeline could be used to guarantee that necessary filters are run in the proper order and that data is not available until it has successfully passed through all necessary processing.<br /> <br /> With a type enforcement policy such as SELinux data on removable media such as CDROMs, USB Flash-based tokens, scanners, external hard disks with file systems not containing trustworthy security labels for all files, etc. can be assigned a default label by the policy. The default label will preclude any access to the raw data files except by the first stage of the processing pipeline.<br /> <br /> A set of carefully built processing applications can examine the file data to determine if it may be safely added to the system. Only upon exit from the pipeline would the data be labeled so that it may be accessed by other applications. If the data were rejected at any time, the security policy would preclude any access. At an early stage in the pipeline, output could branch depending on the format of the incoming data so format-specific processing or translation can be performed. In a subsequent stage, processing can collect and continue with serialized processing.<br /> <br /> Example processing might include:<br /> * Reject all files that are not ASCII text<br /> * Convert all MS Word documents to ASCII text, PDF or TIFF<br /> * Scan with antivirus software<br /> * Allow user to specify appropriate security label<br /> * Reject encrypted or archived files (zip, etc.)<br /> <br /> == Implementation ==<br /> <br /> The current pipeline performs the following steps:<br /> * Import files from specified source into pipeline for processing.<br /> * Scan files for viruses using ClamAV.<br /> * Convert Word documents to text using catdoc.<br /> * Convert PDF documents to text using pdftotext.<br /> * Verify jpg files contain JPEG data using ImageMagick.<br /> * Export files from pipeline into a user specific drop directory.<br /> <br /> Following successful installation the pipeline scripts will be available in &lt;code&gt;/usr/local/bin&lt;/code&gt;. The main pipeline script, &lt;code&gt;pipeline-import.sh&lt;/code&gt;, is what users will run to import files. Files that successfully make their way through the pipeline will be available inside of a users home directory, specifically, &lt;code&gt;~/inbox&lt;/code&gt; and should all have type pipeline_processed_t.<br /> <br /> The SELinux reference policy was modified to set the default type for files in ISO9660 and UDF file systems to pipeline_unclean_t, which can only be accessed by the first stage of the pipeline. Following successful installation an ISO image containing sample files for import is accessible at &lt;code&gt;/media/sample&lt;/code&gt;.<br /> <br /> == Installation ==<br /> <br /> A sample [http://www.selinuxproject.org/~cgrube/pipeline/kickstart/ks.pipeline.cfg kickstart] is available for building a very basic system with the pipeline scripts and SELinux policy installed. The most convenient way to install the demonstration is to boot a system or VM using Fedora Core 11 installation media and at the kernel boot prompt add the option &lt;code&gt;ks=http://www.selinuxproject.org/~cgrube/pipeline/kickstart/ks.pipeline.cfg&lt;/code&gt;.<br /> <br /> Binary RPM packages are available [http://www.selinuxproject.org/~cgrube/pipeline/packages here]. Source RPM packages and tarballs are available [http://www.selinuxproject.org/~cgrube/pipeline/source here].<br /> <br /> == Using the pipeline ==<br /> <br /> The main script controlling the pipeline, pipeline-import.sh, takes two command line arguments:<br /> * -p - will display the SELinux context of each stage of the pipeline as they execute.<br /> * -i {dir} - specifies the directory from which files should be imported.<br /> <br /> To import the sample files (as a non-root user):<br /> * Run &lt;code&gt;pipeline-import.sh -i /media/sample&lt;/code&gt;.<br /> * View the processed files in &lt;code&gt;~/inbox&lt;/code&gt;.</div> CraigGrube http://selinuxproject.org/page/PipelineDemo PipelineDemo 2009-10-24T14:52:37Z <p>CraigGrube: New page: = Overview = Assured pipelines provide the ability to move data between different information domains by carefully specifying a set of processing steps that must occur. Assured pipelines ...</p> <hr /> <div>= Overview =<br /> Assured pipelines provide the ability to move data between different information domains by carefully specifying a set of processing steps that must occur. Assured pipelines are simple in nature, having only a small number of properties that must be guaranteed to provide correct operation. Assured pipelines must be non-bypassable, tamperproof, and verifiable.<br /> <br /> SELinux provides mandatory access control mechanisms that are ideal for building assured pipelines. SELinux type enforcement provides fine-grained access control that can express a wide range of information flow policies. This expressiveness is important in situations where policy involves information domains and relationships that aren’t as simple as those provided by traditional MLS policies.<br /> <br /> As opposed to building a single monolithic application that performs all operations necessary to process data, assured pipelines allow smaller standalone applications to be built. Each application performs a single simple operation on the data. The smaller applications are easier to analyze, test, and evaluate for correctness and trustworthiness. It also allows third party applications or COTS applications to be integrated as a pipeline stage without requiring tight integration with other processing.<br /> <br /> In a trustworthy system, when information must pass from one application to another for processing, separation of processing is not sufficient to guarantee that the system policy is being enforced. An assured pipeline can use a mandatory access control (MAC) policy to place tight controls on how processing stages may interact with each other and guarantee that processing occurs in the proper order.<br /> <br /> Traditional MAC policies such as multi-level security (MLS) can be adapted to provide adequate protection for some types of assured pipelines, but cannot easily adapt to all. A more flexible policy, such as type enforcement can provide fine-grained permissions that express a wider range of information flow pipelines. In cases where assured pipelines are established specifically to allow for data label change and downgrades or to permit export to another system with a lesser privilege (such as a cross domain guard), an MLS policy cannot be used. Since the downgrade operation would be a violation of the MLS policy, the pipeline stages must be privileged to allow data “write-down” operations. When many pipeline stages are privileged, it becomes difficult to make assertions about proper information flow. With a type enforcement policy such as SELinux, types can be used to confine input and output data types for each stage in the pipeline and guarantee that data flows only in the appropriate direction.<br /> <br /> Traditionally, limitations in mandatory access control policies and the desire to reduce overall complexity has resulted in assured pipelines that are only serial in nature – all processing is a single set of sequential stages. However, pipelines do not need to be strictly linear. As long as the information flow policy supports it, pipelines can have branches or can loop back to re-process data.<br /> <br /> Type enforcement also allows for more appropriate processing of audit and monitoring information. With an MLS system, audit information from pipeline stages would typically need to perform a write-up operation to the highest-level label for all data processed. Since type enforcement is not a hierarchical policy with an implicit flow direction, audit data can flow in a more natural path that does not necessitate a central trusted log component.<br /> <br /> = Demonstration = <br /> == Overview ==<br /> Most trustworthy Information systems require a mechanism to import data into the system for further analysis, processing, or dissemination. However, trustworthy systems require that extra care be taken to avoid providing a mechanism to introduce content that could be damaging or disruptive to the system.<br /> <br /> While users sometimes may be trusted to import data directly, a more secure system would require data to pass through a set of non-bypassable filters before it may be used. An assured pipeline could be used to guarantee that necessary filters are run in the proper order and that data is not available until it has successfully passed through all necessary processing.<br /> <br /> With a type enforcement policy such as SELinux data on removable media such as CDROMs, USB Flash-based tokens, scanners, external hard disks with file systems not containing trustworthy security labels for all files, etc. can be assigned a default label by the policy. The default label will preclude any access to the raw data files except by the first stage of the processing pipeline.<br /> <br /> A set of carefully built processing applications can examine the file data to determine if it may be safely added to the system. Only upon exit from the pipeline would the data be labeled so that it may be accessed by other applications. If the data were rejected at any time, the security policy would preclude any access. At an early stage in the pipeline, output could branch depending on the format of the incoming data so format-specific processing or translation can be performed. In a subsequent stage, processing can collect and continue with serialized processing.<br /> <br /> Example processing might include:<br /> * Reject all files that are not ASCII text<br /> * Convert all MS Word documents to ASCII text, PDF or TIFF<br /> * Scan with antivirus software<br /> * Allow user to specify appropriate security label<br /> * Reject encrypted or archived files (zip, etc.)<br /> <br /> == Implementation ==<br /> <br /> The current pipeline performs the following steps:<br /> * Import files from specified source into pipeline for processing.<br /> * Scan files for viruses using ClamAV.<br /> * Convert Word documents to text using catdoc.<br /> * Convert PDF documents to text using pdftotext.<br /> * Verify jpg files contain JPEG data using ImageMagick.<br /> * Export files from pipeline into drop directory.<br /> <br /> Following successful installation the pipeline scripts will be available in &lt;code&gt;/usr/local/bin&lt;/code&gt; and sample files for processing with the pipeline will be in &lt;code&gt;/media/sample&lt;/code&gt;.<br /> <br /> Files that successfully make their way through the pipeline will be available in &lt;code&gt;/home/inbox&lt;/code&gt; and should all have type pipeline_processed_t.<br /> <br /> == Installation ==<br /> <br /> A sample [http://www.selinuxproject.org/~cgrube/pipeline/kickstart/ks.pipeline.cfg kickstart] is available for building a very basic system with the pipeline scripts and SELinux policy installed. The most convenient way to install the demonstration is to boot a system or VM using Fedora Core 11 installation media and at the kernel boot prompt add the option &lt;code&gt;ks=http://www.selinuxproject.org/~cgrube/pipeline/kickstart/ks.pipeline.cfg&lt;/code&gt;.<br /> <br /> Binary RPM packages are available [http://www.selinuxproject.org/~cgrube/pipeline/packages here]. And source RPM packages and tarballs are available [http://www.selinuxproject.org/~cgrube/pipeline/source here].<br /> <br /> == Using the pipeline ==<br /> <br /> The main script controlling the pipeline, pipeline-import.sh, takes two command line arguments:<br /> * -p - will display the SELinux context of each stage of the pipeline as they execute.<br /> * -i {dir} - specifies the directory from which files should be imported.<br /> <br /> To import the sample files:<br /> * use &lt;code&gt;chcon -R system_u:object_r:pipeline_unclean_t:s0 /media/sample&lt;/code&gt; to change the labels of the files to the type the pipeline operates on<br /> * Run &lt;code&gt;pipeline-import.sh -i /media/sample&lt;/code&gt;.<br /> * View the processed files in &lt;code&gt;/home/inbox&lt;/code&gt;.</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-30T15:29:49Z <p>CraigGrube: /* Client Kickstart */</p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Basic Infrastructure=<br /> ==Requirements==<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ==Packages==<br /> The install defaults to using selinuxproject.org for downloading and installing packages, but if another web server is specified the following packages are expected:<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/puppet-policy.tar.gz puppet-policy] - gzipped tarball of the puppet policy is downloaded to the server and defines the desired end state of clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/sefos-demo-policy-0.1-2.fc11.i386.rpm sefos-demo-policy] - RPM containing a small SELinux module required for some demo specific client configuration to work properly. This package is only downloaded to clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-3.6.12-78.fc11.noarch.rpm selinux-policy],[http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-targeted-3.6.12-78.fc11.noarch.rpm selinux-policy-targeted], [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-doc-3.6.12-78.fc11.noarch.rpm selinux-policy-doc] - SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server. Eventually the changes be included in the reference policy and trickle down to the Fedora RPMS, making these RPMS unnecessary.<br /> <br /> = Installation =<br /> == Server Kickstart ==<br /> <br /> Follow this link to download the [http://www.selinuxproject.org/~cgrube/puppet/kickstart/ks.server.cfg Server Kickstart].<br /> <br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded. The kickstart will default to downloading the packages from selinuxproject.org. If a local mirror is to be used the boot option should be used.<br /> *se_repo - relative path from se_www to a yum repo file for use during the installation.<br /> <br /> The boot options can be specified by editing the kernel options in Grub during boot.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ===Example===<br /> If no changes are made from the example DNS configuration and www.selinuxproject.org is accessible from the system being kickstarted no boot options need to be provided.<br /> <br /> If an alternate web server is to be used &lt;code&gt;se_www=http://webserver/path/to/files&lt;/code&gt; should be added to the boot options. If an alternate hostname is desired &lt;code&gt;se_fqdn=server.thedomain&lt;/code&gt; should be added to the boot options. If an alternate domain is to be used &lt;code&gt;se_dnsdomain=thedomain&lt;/code&gt; should be used to specify the domain name.<br /> <br /> == Client Kickstart ==<br /> <br /> Follow this link to download the [http://www.selinuxproject.org/~cgrube/puppet/kickstart/ks.client.cfg Client Kickstart].<br /> <br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded. By default the kickstart will download packages from the selinuxproject.org web server.<br /> *se_repo - relative path from se_www to yum repo file for use during installation.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ===Example===<br /> Assuming no changes from the example DNS configuration no boot options are required for client1, &lt;code&gt;se_fqdn=client2.example.com&lt;/code&gt; should be added to the boot options for client2. See the examples for the server kickstart if DNS changes were made or an alternate web server is being used.<br /> <br /> == Manual Post Installation Configuraton ==<br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-30T15:29:22Z <p>CraigGrube: /* Server Kickstart */</p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Basic Infrastructure=<br /> ==Requirements==<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ==Packages==<br /> The install defaults to using selinuxproject.org for downloading and installing packages, but if another web server is specified the following packages are expected:<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/puppet-policy.tar.gz puppet-policy] - gzipped tarball of the puppet policy is downloaded to the server and defines the desired end state of clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/sefos-demo-policy-0.1-2.fc11.i386.rpm sefos-demo-policy] - RPM containing a small SELinux module required for some demo specific client configuration to work properly. This package is only downloaded to clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-3.6.12-78.fc11.noarch.rpm selinux-policy],[http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-targeted-3.6.12-78.fc11.noarch.rpm selinux-policy-targeted], [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-doc-3.6.12-78.fc11.noarch.rpm selinux-policy-doc] - SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server. Eventually the changes be included in the reference policy and trickle down to the Fedora RPMS, making these RPMS unnecessary.<br /> <br /> = Installation =<br /> == Server Kickstart ==<br /> <br /> Follow this link to download the [http://www.selinuxproject.org/~cgrube/puppet/kickstart/ks.server.cfg Server Kickstart].<br /> <br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded. The kickstart will default to downloading the packages from selinuxproject.org. If a local mirror is to be used the boot option should be used.<br /> *se_repo - relative path from se_www to a yum repo file for use during the installation.<br /> <br /> The boot options can be specified by editing the kernel options in Grub during boot.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ===Example===<br /> If no changes are made from the example DNS configuration and www.selinuxproject.org is accessible from the system being kickstarted no boot options need to be provided.<br /> <br /> If an alternate web server is to be used &lt;code&gt;se_www=http://webserver/path/to/files&lt;/code&gt; should be added to the boot options. If an alternate hostname is desired &lt;code&gt;se_fqdn=server.thedomain&lt;/code&gt; should be added to the boot options. If an alternate domain is to be used &lt;code&gt;se_dnsdomain=thedomain&lt;/code&gt; should be used to specify the domain name.<br /> <br /> == Client Kickstart ==<br /> <br /> Here is the [http://www.selinuxproject.org/~cgrube/puppet/kickstart/ks.client.cfg Client Kickstart].<br /> <br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded. By default the kickstart will download packages from the selinuxproject.org web server.<br /> *se_repo - relative path from se_www to yum repo file for use during installation.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ===Example===<br /> Assuming no changes from the example DNS configuration no boot options are required for client1, &lt;code&gt;se_fqdn=client2.example.com&lt;/code&gt; should be added to the boot options for client2. See the examples for the server kickstart if DNS changes were made or an alternate web server is being used.<br /> <br /> == Manual Post Installation Configuraton ==<br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-30T15:28:42Z <p>CraigGrube: /* Client Kickstart */</p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Basic Infrastructure=<br /> ==Requirements==<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ==Packages==<br /> The install defaults to using selinuxproject.org for downloading and installing packages, but if another web server is specified the following packages are expected:<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/puppet-policy.tar.gz puppet-policy] - gzipped tarball of the puppet policy is downloaded to the server and defines the desired end state of clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/sefos-demo-policy-0.1-2.fc11.i386.rpm sefos-demo-policy] - RPM containing a small SELinux module required for some demo specific client configuration to work properly. This package is only downloaded to clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-3.6.12-78.fc11.noarch.rpm selinux-policy],[http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-targeted-3.6.12-78.fc11.noarch.rpm selinux-policy-targeted], [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-doc-3.6.12-78.fc11.noarch.rpm selinux-policy-doc] - SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server. Eventually the changes be included in the reference policy and trickle down to the Fedora RPMS, making these RPMS unnecessary.<br /> <br /> = Installation =<br /> == Server Kickstart ==<br /> <br /> Here is the [http://www.selinuxproject.org/~cgrube/puppet/kickstart/ks.server.cfg Server Kickstart].<br /> <br /> <br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded. The kickstart will default to downloading the packages from selinuxproject.org. If a local mirror is to be used the boot option should be used.<br /> *se_repo - relative path from se_www to a yum repo file for use during the installation.<br /> <br /> The boot options can be specified by editing the kernel options in Grub during boot.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ===Example===<br /> If no changes are made from the example DNS configuration and www.selinuxproject.org is accessible from the system being kickstarted no boot options need to be provided.<br /> <br /> If an alternate web server is to be used &lt;code&gt;se_www=http://webserver/path/to/files&lt;/code&gt; should be added to the boot options. If an alternate hostname is desired &lt;code&gt;se_fqdn=server.thedomain&lt;/code&gt; should be added to the boot options. If an alternate domain is to be used &lt;code&gt;se_dnsdomain=thedomain&lt;/code&gt; should be used to specify the domain name.<br /> <br /> == Client Kickstart ==<br /> <br /> Here is the [http://www.selinuxproject.org/~cgrube/puppet/kickstart/ks.client.cfg Client Kickstart].<br /> <br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded. By default the kickstart will download packages from the selinuxproject.org web server.<br /> *se_repo - relative path from se_www to yum repo file for use during installation.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ===Example===<br /> Assuming no changes from the example DNS configuration no boot options are required for client1, &lt;code&gt;se_fqdn=client2.example.com&lt;/code&gt; should be added to the boot options for client2. See the examples for the server kickstart if DNS changes were made or an alternate web server is being used.<br /> <br /> == Manual Post Installation Configuraton ==<br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-30T15:26:34Z <p>CraigGrube: /* Server Kickstart */</p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Basic Infrastructure=<br /> ==Requirements==<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ==Packages==<br /> The install defaults to using selinuxproject.org for downloading and installing packages, but if another web server is specified the following packages are expected:<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/puppet-policy.tar.gz puppet-policy] - gzipped tarball of the puppet policy is downloaded to the server and defines the desired end state of clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/sefos-demo-policy-0.1-2.fc11.i386.rpm sefos-demo-policy] - RPM containing a small SELinux module required for some demo specific client configuration to work properly. This package is only downloaded to clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-3.6.12-78.fc11.noarch.rpm selinux-policy],[http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-targeted-3.6.12-78.fc11.noarch.rpm selinux-policy-targeted], [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-doc-3.6.12-78.fc11.noarch.rpm selinux-policy-doc] - SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server. Eventually the changes be included in the reference policy and trickle down to the Fedora RPMS, making these RPMS unnecessary.<br /> <br /> = Installation =<br /> == Server Kickstart ==<br /> <br /> Here is the [http://www.selinuxproject.org/~cgrube/puppet/kickstart/ks.server.cfg Server Kickstart].<br /> <br /> <br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded. The kickstart will default to downloading the packages from selinuxproject.org. If a local mirror is to be used the boot option should be used.<br /> *se_repo - relative path from se_www to a yum repo file for use during the installation.<br /> <br /> The boot options can be specified by editing the kernel options in Grub during boot.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ===Example===<br /> If no changes are made from the example DNS configuration and www.selinuxproject.org is accessible from the system being kickstarted no boot options need to be provided.<br /> <br /> If an alternate web server is to be used &lt;code&gt;se_www=http://webserver/path/to/files&lt;/code&gt; should be added to the boot options. If an alternate hostname is desired &lt;code&gt;se_fqdn=server.thedomain&lt;/code&gt; should be added to the boot options. If an alternate domain is to be used &lt;code&gt;se_dnsdomain=thedomain&lt;/code&gt; should be used to specify the domain name.<br /> <br /> == Client Kickstart ==<br /> <br /> [[PuppetDemoClientKickstart| Client kickstart ]]<br /> <br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded. By default the kickstart will download packages from the selinuxproject.org web server.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ===Example===<br /> Assuming no changes from the example DNS configuration no boot options are required for client1, &lt;code&gt;se_fqdn=client2.example.com&lt;/code&gt; should be added to the boot options for client2. See the examples for the server kickstart if DNS changes were made or an alternate web server is being used.<br /> <br /> <br /> == Manual Post Installation Configuraton ==<br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-18T01:26:03Z <p>CraigGrube: </p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Basic Infrastructure=<br /> ==Requirements==<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ==Packages==<br /> The install defaults to using selinuxproject.org for downloading and installing packages, but if another web server is specified the following packages are expected:<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/puppet-policy.tar.gz puppet-policy] - gzipped tarball of the puppet policy is downloaded to the server and defines the desired end state of clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/sefos-demo-policy-0.1-2.fc11.i386.rpm sefos-demo-policy] - RPM containing a small SELinux module required for some demo specific client configuration to work properly. This package is only downloaded to clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-3.6.12-78.fc11.noarch.rpm selinux-policy],[http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-targeted-3.6.12-78.fc11.noarch.rpm selinux-policy-targeted], [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-doc-3.6.12-78.fc11.noarch.rpm selinux-policy-doc] - SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server. Eventually the changes be included in the reference policy and trickle down to the Fedora RPMS, making these RPMS unnecessary.<br /> <br /> = Installation =<br /> == Server Kickstart ==<br /> <br /> [[PuppetDemoServerKickstart| Server kickstart ]].<br /> <br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded. The kickstart will default to downloading the packages from selinuxproject.org. If a local mirror is to be used boot option should be used.<br /> <br /> The boot options can be specified by editing the kernel options in Grub during boot.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ===Example===<br /> If no changes are made from the example DNS configuration and www.selinuxproject.org is accessible from the system being kickstarted no boot options need to be provided.<br /> <br /> If an alternate web server is to be used &lt;code&gt;se_www=http://webserver/path/to/files&lt;/code&gt; should be added to the boot options. If an alternate hostname is desired &lt;code&gt;se_fqdn=server.thedomain&lt;/code&gt; should be added to the boot options. If an alternate domain is to be used &lt;code&gt;se_dnsdomain=thedomain&lt;/code&gt; should be used to specify the domain name.<br /> <br /> == Client Kickstart ==<br /> <br /> [[PuppetDemoClientKickstart| Client kickstart ]]<br /> <br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded. By default the kickstart will download packages from the selinuxproject.org web server.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ===Example===<br /> Assuming no changes from the example DNS configuration no boot options are required for client1, &lt;code&gt;se_fqdn=client2.example.com&lt;/code&gt; should be added to the boot options for client2. See the examples for the server kickstart if DNS changes were made or an alternate web server is being used.<br /> <br /> <br /> == Manual Post Installation Configuraton ==<br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-18T01:18:43Z <p>CraigGrube: </p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Basic Infrastructure=<br /> ==Requirements==<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ==Packages==<br /> The server and client automated installs expect certain packages<br /> to be present in /packages/ on a web server designated during the<br /> kickstart install. The following packages are expected:<br /> <br /> * [[PuppetDemoServerKickstart| Server kickstart ]] file.<br /> * [[PuppetDemoClientKickstart| Client kickstart ]] file.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/puppet-policy.tar.gz puppet-policy] - gzipped tarball of the puppet policy is downloaded to the server and defines the desired end state of clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/sefos-demo-policy-0.1-2.fc11.i386.rpm sefos-demo-policy] - RPM containing a small SELinux module required for some demo specific client configuration to work properly. This package is only downloaded to clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-3.6.12-78.fc11.noarch.rpm selinux-policy],[http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-targeted-3.6.12-78.fc11.noarch.rpm selinux-policy-targeted], [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-doc-3.6.12-78.fc11.noarch.rpm selinux-policy-doc] - SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server. Eventually the changes be included in the reference policy and trickle down to the Fedora RPMS, making these RPMS unnecessary.<br /> <br /> = Installation =<br /> == Server Kickstart ==<br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded. The kickstart will default to downloading the packages from selinuxproject.org. If a local mirror is to be used boot option should be used.<br /> <br /> The boot options can be specified by editing the kernel options in Grub during boot.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ===Example===<br /> If no changes are made from the example DNS configuration and www.selinuxproject.org is accessible from the system being kickstarted no boot options need to be provided.<br /> <br /> If an alternate web server is to be used &lt;code&gt;se_www=http://webserver/path/to/files&lt;/code&gt; should be added to the boot options. If an alternate hostname is desired &lt;code&gt;se_fqdn=server.thedomain&lt;/code&gt; should be added to the boot options. If an alternate domain is to be used &lt;code&gt;se_dnsdomain=thedomain&lt;/code&gt; should be used to specify the domain name.<br /> <br /> == Client Kickstart ==<br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded. By default the kickstart will download packages from the selinuxproject.org web server.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ===Example===<br /> Assuming no changes from the example DNS configuration no boot options are required for client1, &lt;code&gt;se_fqdn=client2.example.com&lt;/code&gt; should be added to the boot options for client2. See the examples for the server kickstart if DNS changes were made or an alternate web server is being used.<br /> <br /> <br /> == Manual Post Installation Configuraton ==<br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-18T01:00:10Z <p>CraigGrube: /* Packages */</p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Basic Infrastructure=<br /> ==Requirements==<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ==Packages==<br /> The server and client automated installs expect certain packages<br /> to be present in /packages/ on a web server designated during the<br /> kickstart install. The following packages are expected:<br /> <br /> * [[PuppetDemoServerKickstart| Server kickstart ]] file.<br /> * [[PuppetDemoClientKickstart| Client kickstart ]] file.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/puppet-policy.tar.gz puppet-policy] - gzipped tarball of the puppet policy is downloaded to the server and defines the desired end state of clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/sefos-demo-policy-0.1-2.fc11.i386.rpm sefos-demo-policy] - RPM containing a small SELinux module required for some demo specific client configuration to work properly. This package is only downloaded to clients.<br /> <br /> * [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-3.6.12-78.fc11.noarch.rpm selinux-policy],[http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-targeted-3.6.12-78.fc11.noarch.rpm selinux-policy-targeted], [http://www.selinuxproject.org/~cgrube/puppet/packages/selinux-policy-doc-3.6.12-78.fc11.noarch.rpm selinux-policy-doc] - SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server. Eventually the changes be included in the reference policy and trickle down to the Fedora RPMS, making these RPMS unnecessary.<br /> <br /> = Installation =<br /> == Server Kickstart ==<br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> === Example ===<br /> <br /> == Client Kickstart ==<br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ===Example===<br /> When installing client1 only se_www needs to be specified as the default values for hostname, DNS Domain and Puppetmaster DNS name will be sufficient as long the demo environment is the same as the provided examples.<br /> <br /> Assuming no changes from the demo, se_fqdn and se_www should be used when kickstarting client2.<br /> <br /> == Manual Post Installation Configuraton ==<br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemoClientKickstart PuppetDemoClientKickstart 2009-09-18T00:51:30Z <p>CraigGrube: </p> <hr /> <div>Here is a downloadable version of the [http://www.selinuxproject.org/~cgrube/puppet/kickstart/ks.client.cfg client kickstart].<br /> <br /> &lt;pre&gt;<br /> ##########################################################<br /> # Puppet Demo Client Kickstart file<br /> #<br /> # Purpose - <br /> # The purpose of the client kickstart is to build a very<br /> # basic systems (just base packages + Puppet and dependencies)<br /> # that will then be boot-strapped via Puppet. <br /> #<br /> # External Dependencies - <br /> # Installation: To install boot the system from FC11<br /> # installation media (DVD, CD, netboot, etc). When the <br /> # grub interface appears, modify the boot options to load<br /> # the kickstart and provide the desired boot options to <br /> # customize the installation (i.e. ks=http://webserver/dir/<br /> # ks.cfg se_var1=val1 ...).<br /> #<br /> # Boot Options - <br /> #<br /> # se_dnsdomain - DNS domain of client (assumes example.com<br /> # if none provided)<br /> # se_fqdn - Fully qualified domain name of client (assumes<br /> # client1.${se_dnsdomain} if none provided)<br /> # se_pmaster - FQDN of Puppet server (assumes <br /> # puppetmaster.${se_dnsdomain} if none provided)<br /> # se_www - IP address of resolvable DNS name of web server<br /> # from which packages should be downloaded. The default<br /> # value will download the packages from selinuxproject.org<br /> #<br /> # Assumptions:<br /> # Network address provisioning is with DHCP. IF static<br /> # addressing is desired uncomment and modify the static<br /> # network configuration line and comment the DHCP network<br /> # configuration line.<br /> #<br /> ##########################################################<br /> # Kickstart file<br /> <br /> install<br /> logging --level=info<br /> <br /> # XXX: Network install options<br /> #nfs --server=192.168.1.3 --dir=/site/isos/redhat/10/i386<br /> #url --url http://192.168.1.3/fedora/10/i386<br /> <br /> # XXX: use a local repo, if available<br /> #repo --name=&quot;My Updates&quot; --baseurl=http://192.168.1.3/fedora/10/updates/i386/<br /> <br /> #<br /> # remove interactive for an automated install<br /> #<br /> interactive<br /> <br /> lang en_US.UTF-8<br /> keyboard us<br /> <br /> network --device eth0 --bootproto dhcp<br /> #network --device eth0 --bootproto static --ip 172.16.148.51 --netmask 255.255.255.0 --gateway 172.16.148.2 --nameserver 172.16.148.10<br /> <br /> <br /> #<br /> # make sure to change your password after installation, or during<br /> # for interactive installs<br /> #<br /> rootpw sefos1<br /> <br /> firewall --enabled --ssh <br /> authconfig --enableshadow --enablemd5<br /> <br /> #<br /> # --Disable doesn't work. Selinux is still enabled.<br /> #<br /> selinux --permissive<br /> <br /> timezone --utc America/New_York<br /> bootloader --location=mbr <br /> <br /> reboot<br /> <br /> %packages --excludedocs --nobase<br /> @core<br /> perl<br /> yum<br /> openssh-server<br /> openssh-clients<br /> man<br /> <br /> # optional packages<br /> selinux-policy-targeted<br /> audit<br /> audit-libs<br /> dhclient<br /> bind-utils<br /> <br /> %end<br /> <br /> %post --erroronfail --log=/root/nklinstall.log<br /> <br /> # Boot arguments <br /> # get boot args beginning with 'se_'<br /> &lt; /proc/cmdline sed 's/ /\n/g' | grep ^se_ &gt; /tmp/boot_args<br /> . /tmp/boot_args<br /> <br /> <br /> <br /> ############# BOOT ARGUMENTS DEFAULTS ########################<br /> # Enter default values below!<br /> # If boot arguments exist, use them else use these<br /> <br /> # set default dns name if none provided<br /> if [ &quot;${se_dnsdomain}x&quot; == &quot;x&quot; ]; then<br /> se_dnsdomain=&quot;example.com&quot;<br /> fi<br /> <br /> # set default fqdn is none provided<br /> if [ &quot;${se_fqdn}x&quot; == &quot;x&quot; ]; then<br /> se_fqdn=&quot;client1.${se_dnsdomain}&quot;;<br /> fi<br /> <br /> # set default name of puppet server if none provided<br /> if [ &quot;${se_pmaster}x&quot; == &quot;x&quot; ]; then<br /> se_pmaster=&quot;puppetmaster.${se_dnsdomain}&quot;<br /> fi<br /> <br /> # set default location of web server for packages<br /> if [ &quot;${se_www}x&quot; == &quot;x&quot; ]; then<br /> se_www=&quot;www.selinuxproject.org/~cgrube/puppet&quot;<br /> fi<br /> <br /> ############### NETWORK FILE TRANSFERS #######################<br /> # do initial update, this should just get the repository info<br /> /usr/bin/yum -y update | /usr/bin/tee -a /root/yumup.log<br /> echo | /usr/bin/tee -a /root/yumup.log<br /> <br /> ##########################################<br /> # install custom selinux policy packages<br /> pv=3.6.12-78.fc11<br /> <br /> rpm -e selinux-policy selinux-policy-targeted<br /> <br /> rpm -U --force http://${se_www}/packages/selinux-policy-${pv}.noarch.rpm http://${se_www}/packages/selinux-policy-doc-${pv}.noarch.rpm http://${se_www}/packages/selinux-policy-targeted-${pv}.noarch.rpm<br /> rpm -U http://${se_www}/packages/sefos-demo-policy-0.1-2.fc11.i386.rpm<br /> <br /> # install the puppet client<br /> /usr/bin/yum -y install puppet ruby-rdoc | /usr/bin/tee -a /root/yumup.log<br /> <br /> <br /> ################# FILE CONFIGURATION ################<br /> # switch to enforcing mode<br /> /usr/bin/perl -p -i.sefback -e &quot;s/=disabled/=enforcing/&quot; /etc/selinux/config<br /> <br /> # set hostname<br /> /usr/bin/perl -p -i.sefback -e &quot;s/HOSTNAME=localhost.localdomain/HOSTNAME=${se_fqdn}/g&quot; /etc/sysconfig/network 2&gt;&amp;1<br /> <br /> # set default DNS search domain<br /> echo &quot;SEARCH=${se_dnsdomain}&quot; &gt;&gt; /etc/sysconfig/network-scripts/ifcfg-eth0<br /> <br /> ## relabel file system at boot to ensure puppet files have right labels<br /> touch /.autorelabel<br /> <br /> # network service doesn't appear to be on by default, so turn it on to get clients with<br /> # static addressing working.<br /> <br /> /sbin/chkconfig network on<br /> /sbin/chkconfig puppet on<br /> <br /> # set puppet server <br /> echo &quot;# Begin automated kickstart configuration&quot; &gt;&gt; /etc/sysconfig/puppet<br /> echo &quot;PUPPET_SERVER=${se_pmaster}&quot; &gt;&gt; /etc/sysconfig/puppet<br /> <br /> %end<br /> <br /> &lt;/pre&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemoServerKickstart PuppetDemoServerKickstart 2009-09-18T00:49:37Z <p>CraigGrube: </p> <hr /> <div>Here's a downloadable version of the [http://www.selinuxproject.org/~cgrube/puppet/kickstart/ks.server.cfg server kickstart].<br /> <br /> &lt;pre&gt;<br /> ##########################################################<br /> # Puppet Demo Server Kickstart file<br /> #<br /> # Purpose - <br /> # The purpose of the server kickstart is to build a <br /> # basic Puppet server. The installation is small (essentially<br /> # just base packages + Puppet and dependencies), so many <br /> # administrative and user packages are not installed.<br /> #<br /> # External Dependencies - <br /> # Installation: To install boot the system from FC9 <br /> # installation media (DVD, CD, netboot, etc). When the <br /> # grub interface appears, modify the boot options to load<br /> # the kickstart and provide the desired boot options to <br /> # customize the installation (i.e. ks=http://webserver/dir/<br /> # ks.cfg se_var1=val1 ...).<br /> #<br /> # Boot Options - <br /> # se_dnsdomain - DNS domain of server (assumes example.com<br /> # if none is provided)<br /> # se_fqdn - Fully qualified domain name of server (assumes<br /> # puppetmaster.${se_dnsdomain} if none is provided.)<br /> # se_www - IP or resolvable DNS name of web server and base<br /> # path from which packages should be downloaded. Defaults<br /> # to downloading the packages from selinuxproject.org<br /> #<br /> # Assumptions:<br /> # By default network address provisioning is via DHCP. If<br /> # static addressing is required uncomment and modify the <br /> # network configuration for static addressing.<br /> #<br /> ##########################################################<br /> # Kickstart file<br /> <br /> install<br /> logging --level=info<br /> <br /> ## examples of repo sources if using local repos via http or nfs<br /> #nfs --server=192.168.1.3 --dir=/site/isos/redhat/10/i386<br /> #url --url http://192.168.1.3/fedora/10/i386<br /> <br /> # XXX: use a local repo , if available<br /> #repo --name=&quot;My Updates&quot; --baseurl=http://192.168.1.3/fedora/9/updates/i386<br /> #repo --name=&quot;My Updates&quot; --baseurl=http://192.168.1.3/fedora/10/updates/i386<br /> <br /> <br /> #<br /> # remove interactive for an automated install<br /> #<br /> interactive<br /> <br /> lang en_US.UTF-8<br /> keyboard us<br /> <br /> network --device eth0 --bootproto dhcp<br /> #network --device eth0 --bootproto static --ip 172.16.148.50 --netmask 255.255.255.0 --gateway 172.16.148.2 --nameserver 172.16.148.10<br /> <br /> <br /> #<br /> # make sure to change your password after installation, or during<br /> # for interactive installs<br /> #<br /> rootpw sefos1<br /> <br /> firewall --enabled --ssh --port=8140:tcp <br /> authconfig --enableshadow --enablemd5<br /> <br /> #<br /> # --Disable doesn't work. Selinux is still enabled.<br /> #<br /> selinux --permissive<br /> <br /> timezone --utc America/New_York<br /> bootloader --location=mbr <br /> <br /> reboot<br /> <br /> %packages --excludedocs --nobase<br /> @core<br /> yum<br /> openssh-server<br /> openssh-clients<br /> # optional packages<br /> audit<br /> audit-libs<br /> make<br /> perl<br /> man<br /> <br /> # basic networking tools<br /> dhclient<br /> bind-utils<br /> <br /> %end<br /> <br /> %post --erroronfail --log=/root/nklinstall.log<br /> <br /> # Boot arguments <br /> # get boot args beginning with 'se_'<br /> &lt; /proc/cmdline sed 's/ /\n/g' | grep ^se_ &gt; /tmp/boot_args <br /> . /tmp/boot_args<br /> <br /> <br /> ############# BOOT ARGUMENTS DEFAULTS ########################<br /> # Enter default values below!<br /> # If boot arguments exist, use them else use these<br /> <br /> # set default domain name if necessary<br /> if [ &quot;${se_dnsdomain}x&quot; == &quot;x&quot; ]; then<br /> se_dnsdomain=&quot;example.com&quot;<br /> fi<br /> <br /> # set default fqdn of system if necessary<br /> if [ &quot;${se_fqdn}x&quot; == &quot;x&quot; ]; then<br /> se_fqdn=&quot;puppetmaster.${se_dnsdomain}&quot;;<br /> fi<br /> <br /> # set default location of web server if none identified.<br /> if [ &quot;${se_www}x&quot; == &quot;x&quot; ]; then<br /> se_www=&quot;www.selinuxproject.org/~cgrube/puppet&quot;<br /> fi<br /> <br /> ############### NETWORK FILE TRANSFERS #######################<br /> # do initial update, this should just get the repository info<br /> /usr/bin/yum -y update | /usr/bin/tee -a /root/yumup.log<br /> echo | /usr/bin/tee -a /root/yumup.log<br /> <br /> #########################################<br /> # install custom selinux policy packages<br /> <br /> rpm -e selinux-policy-targeted selinux-policy<br /> <br /> # packages have the same version number, so just update<br /> # here if newer packages are made <br /> pv=3.6.12-78.fc11<br /> <br /> rpm -U --force http://${se_www}/packages/selinux-policy-${pv}.noarch.rpm http://${se_www}/packages/selinux-policy-doc-${pv}.noarch.rpm http://${se_www}/packages/selinux-policy-targeted-${pv}.noarch.rpm <br /> <br /> ## install puppet server<br /> /usr/bin/yum -y install puppet-server ruby-rdoc | /usr/bin/tee -a /root/yumup.log<br /> <br /> ## download and untar puppet policy to /etc/puppet<br /> /usr/bin/curl http://${se_www}/packages/puppet-policy.tar.gz -o /tmp/puppet-policy.tar.gz<br /> if [ -d /etc/puppet ]; then<br /> cd /etc/puppet &amp;&amp; tar -xzf /tmp/puppet-policy.tar.gz<br /> chown -R root:root /etc/puppet<br /> else <br /> echo &quot;/etc/puppet doesn't exist, unable to extract /tmp/puppet-policy.tar.gz&quot;<br /> fi<br /> <br /> ## relabel the file system to ensure all puppet files are appropriately <br /> ## labeled<br /> touch /.autorelabel<br /> <br /> ################# FILE CONFIGURATION ################<br /> # switch to enforcing mode<br /> /usr/bin/perl -p -i.sefback -e &quot;s/=disabled/=enforcing/&quot; /etc/selinux/config<br /> <br /> # set hostname<br /> /usr/bin/perl -p -i.sefback -e &quot;s/HOSTNAME=localhost.localdomain/HOSTNAME=${se_fqdn}/g&quot; /etc/sysconfig/network 2&gt;&amp;1<br /> <br /> # set default DNS search domain<br /> echo &quot;SEARCH=${se_dnsdomain}&quot; &gt;&gt; /etc/sysconfig/network-scripts/ifcfg-eth0<br /> <br /> # for some reason the network service isn't on by default, so when using<br /> # static addressing the interfaces never come up<br /> <br /> /sbin/chkconfig network on<br /> /sbin/chkconfig puppetmaster on<br /> <br /> %end<br /> <br /> &lt;/pre&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-14T22:47:10Z <p>CraigGrube: </p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Basic Infrastructure=<br /> ==Requirements==<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ==Packages==<br /> The server and client automated installs expect certain packages<br /> to be present in /packages/ on a web server designated during the<br /> kickstart install. The following packages are expected:<br /> <br /> * [[PuppetDemoServerKickstart| Server kickstart ]] file.<br /> * [[PuppetDemoClientKickstart| Client kickstart ]] file.<br /> <br /> * puppet-policy.tar.gz - gzipped tarball of the puppet policy is <br /> downloaded to the server and defines the desired end state of <br /> clients.<br /> <br /> * sefos-demo-policy-0.1-1.fc11.i386.rpm - RPM containing a small<br /> SELinux module required for some demo specific client configuration<br /> to work properly. This package is only downloaded to clients.<br /> <br /> * selinux-policy-{ver}.noarch.rpm, selinux-policy-targeted-{ver}.noarch.rpm -<br /> SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server.<br /> <br /> = Installation =<br /> == Server Kickstart ==<br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> === Example ===<br /> <br /> == Client Kickstart ==<br /> === Disk Partitioning ===<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ===Kernel Boot Options===<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded.<br /> <br /> ===Network Configuration===<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ===Example===<br /> When installing client1 only se_www needs to be specified as the default values for hostname, DNS Domain and Puppetmaster DNS name will be sufficient as long the demo environment is the same as the provided examples.<br /> <br /> Assuming no changes from the demo, se_fqdn and se_www should be used when kickstarting client2.<br /> <br /> == Manual Post Installation Configuraton ==<br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-14T22:39:10Z <p>CraigGrube: /* Example */</p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Demo=<br /> ==Basic Infrastructure==<br /> ===Requirements===<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ===Packages===<br /> The server and client automated installs expect certain packages<br /> to be present in /packages/ on a web server designated during the<br /> kickstart install. The following packages are expected:<br /> <br /> * [[PuppetDemoServerKickstart| Server kickstart ]] file.<br /> * [[PuppetDemoClientKickstart| Client kickstart ]] file.<br /> <br /> * puppet-policy.tar.gz - gzipped tarball of the puppet policy is <br /> downloaded to the server and defines the desired end state of <br /> clients.<br /> <br /> * sefos-demo-policy-0.1-1.fc11.i386.rpm - RPM containing a small<br /> SELinux module required for some demo specific client configuration<br /> to work properly. This package is only downloaded to clients.<br /> <br /> * selinux-policy-{ver}.noarch.rpm, selinux-policy-targeted-{ver}.noarch.rpm -<br /> SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server.<br /> <br /> == Installation ==<br /> === Server Kickstart ===<br /> ==== Disk Partitioning ====<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ====Kernel Boot Options====<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded.<br /> <br /> ====Network Configuration====<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ==== Example ====<br /> <br /> === Client Kickstart ===<br /> ==== Disk Partitioning ====<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ====Kernel Boot Options====<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded.<br /> <br /> ====Network Configuration====<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ====Example====<br /> When installing client1 only se_www needs to be specified as the default values for hostname, DNS Domain and Puppetmaster DNS name will be sufficient as long the demo environment is the same as the provided examples.<br /> <br /> Assuming no changes from the demo, se_fqdn and se_www should be used when kickstarting client2.<br /> <br /> === Manual Post Installation Configuraton ===<br /> <br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-14T22:31:44Z <p>CraigGrube: /* Packages */</p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Demo=<br /> ==Basic Infrastructure==<br /> ===Requirements===<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ===Packages===<br /> The server and client automated installs expect certain packages<br /> to be present in /packages/ on a web server designated during the<br /> kickstart install. The following packages are expected:<br /> <br /> * [[PuppetDemoServerKickstart| Server kickstart ]] file.<br /> * [[PuppetDemoClientKickstart| Client kickstart ]] file.<br /> <br /> * puppet-policy.tar.gz - gzipped tarball of the puppet policy is <br /> downloaded to the server and defines the desired end state of <br /> clients.<br /> <br /> * sefos-demo-policy-0.1-1.fc11.i386.rpm - RPM containing a small<br /> SELinux module required for some demo specific client configuration<br /> to work properly. This package is only downloaded to clients.<br /> <br /> * selinux-policy-{ver}.noarch.rpm, selinux-policy-targeted-{ver}.noarch.rpm -<br /> SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server.<br /> <br /> == Installation ==<br /> === Server Kickstart ===<br /> ==== Disk Partitioning ====<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ====Kernel Boot Options====<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded.<br /> <br /> ====Network Configuration====<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ==== Example ====<br /> <br /> === Client Kickstart ===<br /> ==== Disk Partitioning ====<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ====Kernel Boot Options====<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded.<br /> <br /> ====Network Configuration====<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ====Example====<br /> To install client1 only se_www needs to be specified. To install<br /> client2 se_fqdn and se_www should be used.<br /> <br /> <br /> === Manual Post Installation Configuraton ===<br /> <br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-14T22:31:20Z <p>CraigGrube: /* Packages */</p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Demo=<br /> ==Basic Infrastructure==<br /> ===Requirements===<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ===Packages===<br /> The server and client automated installs expect certain packages<br /> to be present in /packages/ on a web server designated during the<br /> kickstart install. The following packages are expected:<br /> <br /> * [[PuppetDemoServerKickstart|| Server kickstart ]] file.<br /> * [[PuppetDemoClientKickstart|| Client kickstart ]] file.<br /> <br /> * puppet-policy.tar.gz - gzipped tarball of the puppet policy is <br /> downloaded to the server and defines the desired end state of <br /> clients.<br /> <br /> * sefos-demo-policy-0.1-1.fc11.i386.rpm - RPM containing a small<br /> SELinux module required for some demo specific client configuration<br /> to work properly. This package is only downloaded to clients.<br /> <br /> * selinux-policy-{ver}.noarch.rpm, selinux-policy-targeted-{ver}.noarch.rpm -<br /> SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server.<br /> <br /> == Installation ==<br /> === Server Kickstart ===<br /> ==== Disk Partitioning ====<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ====Kernel Boot Options====<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded.<br /> <br /> ====Network Configuration====<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ==== Example ====<br /> <br /> === Client Kickstart ===<br /> ==== Disk Partitioning ====<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ====Kernel Boot Options====<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded.<br /> <br /> ====Network Configuration====<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ====Example====<br /> To install client1 only se_www needs to be specified. To install<br /> client2 se_fqdn and se_www should be used.<br /> <br /> <br /> === Manual Post Installation Configuraton ===<br /> <br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemoClientKickstart PuppetDemoClientKickstart 2009-09-14T22:29:38Z <p>CraigGrube: New page: The Puppet demo client kickstart: &lt;pre&gt; ########################################################## # Sefos Demo Client Kickstart file # # Purpose - # The purpose of the client kickstar...</p> <hr /> <div>The Puppet demo client kickstart:<br /> <br /> &lt;pre&gt;<br /> ##########################################################<br /> # Sefos Demo Client Kickstart file<br /> #<br /> # Purpose - <br /> # The purpose of the client kickstart is to build a very<br /> # basic systems (just base packages + Puppet and dependencies)<br /> # that will then be boot-strapped via Puppet. <br /> #<br /> # External Dependencies - <br /> # Installation: To install boot the system from FC9 <br /> # installation media (DVD, CD, netboot, etc). When the <br /> # grub interface appears, modify the boot options to load<br /> # the kickstart and provide the desired boot options to <br /> # customize the installation (i.e. ks=http://webserver/dir/<br /> # ks.cfg se_var1=val1 ...).<br /> #<br /> # Boot Options - <br /> #<br /> # se_dnsdomain - DNS domain of client (assumes example.com<br /> # if none provided)<br /> # se_fqdn - Fully qualified domain name of client (assumes<br /> # client1.${se_dnsdomain} if none provided)<br /> # se_pmaster - FQDN of Puppet server (assumes <br /> # puppetmaster.${se_dnsdomain} if none provided)<br /> # se_www - IP address of resolvable DNS name of web server<br /> # from which packages should be downloaded<br /> #<br /> # Assumptions:<br /> # Network address provisioning is with DHCP. IF static<br /> # addressing is desired uncomment and modify the static<br /> # network configuration line and comment the DHCP network<br /> # configuration line.<br /> #<br /> ##########################################################<br /> # Kickstart file<br /> <br /> install<br /> logging --level=info<br /> <br /> # XXX: Network install options<br /> #nfs --server=192.168.1.3 --dir=/site/isos/redhat/10/i386<br /> #url --url http://192.168.1.3/fedora/10/i386<br /> <br /> # XXX: use a local repo, if available<br /> #repo --name=&quot;My Updates&quot; --baseurl=http://192.168.1.3/fedora/10/updates/i386/<br /> <br /> #<br /> # remove interactive for an automated install<br /> #<br /> interactive<br /> <br /> lang en_US.UTF-8<br /> keyboard us<br /> <br /> network --device eth0 --bootproto dhcp<br /> #network --device eth0 --bootproto static --ip 172.16.148.51 --netmask 255.255.255.0 --gateway 172.16.148.2 --nameserver 172.16.148.10<br /> <br /> <br /> #<br /> # make sure to change your password after installation, or during<br /> # for interactive installs<br /> #<br /> rootpw sefos1<br /> <br /> firewall --enabled --ssh <br /> authconfig --enableshadow --enablemd5<br /> <br /> #<br /> # --Disable doesn't work. Selinux is still enabled.<br /> #<br /> selinux --permissive<br /> <br /> timezone --utc America/New_York<br /> bootloader --location=mbr <br /> <br /> reboot<br /> <br /> %packages --excludedocs --nobase<br /> @core<br /> perl<br /> yum<br /> openssh-server<br /> openssh-clients<br /> man<br /> <br /> # optional packages<br /> selinux-policy-targeted<br /> audit<br /> audit-libs<br /> dhclient<br /> bind-utils<br /> <br /> %end<br /> <br /> %post --erroronfail --log=/root/nklinstall.log<br /> <br /> # Boot arguments <br /> # get boot args beginning with 'se_'<br /> &lt; /proc/cmdline sed 's/ /\n/g' | grep ^se_ &gt; /tmp/boot_args<br /> . /tmp/boot_args<br /> <br /> <br /> <br /> ############# BOOT ARGUMENTS DEFAULTS ########################<br /> # Enter default values below!<br /> # If boot arguments exist, use them else use these<br /> <br /> # set default dns name if none provided<br /> if [ &quot;${se_dnsdomain}x&quot; == &quot;x&quot; ]; then<br /> se_dnsdomain=&quot;example.com&quot;<br /> fi<br /> <br /> # set default fqdn is none provided<br /> if [ &quot;${se_fqdn}x&quot; == &quot;x&quot; ]; then<br /> se_fqdn=&quot;client1.${se_dnsdomain}&quot;;<br /> fi<br /> <br /> # set default name of puppet server if none provided<br /> if [ &quot;${se_pmaster}x&quot; == &quot;x&quot; ]; then<br /> se_pmaster=&quot;puppetmaster.${se_dnsdomain}&quot;<br /> fi<br /> <br /> # set default location of web server for packages<br /> if [ &quot;${se_www}x&quot; == &quot;x&quot; ]; then<br /> se_www=&quot;172.16.148.10&quot;<br /> fi<br /> <br /> ############### NETWORK FILE TRANSFERS #######################<br /> # do initial update, this should just get the repository info<br /> /usr/bin/yum -y update | /usr/bin/tee -a /root/yumup.log<br /> echo | /usr/bin/tee -a /root/yumup.log<br /> <br /> ##########################################<br /> # install custom selinux policy packages<br /> pv=3.6.12-78.fc11<br /> <br /> rpm -e selinux-policy selinux-policy-targeted<br /> <br /> rpm -U --force http://${se_www}/packages/selinux-policy-${pv}.noarch.rpm http://${se_www}/packages/selinux-policy-doc-${pv}.noarch.rpm http://${se_www}/packages/selinux-policy-targeted-${pv}.noarch.rpm<br /> rpm -U http://${se_www}/packages/sefos-demo-policy-0.1-2.fc11.i386.rpm<br /> <br /> # install the puppet client<br /> /usr/bin/yum -y install puppet ruby-rdoc | /usr/bin/tee -a /root/yumup.log<br /> <br /> <br /> ################# FILE CONFIGURATION ################<br /> # switch to enforcing mode<br /> /usr/bin/perl -p -i.sefback -e &quot;s/=disabled/=enforcing/&quot; /etc/selinux/config<br /> <br /> # set hostname<br /> /usr/bin/perl -p -i.sefback -e &quot;s/HOSTNAME=localhost.localdomain/HOSTNAME=${se_fqdn}/g&quot; /etc/sysconfig/network 2&gt;&amp;1<br /> <br /> # set default DNS search domain<br /> echo &quot;SEARCH=${se_dnsdomain}&quot; &gt;&gt; /etc/sysconfig/network-scripts/ifcfg-eth0<br /> <br /> ## relabel file system at boot to ensure puppet files have right labels<br /> touch /.autorelabel<br /> <br /> # network service doesn't appear to be on by default, so turn it on to get clients with<br /> # static addressing working.<br /> <br /> /sbin/chkconfig network on<br /> /sbin/chkconfig puppet on<br /> <br /> # set puppet server <br /> echo &quot;# Begin automated kickstart configuration&quot; &gt;&gt; /etc/sysconfig/puppet<br /> echo &quot;PUPPET_SERVER=${se_pmaster}&quot; &gt;&gt; /etc/sysconfig/puppet<br /> <br /> %end<br /> &lt;/pre&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemoServerKickstart PuppetDemoServerKickstart 2009-09-14T22:28:12Z <p>CraigGrube: New page: The Puppet demo server kickstart file: &lt;pre&gt; ########################################################## # Puppet Demo Server Kickstart file # # Purpose - # The purpose of the server kic...</p> <hr /> <div>The Puppet demo server kickstart file:<br /> <br /> &lt;pre&gt;<br /> ##########################################################<br /> # Puppet Demo Server Kickstart file<br /> #<br /> # Purpose - <br /> # The purpose of the server kickstart is to build a <br /> # basic Puppet server. The installation is small (essentially<br /> # just base packages + Puppet and dependencies), so many <br /> # administrative and user packages are not installed.<br /> #<br /> # External Dependencies - <br /> # Installation: To install boot the system from FC9 <br /> # installation media (DVD, CD, netboot, etc). When the <br /> # grub interface appears, modify the boot options to load<br /> # the kickstart and provide the desired boot options to <br /> # customize the installation (i.e. ks=http://webserver/dir/<br /> # ks.cfg se_var1=val1 ...).<br /> #<br /> # Boot Options - <br /> # se_dnsdomain - DNS domain of server (assumes example.com<br /> # if none is provided)<br /> # se_fqdn - Fully qualified domain name of server (assumes<br /> # puppetmaster.${se_dnsdomain} if none is provided.)<br /> # se_www - IP or resolvable DNS name of web server to<br /> # from which to download packages. Assuming path<br /> # of /packages/ from web root to various packages.<br /> #<br /> # Assumptions:<br /> # By default network address provisioning is via DHCP. If<br /> # static addressing is required uncomment and modify the <br /> # network configuration for static addressing.<br /> #<br /> ##########################################################<br /> # Kickstart file<br /> <br /> install<br /> logging --level=info<br /> <br /> ## examples of repo sources if using local repos via http or nfs<br /> #nfs --server=192.168.1.3 --dir=/site/isos/redhat/10/i386<br /> #url --url http://192.168.1.3/fedora/10/i386<br /> <br /> # XXX: use a local repo , if available<br /> #repo --name=&quot;My Updates&quot; --baseurl=http://192.168.1.3/fedora/9/updates/i386<br /> #repo --name=&quot;My Updates&quot; --baseurl=http://192.168.1.3/fedora/10/updates/i386<br /> <br /> <br /> #<br /> # remove interactive for an automated install<br /> #<br /> interactive<br /> <br /> lang en_US.UTF-8<br /> keyboard us<br /> <br /> network --device eth0 --bootproto dhcp<br /> #network --device eth0 --bootproto static --ip 172.16.148.50 --netmask 255.255.255.0 --gateway 172.16.148.2 --nameserver 172.16.148.10<br /> <br /> <br /> #<br /> # make sure to change your password after installation, or during<br /> # for interactive installs<br /> #<br /> rootpw sefos1<br /> <br /> firewall --enabled --ssh --port=8140:tcp <br /> authconfig --enableshadow --enablemd5<br /> <br /> #<br /> # --Disable doesn't work. Selinux is still enabled.<br /> #<br /> selinux --permissive<br /> <br /> timezone --utc America/New_York<br /> bootloader --location=mbr <br /> <br /> reboot<br /> <br /> %packages --excludedocs --nobase<br /> @core<br /> yum<br /> openssh-server<br /> openssh-clients<br /> # optional packages<br /> audit<br /> audit-libs<br /> make<br /> perl<br /> man<br /> <br /> # basic networking tools<br /> dhclient<br /> bind-utils<br /> <br /> %end<br /> <br /> %post --erroronfail --log=/root/nklinstall.log<br /> <br /> # Boot arguments <br /> # get boot args beginning with 'se_'<br /> &lt; /proc/cmdline sed 's/ /\n/g' | grep ^se_ &gt; /tmp/boot_args <br /> . /tmp/boot_args<br /> <br /> <br /> ############# BOOT ARGUMENTS DEFAULTS ########################<br /> # Enter default values below!<br /> # If boot arguments exist, use them else use these<br /> <br /> # set default domain name if necessary<br /> if [ &quot;${se_dnsdomain}x&quot; == &quot;x&quot; ]; then<br /> se_dnsdomain=&quot;example.com&quot;<br /> fi<br /> <br /> # set default fqdn of system if necessary<br /> if [ &quot;${se_fqdn}x&quot; == &quot;x&quot; ]; then<br /> se_fqdn=&quot;puppetmaster.${se_dnsdomain}&quot;;<br /> fi<br /> <br /> # set default location of web server if none identified.<br /> if [ &quot;${se_www}x&quot; == &quot;x&quot; ]; then<br /> se_www=172.16.148.10<br /> fi<br /> <br /> ############### NETWORK FILE TRANSFERS #######################<br /> # do initial update, this should just get the repository info<br /> /usr/bin/yum -y update | /usr/bin/tee -a /root/yumup.log<br /> echo | /usr/bin/tee -a /root/yumup.log<br /> <br /> #########################################<br /> # install custom selinux policy packages<br /> <br /> rpm -e selinux-policy-targeted selinux-policy<br /> <br /> # packages have the same version number, so just update<br /> # here if newer packages are made <br /> pv=3.6.12-78.fc11<br /> <br /> rpm -U --force http://${se_www}/packages/selinux-policy-${pv}.noarch.rpm http://${se_www}/packages/selinux-policy-doc-${pv}.noarch.rpm http://${se_www}/packages/selinux-policy-targeted-${pv}.noarch.rpm <br /> <br /> ## install puppet server<br /> /usr/bin/yum -y install puppet-server ruby-rdoc | /usr/bin/tee -a /root/yumup.log<br /> <br /> ## download and untar puppet policy to /etc/puppet<br /> /usr/bin/curl http://${se_www}/packages/puppet-policy.tar.gz -o /tmp/puppet-policy.tar.gz<br /> if [ -d /etc/puppet ]; then<br /> cd /etc/puppet &amp;&amp; tar -xzf /tmp/puppet-policy.tar.gz<br /> chown -R root:root /etc/puppet<br /> else <br /> echo &quot;/etc/puppet doesn't exist, unable to extract /tmp/puppet-policy.tar.gz&quot;<br /> fi<br /> <br /> ## relabel the file system to ensure all puppet files are appropriately <br /> ## labeled<br /> touch /.autorelabel<br /> <br /> ################# FILE CONFIGURATION ################<br /> # switch to enforcing mode<br /> /usr/bin/perl -p -i.sefback -e &quot;s/=disabled/=enforcing/&quot; /etc/selinux/config<br /> <br /> # set hostname<br /> /usr/bin/perl -p -i.sefback -e &quot;s/HOSTNAME=localhost.localdomain/HOSTNAME=${se_fqdn}/g&quot; /etc/sysconfig/network 2&gt;&amp;1<br /> <br /> # set default DNS search domain<br /> echo &quot;SEARCH=${se_dnsdomain}&quot; &gt;&gt; /etc/sysconfig/network-scripts/ifcfg-eth0<br /> <br /> # for some reason the network service isn't on by default, so when using<br /> # static addressing the interfaces never come up<br /> <br /> /sbin/chkconfig network on<br /> /sbin/chkconfig puppetmaster on<br /> <br /> %end<br /> &lt;/pre&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-14T22:23:24Z <p>CraigGrube: /* Requirements */</p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Demo=<br /> ==Basic Infrastructure==<br /> ===Requirements===<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> [[PuppetDemoBootServer]] contains instructions for setting up a system to provide DHCP, DNS and HTTP services for<br /> initializing the demonstration.<br /> <br /> ===Packages===<br /> The server and client automated installs expect certain packages<br /> to be present in /packages/ on a web server designated during the<br /> kickstart install. The following packages are expected:<br /> <br /> *puppet-policy.tar.gz - gzipped tarball of the puppet policy is <br /> downloaded to the server and defines the desired end state of <br /> clients.<br /> <br /> *sefos-demo-policy-0.1-1.fc11.i386.rpm - RPM containing a small<br /> SELinux module required for some demo specific client configuration<br /> to work properly. This package is only downloaded to clients.<br /> <br /> *selinux-policy-{ver}.noarch.rpm, selinux-policy-targeted-{ver}.noarch.rpm -<br /> SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server. <br /> <br /> The packages can be downloaded from LOCATION.<br /> <br /> == Installation ==<br /> === Server Kickstart ===<br /> ==== Disk Partitioning ====<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ====Kernel Boot Options====<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded.<br /> <br /> ====Network Configuration====<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ==== Example ====<br /> <br /> === Client Kickstart ===<br /> ==== Disk Partitioning ====<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ====Kernel Boot Options====<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded.<br /> <br /> ====Network Configuration====<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ====Example====<br /> To install client1 only se_www needs to be specified. To install<br /> client2 se_fqdn and se_www should be used.<br /> <br /> <br /> === Manual Post Installation Configuraton ===<br /> <br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/PuppetDemoBootServer PuppetDemoBootServer 2009-09-14T22:21:41Z <p>CraigGrube: New page: This pages briefly describes how to build a boot server for use with the Puppet demonstration. =General Notes= The sample configurations assume a local network using the 192.168.201.0/24 ...</p> <hr /> <div>This pages briefly describes how to build a boot server for use with the Puppet demonstration.<br /> <br /> =General Notes=<br /> The sample configurations assume a local network using the 192.168.201.0/24 address block. Network ranges/addresses should be modified to match those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration examples and in the demo environment. The domain may be modified to match an existing domain. Changes to the kickstarts will be required to set the new default domain and to change the creation of the ldap structure if the domain name is increased beyond two levels.<br /> <br /> The location of the configuration files identified for the boot server configuration are assuming Fedora Core 11 is the host operating system. Different release versions or distributions may place the configuration files in different locations.<br /> <br /> As the DNS, DHCP, and HTTP servers need to be accessible to remote systems, the boot server firewall may need to be configured to allow incoming connections from the local network to these ports:<br /> <br /> * 80/tcp<br /> * 67/udp<br /> * 53/udp <br /> <br /> =Installing packages=<br /> <br /> The YUM package tool is used to install packages. This requires a connection to the Internet to connect to remote package repositories, or a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated packages. <br /> <br /> =Setting up the DHCP server=<br /> <br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The example provided is one that is being used in a VMware environment.<br /> &lt;pre&gt;<br /> [excerpt from sample /etc/dhcpd.conf]<br /> <br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host puppetmaster {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;puppetmaster.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it might be useful to generate that portion of the DHCPD config file from a flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> =Setting up the DNS Server=<br /> <br /> packages: named<br /> <br /> The default configuration will only listen on the &lt;code&gt;localhost&lt;/code&gt; address. You will need to set the listen-on and allow-query addresses in the options section of &lt;code&gt;/etc/named.conf&lt;/code&gt; so that named can respond to queries on the local network.<br /> <br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> <br /> Add forward and reverse zones for the address range in use:<br /> <br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> puppetmaser A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> client2 A 192.168.201.51<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> <br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR puppetmaster.example.com.<br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named on<br /> &lt;/pre&gt;<br /> <br /> =Setting up the Web server=<br /> <br /> packages: httpd<br /> <br /> Download the latest versions of the kickstart files and binary RPMs as identified in the [[PuppetDemo || Puppet demonstration]].<br /> * Client Kickstart<br /> * Server Kickstart<br /> * Custom SELinux Policy packages <br /> <br /> Create a directory to hold the kickstart files, &lt;code&gt;/var/www/html/kickstart&lt;/code&gt;. Copy the client and server kickstart files into this directory.<br /> <br /> Create a directory to hold the packages, &lt;code&gt;/var/www/html/packages&lt;/code&gt;. Copy the custom SELinux Policy packages and the Puppet configuration tarball into this directory.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> <br /> =Kickstart Customization and System Installation=<br /> <br /> Documentation at the beginning of the kickstart files details some boot time options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> <br /> * Depending on the network environment the kickstart can be configured to use DHCP for address provisioning or static addressing. The default is to use DHCP, however a sample static address configuration is included for reference. If addresses are assigned statically, the kickstarts will need to be modified for each client/server installation (to provide the appropriate address).<br /> * If installing FC11 from CD/DVD access to a yum repository (via external network connection or local mirror) is required as some packages required for the installs are not included in the CD/DVD install media.<br /> * Installs are currently interactive. To convert the kickstarts to a fully automated install comment out the &quot;interactive&quot; directive at the beginning of the files.</div> CraigGrube http://selinuxproject.org/page/PuppetDemo PuppetDemo 2009-09-13T19:55:31Z <p>CraigGrube: *</p> <hr /> <div>=Overview=<br /> This page describes a proposed demonstration showing how to manage<br /> systems running SELinux using Puppet, an open-source enterprise grade configuration <br /> management tool. The goals of the demonstration are to show that configuration management<br /> systems can conveniently manage multiple SELinux clients, provide examples for configuring<br /> SELinux clients, and develop policy to constrain the client and server.<br /> <br /> The demonstration will use Puppet to bootstrap client systems to the desired <br /> server type and ensure that SELinux is properly configured to protect the services. <br /> <br /> =Components=<br /> The demonstration includes Fedora 11 kickstart files for the two main components: a Puppet <br /> server and a generic client. The example Puppet policy will transform two generic clients <br /> will be transformed into fully configured and functional servers with appropriate SELinux <br /> configurations once joined to the Puppet server.<br /> <br /> While the number of clients is , the fully configured clients are intended to be similar<br /> to some of what might be found in an enterprise environment. Specifically, following <br /> successful configuration client will be turned into a web server or a mail server. <br /> <br /> The web server will be configured as follows:<br /> *Packages<br /> **Install Apache and dependencies<br /> *Users/Groups<br /> **Add apache user with specific UID<br /> **Add apache group with specific GID<br /> *Apache Configuration<br /> **Add of three virtual hosts (client1, client1a, client1b) <br /> **Configure one of the virtual hosts to allow sharing of files from users's public_html directories<br /> *SELinux Configuration<br /> **Ensure updated files have the desired type<br /> **Ensure httpd SELinux module is loaded<br /> **Ensure httpd_enable_homedirs SELinux boolean is enabled<br /> <br /> The email server will be configured as follows:<br /> *Packages<br /> **Remove default Exim package<br /> **Install postfix<br /> *Users/Groups<br /> **Add postfix user with specific UID<br /> **Add postfix group with specific GID<br /> *Postfix Configuration<br /> **Apply basic main.cf from template<br /> *SELinux Configuration<br /> **Apply desired file labels to updated files<br /> **Ensure {module} is loaded<br /> **Ensure allow_postfix_local_write_mail_spool SELinux boolean is on<br /> <br /> =Demo=<br /> ==Basic Infrastructure==<br /> ===Requirements===<br /> Working forward/reverse DNS is needed for OpenSSL certificates to work properly for client/server<br /> authentication and data encryption. <br /> <br /> For the demo to work properly with no modifications <br /> to the puppet policy the DNS server should be able to resolve<br /> two client hostnames (client1, client2) as well as two<br /> CNAMES for client1 (client1a, client1b - because the<br /> default puppet policy will set up three Apache virtual hosts<br /> on client1.) <br /> <br /> An example partial zone configuration for the demo could be:<br /> &lt;pre&gt;<br /> puppetmaster A 192.168.1.174<br /> client1 A 192.168.1.175<br /> client2 A 192.168.1.176<br /> client1a CNAME client1<br /> client1b CNAME client1<br /> &lt;/pre&gt;<br /> <br /> The matching reverse zone configuration could be:<br /> <br /> &lt;pre&gt;<br /> 174 IN PTR puppetmaster.example.com.<br /> 175 IN PTR client1.example.com.<br /> 176 IN PTR client2.example.com.<br /> &lt;/pre&gt;<br /> <br /> BOOTSERVER contains instuctions for setting up a system to provide DHCP, DNS and HTTP services for<br /> configuring the demonstration server and client.<br /> <br /> ===Packages===<br /> The server and client automated installs expect certain packages<br /> to be present in /packages/ on a web server designated during the<br /> kickstart install. The following packages are expected:<br /> <br /> *puppet-policy.tar.gz - gzipped tarball of the puppet policy is <br /> downloaded to the server and defines the desired end state of <br /> clients.<br /> <br /> *sefos-demo-policy-0.1-1.fc11.i386.rpm - RPM containing a small<br /> SELinux module required for some demo specific client configuration<br /> to work properly. This package is only downloaded to clients.<br /> <br /> *selinux-policy-{ver}.noarch.rpm, selinux-policy-targeted-{ver}.noarch.rpm -<br /> SELinux policy RPMs including new policy to constrain the Puppet client<br /> and server. <br /> <br /> The packages can be downloaded from LOCATION.<br /> <br /> == Installation ==<br /> === Server Kickstart ===<br /> ==== Disk Partitioning ====<br /> The default anaconda chosen disk partitioning scheme is used <br /> unless modified by person performing the installation. 1G+ of <br /> disk space is recommended. <br /> <br /> ====Kernel Boot Options====<br /> Kernel boot options for server configuration are:<br /> *se_dnsdomain - dns domain of server (assumes example.com if none provided)<br /> *se_fqdn - fully qualified domain name of server (set to puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or hostname of web server from which packages (selinux policy and puppet policy) should<br /> be downloaded.<br /> <br /> ====Network Configuration====<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network'<br /> line, and uncomment and edit the 'network' line containing the<br /> static address and modify as needed.<br /> <br /> ==== Example ====<br /> <br /> === Client Kickstart ===<br /> ==== Disk Partitioning ====<br /> The default anaconda chosen disk partitioning scheme is used<br /> unless modified during the installation. 1G+ of<br /> disk space is recommended.<br /> <br /> ====Kernel Boot Options====<br /> Kernel boot options for client configuration are:<br /> *se_dnsdomain - dns domain of client (assumes example.com if not provided))<br /> *se_fqdn - fully qualified domain name of client (assumes client1.${se_dnsdomain} if none provided)<br /> *se_pmaster - FQDN of puppetmaster server (assumes puppetmaster.${se_dnsdomain} if none provided)<br /> *se_www - IP address or resolvable DNS name of web server from which packages can be downloaded.<br /> <br /> ====Network Configuration====<br /> By default DHCP is used for network address provisioning.<br /> <br /> If static addressing is desired/required comment out DHCP 'network' line, and uncomment and edit the 'network' line containing the static address.<br /> <br /> ====Example====<br /> To install client1 only se_www needs to be specified. To install<br /> client2 se_fqdn and se_www should be used.<br /> <br /> <br /> === Manual Post Installation Configuraton ===<br /> <br /> During the kickstart of the server and one or more clients, the clients Puppet service will<br /> contact the server and submit a certificate for signing. To list unsigned certificates on<br /> the server run &lt;code&gt;puppetca -l&lt;/code&gt;. For each demo client run &lt;code&gt;puppetca -s {hostname}&lt;/code&gt;<br /> to sign the client certificates.<br /> <br /> The clients will automatically download the signed certificate at the next update (approximately every <br /> 30 minutes) and will download and apply the configuration from the server. To force an immediate update<br /> the puppet client service can be restarted with &lt;code&gt;run_init service puppet restart&lt;/code&gt;</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-23T14:31:06Z <p>CraigGrube: /* Server */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service enables files to be accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users access files from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a simple network accessible directory service. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = SELinux = <br /> <br /> SELinux policy and configuration changes are required on both the client and server for all of the services to function properly together. Supplementary SELinux policy modules were developed for installation on the NFS server to augment the stock policy package. On the client several booleans needed to be turned on to allow the client side services to interact properly. <br /> <br /> == Server == <br /> <br /> The server SELinux policy is largely a stock Fedora policy package, with some custom policy to address some existing issues not addressed by the stock policy that prevent RPC and NFS services from functioning properly. The stock policy defines domains and types<br /> for the network services that limit access to required system resources and contain failures. Additional SELinux policy was developed as the services required access to additional resources beyond those granted in the stock policy to function properly. The server policy source RPM contains source for the following policies:<br /> <br /> * sefosrpc - The stock SELinux policy provides the required domains and types, but is supplemented to allow portmap to bind to network ports and for creation of a socket file in /var/run.<br /> * sefosnfsserver - As with the RPC policy, the stock SELinux policy provides the required domains and types, but is supplemented to allow the creation/management of files in /var/lib/nfs, and allow the starting/stopping of services required for NFS (nfsd, rpc.gssd, idmapd, etc).<br /> <br /> Another policy module (sefosexports) is required<br /> to grant the NFS kernel server access to the file types being exported. The set of types allowed for export is fairly minimal, by default including the following types:<br /> <br /> * Read-Only Directories<br /> ** mnt_t - The NFS server requires at least read access to the parent directories of an exported directory. In the demonstration /mnt/export/home is exported, and as /mnt is of type mnt_t, read only access is required.<br /> ** home_root_t - This is the type of /home (and /mnt/export/home as it is /home via a local bind mount). In the demonstration user creation (and thus the creation of their home directories) is performed locally on the NFS server, so read-only and not read-write access is required by the NFS server.<br /> * Read-Write Directories and Files<br /> ** user_home_t - User files are by default of type user_home_t. Read-write access is required for remote users to create and manage files.<br /> <br /> == Client == <br /> <br /> The client SELinux policy is a stock Fedora policy package. Three booleans are enabled to allow Kerberos, NFS and RPC GSSD to function properly. The three SELinux booleans are:<br /> <br /> * allow_kerberos - required for client-side Kerberos to function properly<br /> * allow_gssd_read_tmp - required for RPC GSSD to read cached Kerberos credentials in /tmp (for passing credentials between NFS client and server)<br /> * use_nfs_home_dirs - allow home directories (/home) to be mounted via NFS<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/CustomizingServerPolicy|Customizing the Server SELinux Policy]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc6-7.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-23T14:30:35Z <p>CraigGrube: /* SELinux */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service enables files to be accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users access files from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a simple network accessible directory service. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = SELinux = <br /> <br /> SELinux policy and configuration changes are required on both the client and server for all of the services to function properly together. Supplementary SELinux policy modules were developed for installation on the NFS server to augment the stock policy package. On the client several booleans needed to be turned on to allow the client side services to interact properly. <br /> <br /> == Server == <br /> <br /> The server SELinux policy is largely a stock Fedora policy package, with some custom policy to address some existing issues not addressed by the stock policy that prevent RPC and NFS services from functioning properly. The stock policy defines domains and types<br /> for the network services that limit access to required system resources and contain failures. Additional SELinux policy was developed as the services required access to additional resources beyond those granted in the stock policy to function properly. The server policy source RPM contains source for the following policies:<br /> <br /> * sefosrpc - The stock SELinux policy provides the required domains and types, but is supplemented to allow portmap to bind to network ports and for creation of a socket file in /var/run.<br /> * sefosnfsserver - As with the RPC policy, the stock SELinux policy provides the required domains and types, but is supplemented to allow the creation/management of files in /var/lib/nfs, and allow the starting/stopping of services required for NFS (nfsd, rpc.gssd, idmapd, etc).<br /> <br /> Another policy module (sefosexports.[te|if]) are required<br /> to grant the NFS kernel server access to the file types being exported. The set of types allowed for export is fairly minimal, by default including the following types:<br /> <br /> * Read-Only Directories<br /> ** mnt_t - The NFS server requires at least read access to the parent directories of an exported directory. In the demonstration /mnt/export/home is exported, and as /mnt is of type mnt_t, read only access is required.<br /> ** home_root_t - This is the type of /home (and /mnt/export/home as it is /home via a local bind mount). In the demonstration user creation (and thus the creation of their home directories) is performed locally on the NFS server, so read-only and not read-write access is required by the NFS server.<br /> * Read-Write Directories and Files<br /> ** user_home_t - User files are by default of type user_home_t. Read-write access is required for remote users to create and manage files.<br /> <br /> == Client == <br /> <br /> The client SELinux policy is a stock Fedora policy package. Three booleans are enabled to allow Kerberos, NFS and RPC GSSD to function properly. The three SELinux booleans are:<br /> <br /> * allow_kerberos - required for client-side Kerberos to function properly<br /> * allow_gssd_read_tmp - required for RPC GSSD to read cached Kerberos credentials in /tmp (for passing credentials between NFS client and server)<br /> * use_nfs_home_dirs - allow home directories (/home) to be mounted via NFS<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/CustomizingServerPolicy|Customizing the Server SELinux Policy]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc6-7.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-23T14:27:51Z <p>CraigGrube: /* SELinux */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service enables files to be accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users access files from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a simple network accessible directory service. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = SELinux = <br /> <br /> SELinux policy and configuration changes are required on both the client and server for all of the services to function properly together. Supplementary SELinux policy modules were developed for installation on the NFS server to provide necessary augmentations to the stock policy. On the client several booleans needed to be turned on to allow the client side services to interact properly. <br /> <br /> == Server == <br /> <br /> The server SELinux policy is largely a stock Fedora policy package, with some custom policy to address some existing issues not addressed by the stock policy that prevent RPC and NFS services from functioning properly. The stock policy defines domains and types<br /> for the network services that limit access to required system resources and contain failures. Additional SELinux policy was developed as the services required access to additional resources beyond those granted in the stock policy to function properly. The server policy source RPM contains source for the following policies:<br /> <br /> * sefosrpc - The stock SELinux policy provides the required domains and types, but is supplemented to allow portmap to bind to network ports and for creation of a socket file in /var/run.<br /> * sefosnfsserver - As with the RPC policy, the stock SELinux policy provides the required domains and types, but is supplemented to allow the creation/management of files in /var/lib/nfs, and allow the starting/stopping of services required for NFS (nfsd, rpc.gssd, idmapd, etc).<br /> <br /> The NFS server used in the demonstration is the Linux kernel NFS server. Another policy module (sefosexports.[te|if]) are required<br /> to grant the NFS kernel server access to the file types being exported. The set of types allowed for export is fairly minimal, by default including the following types:<br /> <br /> * Read-Only Directories<br /> ** mnt_t - The NFS server requires at least read access to the parent directories of an exported directory. In the demonstration /mnt/export/home is exported, and as /mnt is of type mnt_t, read only access is required.<br /> ** home_root_t - This is the type of /home (and /mnt/export/home as it is /home via a local bind mount). In the demonstration user creation (and thus the creation of their home directories) is performed locally on the NFS server, so read-only and not read-write access is required by the NFS server.<br /> * Read-Write Directories and Files<br /> ** user_home_t - User files are by default of type user_home_t. Read-write access is required for remote users to create and manage files.<br /> <br /> == Client == <br /> <br /> The client SELinux policy is a stock Fedora policy package. Three booleans are enabled to allow Kerberos, NFS and RPC GSSD to function properly. The three SELinux booleans are:<br /> <br /> * allow_kerberos - required for client-side Kerberos to function properly<br /> * allow_gssd_read_tmp - required for RPC GSSD to read cached Kerberos credentials in /tmp (for passing credentials between NFS client and server)<br /> * use_nfs_home_dirs - allow home directories (/home) to be mounted via NFS<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/CustomizingServerPolicy|Customizing the Server SELinux Policy]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc6-7.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-23T14:25:06Z <p>CraigGrube: </p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service enables files to be accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users access files from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a simple network accessible directory service. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = SELinux = <br /> <br /> SELinux policy and configuration changes are required on both the client and server for all of the services to function properly together. Due to deficiencies in the stock Fedora policy package, supplementary SELinux policy modules were developed for installation on the NFS server. On the client several booleans needed to be turned on to allow the client side services to interact properly. <br /> <br /> == Server == <br /> <br /> The server SELinux policy is largely a stock Fedora policy package, with some custom policy to address some existing issues not addressed by the stock policy that prevent RPC and NFS services from functioning properly. The stock policy defines domains and types<br /> for the network services that limit access to required system resources and contain failures. Additional SELinux policy was developed as the services required access to additional resources beyond those granted in the stock policy to function properly. The server policy source RPM contains source for the following policies:<br /> <br /> * sefosrpc - The stock SELinux policy provides the required domains and types, but is supplemented to allow portmap to bind to network ports and for creation of a socket file in /var/run.<br /> * sefosnfsserver - As with the RPC policy, the stock SELinux policy provides the required domains and types, but is supplemented to allow the creation/management of files in /var/lib/nfs, and allow the starting/stopping of services required for NFS (nfsd, rpc.gssd, idmapd, etc).<br /> <br /> The NFS server used in the demonstration is the Linux kernel NFS server. Another policy module (sefosexports.[te|if]) are required<br /> to grant the NFS kernel server access to the file types being exported. The set of types allowed for export is fairly minimal, by default including the following types:<br /> <br /> * Read-Only Directories<br /> ** mnt_t - The NFS server requires at least read access to the parent directories of an exported directory. In the demonstration /mnt/export/home is exported, and as /mnt is of type mnt_t, read only access is required.<br /> ** home_root_t - This is the type of /home (and /mnt/export/home as it is /home via a local bind mount). In the demonstration user creation (and thus the creation of their home directories) is performed locally on the NFS server, so read-only and not read-write access is required by the NFS server.<br /> * Read-Write Directories and Files<br /> ** user_home_t - User files are by default of type user_home_t. Read-write access is required for remote users to create and manage files.<br /> <br /> == Client == <br /> <br /> The client SELinux policy is a stock Fedora policy package. Three booleans are enabled to allow Kerberos, NFS and RPC GSSD to function properly. The three SELinux booleans are:<br /> <br /> * allow_kerberos - required for client-side Kerberos to function properly<br /> * allow_gssd_read_tmp - required for RPC GSSD to read cached Kerberos credentials in /tmp (for passing credentials between NFS client and server)<br /> * use_nfs_home_dirs - allow home directories (/home) to be mounted via NFS <br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/CustomizingServerPolicy|Customizing the Server SELinux Policy]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc6-7.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-22T16:47:46Z <p>CraigGrube: /* Packages */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service enables files to be accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users access files from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a simple network accessible directory service. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/CustomizingServerPolicy|Customizing the Server SELinux Policy]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc6-7.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/CustomizingServerPolicy Labeled NFS/Demo/CustomizingServerPolicy 2008-12-22T14:55:15Z <p>CraigGrube: /* Building the policy */</p> <hr /> <div>= Introduction = <br /> <br /> The server policy contains three SELinux policy modules that are required for NFS to function properly. This section will not cover the specifics of the sefosnfsserver and sefosrpc policies, but will focus on the sefosexports policy. The sefosnfsserver and sefosrpc policies are required for the NFS server and related RPC services to function properly. The sefosexports policy is required to allow the NFS server to access and manage files being shared to the clients.<br /> <br /> = Sample Policy = <br /> &lt;pre&gt;<br /> module sefosexports 1.0.0;<br /> <br /> require {<br /> ## specific to access files/dirs in exports<br /> type mnt_t;<br /> type home_root_t;<br /> type user_home_dir_t;<br /> type user_home_t;<br /> type kernel_t;<br /> type nfsd_t;<br /> <br /> class file { create open getattr setattr read write append rename link unlink ioctl lock };<br /> class dir { create open getattr setattr read write link unlink rename search add_name remove_name reparent rmdir<br /> lock ioctl };<br /> class udp_socket { name_bind listen };<br /> class lnk_file {create getattr unlink};<br /> }<br /> <br /> ## specifc to type of exported dirs<br /> nfs_ro_export_dir_type(mnt_t);<br /> nfs_ro_export_dir_type(home_root_t);<br /> nfs_rw_export_type(user_home_t);<br /> &lt;/pre&gt;<br /> <br /> The policy shown above provides the NFS server read-only access to three file types (using the nfs_ro_export_dir_type macro):<br /> * mnt_t - /mnt, /mnt/export<br /> * home_root_t - /mnt/export/home<br /> <br /> The policy provides read-write access to one file type (using the nfs_rw_export_type macro):<br /> * user_home_t - /mnt/export/home/newuser<br /> <br /> The two macros should make it fairly easy to allow the NFS server to access additional file types. To allow the NFS server to access additional types, simply add the type in the requires block and apply the appropriate macro. There currently is no macro to provide read-only access to a file type, but it should be fairly trivial to create one modeled after the read-write macro.<br /> <br /> = Modifying the policy = <br /> For the example of policy modification we will be adding read-write access to the type httpd_user_content_t.<br /> <br /> Here are the steps required to modify the policy:<br /> &lt;ol&gt;<br /> &lt;li&gt;Install the server policy source RPM<br /> &lt;pre&gt;rpm -i sefos-server-policy-0.2-1.fc9.src.rpm&lt;/pre&gt;<br /> <br /> &lt;li&gt;Change directory to &lt;code&gt;/usr/src/redhat/SOURCES&lt;/code&gt;<br /> &lt;li&gt;Extract the policy archive:<br /> &lt;pre&gt;tar -xzf sefos-server-policy-0.2.tar.gz&lt;/pre&gt;<br /> &lt;li&gt;Edit the sefeosexports.te file:<br /> &lt;ol&gt;<br /> &lt;li&gt;Increment the module version number.<br /> &lt;li&gt;In the requires section add the following to allow us to later reference the httpd_user_content_t type:<br /> &lt;pre&gt;type httpd_user_content_t;&lt;/pre&gt;<br /> &lt;li&gt;At the end of the file add a line to allow read-write access to the httpd_user_content_t type:<br /> &lt;/ol&gt;<br /> &lt;pre&gt;nfs_rw_export_type(httpd_user_content_t);&lt;/pre&gt;<br /> &lt;li&gt;In /usr/src/redhat/SOURCES recreate the tarball: <br /> &lt;pre&gt;<br /> tar -czvf sefos-server-policy-0.2.tar.gz sefos-server-policy-0.2<br /> &lt;/pre&gt;<br /> &lt;/ol&gt;<br /> <br /> = Building the policy =<br /> We recommend incrementing the release number to allow the package to be upgraded, instead of forcing the administrator to remove the old version and install the new version. To do so edit &lt;code&gt;/usr/src/redhat/SPECS/sefos-server-policy.spec&lt;/code&gt;. Increment the number in the line that looks similar to the following:<br /> &lt;pre&gt;<br /> Release: 1%{?dist}<br /> &lt;/pre&gt;<br /> <br /> <br /> To build the binary RPM run (use -ba to build binary and source packages or -bs for building just the source package):<br /> &lt;pre&gt;<br /> rpmbuild -bb /usr/src/redhat/SPECS/sefos-server-policy.spec<br /> &lt;/pre&gt;<br /> <br /> = Installing the policy = <br /> Use &lt;code&gt;rpm&lt;/code&gt; to upgrade the policy on the server:<br /> &lt;pre&gt;<br /> rpm --upgrade /usr/src/redhat/RPMS/i386/sefos-server-policy-0.2-2.fc9.i386.rpm<br /> &lt;/pre&gt;<br /> <br /> You should now be able to access the new file type through NFS.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/CustomizingServerPolicy Labeled NFS/Demo/CustomizingServerPolicy 2008-12-22T14:54:53Z <p>CraigGrube: /* Installing the policy */</p> <hr /> <div>= Introduction = <br /> <br /> The server policy contains three SELinux policy modules that are required for NFS to function properly. This section will not cover the specifics of the sefosnfsserver and sefosrpc policies, but will focus on the sefosexports policy. The sefosnfsserver and sefosrpc policies are required for the NFS server and related RPC services to function properly. The sefosexports policy is required to allow the NFS server to access and manage files being shared to the clients.<br /> <br /> = Sample Policy = <br /> &lt;pre&gt;<br /> module sefosexports 1.0.0;<br /> <br /> require {<br /> ## specific to access files/dirs in exports<br /> type mnt_t;<br /> type home_root_t;<br /> type user_home_dir_t;<br /> type user_home_t;<br /> type kernel_t;<br /> type nfsd_t;<br /> <br /> class file { create open getattr setattr read write append rename link unlink ioctl lock };<br /> class dir { create open getattr setattr read write link unlink rename search add_name remove_name reparent rmdir<br /> lock ioctl };<br /> class udp_socket { name_bind listen };<br /> class lnk_file {create getattr unlink};<br /> }<br /> <br /> ## specifc to type of exported dirs<br /> nfs_ro_export_dir_type(mnt_t);<br /> nfs_ro_export_dir_type(home_root_t);<br /> nfs_rw_export_type(user_home_t);<br /> &lt;/pre&gt;<br /> <br /> The policy shown above provides the NFS server read-only access to three file types (using the nfs_ro_export_dir_type macro):<br /> * mnt_t - /mnt, /mnt/export<br /> * home_root_t - /mnt/export/home<br /> <br /> The policy provides read-write access to one file type (using the nfs_rw_export_type macro):<br /> * user_home_t - /mnt/export/home/newuser<br /> <br /> The two macros should make it fairly easy to allow the NFS server to access additional file types. To allow the NFS server to access additional types, simply add the type in the requires block and apply the appropriate macro. There currently is no macro to provide read-only access to a file type, but it should be fairly trivial to create one modeled after the read-write macro.<br /> <br /> = Modifying the policy = <br /> For the example of policy modification we will be adding read-write access to the type httpd_user_content_t.<br /> <br /> Here are the steps required to modify the policy:<br /> &lt;ol&gt;<br /> &lt;li&gt;Install the server policy source RPM<br /> &lt;pre&gt;rpm -i sefos-server-policy-0.2-1.fc9.src.rpm&lt;/pre&gt;<br /> <br /> &lt;li&gt;Change directory to &lt;code&gt;/usr/src/redhat/SOURCES&lt;/code&gt;<br /> &lt;li&gt;Extract the policy archive:<br /> &lt;pre&gt;tar -xzf sefos-server-policy-0.2.tar.gz&lt;/pre&gt;<br /> &lt;li&gt;Edit the sefeosexports.te file:<br /> &lt;ol&gt;<br /> &lt;li&gt;Increment the module version number.<br /> &lt;li&gt;In the requires section add the following to allow us to later reference the httpd_user_content_t type:<br /> &lt;pre&gt;type httpd_user_content_t;&lt;/pre&gt;<br /> &lt;li&gt;At the end of the file add a line to allow read-write access to the httpd_user_content_t type:<br /> &lt;/ol&gt;<br /> &lt;pre&gt;nfs_rw_export_type(httpd_user_content_t);&lt;/pre&gt;<br /> &lt;li&gt;In /usr/src/redhat/SOURCES recreate the tarball: <br /> &lt;pre&gt;<br /> tar -czvf sefos-server-policy-0.2.tar.gz sefos-server-policy-0.2<br /> &lt;/pre&gt;<br /> &lt;/ol&gt;<br /> <br /> = Building the policy =<br /> We recommend incrementing the release number to allow the package to be upgraded, instead of forcing the administrator to remove the old version and install the new version. To do so edit &lt;code&gt;/usr/src/redhat/SPECS/sefos-server-policy.spec. Increment the number in the line that looks similar to the following:<br /> &lt;pre&gt;<br /> Release: 1%{?dist}<br /> &lt;/pre&gt;<br /> <br /> <br /> To build the binary RPM run (use -ba to build binary and source packages or -bs for building just the source package):<br /> &lt;pre&gt;<br /> rpmbuild -bb /usr/src/redhat/SPECS/sefos-server-policy.spec<br /> &lt;/pre&gt;<br /> <br /> = Installing the policy = <br /> Use &lt;code&gt;rpm&lt;/code&gt; to upgrade the policy on the server:<br /> &lt;pre&gt;<br /> rpm --upgrade /usr/src/redhat/RPMS/i386/sefos-server-policy-0.2-2.fc9.i386.rpm<br /> &lt;/pre&gt;<br /> <br /> You should now be able to access the new file type through NFS.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/CustomizingServerPolicy Labeled NFS/Demo/CustomizingServerPolicy 2008-12-19T19:57:03Z <p>CraigGrube: /* Modifying the policy */</p> <hr /> <div>= Introduction = <br /> <br /> The server policy contains three SELinux policy modules that are required for NFS to function properly. This section will not cover the specifics of the sefosnfsserver and sefosrpc policies, but will focus on the sefosexports policy. The sefosnfsserver and sefosrpc policies are required for the NFS server and related RPC services to function properly. The sefosexports policy is required to allow the NFS server to access and manage files being shared to the clients.<br /> <br /> = Sample Policy = <br /> &lt;pre&gt;<br /> module sefosexports 1.0.0;<br /> <br /> require {<br /> ## specific to access files/dirs in exports<br /> type mnt_t;<br /> type home_root_t;<br /> type user_home_dir_t;<br /> type user_home_t;<br /> type kernel_t;<br /> type nfsd_t;<br /> <br /> class file { create open getattr setattr read write append rename link unlink ioctl lock };<br /> class dir { create open getattr setattr read write link unlink rename search add_name remove_name reparent rmdir<br /> lock ioctl };<br /> class udp_socket { name_bind listen };<br /> class lnk_file {create getattr unlink};<br /> }<br /> <br /> ## specifc to type of exported dirs<br /> nfs_ro_export_dir_type(mnt_t);<br /> nfs_ro_export_dir_type(home_root_t);<br /> nfs_rw_export_type(user_home_t);<br /> &lt;/pre&gt;<br /> <br /> The policy shown above provides the NFS server read-only access to three file types (using the nfs_ro_export_dir_type macro):<br /> * mnt_t - /mnt, /mnt/export<br /> * home_root_t - /mnt/export/home<br /> <br /> The policy provides read-write access to one file type (using the nfs_rw_export_type macro):<br /> * user_home_t - /mnt/export/home/newuser<br /> <br /> The two macros should make it fairly easy to allow the NFS server to access additional file types. To allow the NFS server to access additional types, simply add the type in the requires block and apply the appropriate macro. There currently is no macro to provide read-only access to a file type, but it should be fairly trivial to create one modeled after the read-write macro.<br /> <br /> = Modifying the policy = <br /> For the example of policy modification we will be adding read-write access to the type httpd_user_content_t.<br /> <br /> Here are the steps required to modify the policy:<br /> &lt;ol&gt;<br /> &lt;li&gt;Install the server policy source RPM<br /> &lt;pre&gt;rpm -i sefos-server-policy-0.2-1.fc9.src.rpm&lt;/pre&gt;<br /> <br /> &lt;li&gt;Change directory to &lt;code&gt;/usr/src/redhat/SOURCES&lt;/code&gt;<br /> &lt;li&gt;Extract the policy archive:<br /> &lt;pre&gt;tar -xzf sefos-server-policy-0.2.tar.gz&lt;/pre&gt;<br /> &lt;li&gt;Edit the sefeosexports.te file:<br /> &lt;ol&gt;<br /> &lt;li&gt;Increment the module version number.<br /> &lt;li&gt;In the requires section add the following to allow us to later reference the httpd_user_content_t type:<br /> &lt;pre&gt;type httpd_user_content_t;&lt;/pre&gt;<br /> &lt;li&gt;At the end of the file add a line to allow read-write access to the httpd_user_content_t type:<br /> &lt;/ol&gt;<br /> &lt;pre&gt;nfs_rw_export_type(httpd_user_content_t);&lt;/pre&gt;<br /> &lt;li&gt;In /usr/src/redhat/SOURCES recreate the tarball: <br /> &lt;pre&gt;<br /> tar -czvf sefos-server-policy-0.2.tar.gz sefos-server-policy-0.2<br /> &lt;/pre&gt;<br /> &lt;/ol&gt;<br /> <br /> = Building the policy =<br /> We recommend incrementing the release number to allow the package to be upgraded, instead of forcing the administrator to remove the old version and install the new version. To do so edit &lt;code&gt;/usr/src/redhat/SPECS/sefos-server-policy.spec. Increment the number in the line that looks similar to the following:<br /> &lt;pre&gt;<br /> Release: 1%{?dist}<br /> &lt;/pre&gt;<br /> <br /> <br /> To build the binary RPM run (use -ba to build binary and source packages or -bs for building just the source package):<br /> &lt;pre&gt;<br /> rpmbuild -bb /usr/src/redhat/SPECS/sefos-server-policy.spec<br /> &lt;/pre&gt;<br /> <br /> = Installing the policy = <br /> Use &lt;code&gt;rpm&lt;/code&gt; to upgrade the policy on the server:<br /> &lt;pre&gt;<br /> rpm --upgrade /usr/src/redhat/RPMS/i386/sefos-server-policy-0.2-2.fc9.i386.rpm<br /> &lt;/pre&gt;<br /> <br /> You should now be able to access the new file type through NFS.<br /> &lt;/pre&gt;</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/CustomizingServerPolicy Labeled NFS/Demo/CustomizingServerPolicy 2008-12-19T19:48:36Z <p>CraigGrube: New page: = Introduction = The server policy contains three SELinux policy modules that are required for NFS to function properly. This section will not cover the specifics of the sefosnfsserver ...</p> <hr /> <div>= Introduction = <br /> <br /> The server policy contains three SELinux policy modules that are required for NFS to function properly. This section will not cover the specifics of the sefosnfsserver and sefosrpc policies, but will focus on the sefosexports policy. The sefosnfsserver and sefosrpc policies are required for the NFS server and related RPC services to function properly. The sefosexports policy is required to allow the NFS server to access and manage files being shared to the clients.<br /> <br /> = Sample Policy = <br /> &lt;pre&gt;<br /> module sefosexports 1.0.0;<br /> <br /> require {<br /> ## specific to access files/dirs in exports<br /> type mnt_t;<br /> type home_root_t;<br /> type user_home_dir_t;<br /> type user_home_t;<br /> type kernel_t;<br /> type nfsd_t;<br /> <br /> class file { create open getattr setattr read write append rename link unlink ioctl lock };<br /> class dir { create open getattr setattr read write link unlink rename search add_name remove_name reparent rmdir<br /> lock ioctl };<br /> class udp_socket { name_bind listen };<br /> class lnk_file {create getattr unlink};<br /> }<br /> <br /> ## specifc to type of exported dirs<br /> nfs_ro_export_dir_type(mnt_t);<br /> nfs_ro_export_dir_type(home_root_t);<br /> nfs_rw_export_type(user_home_t);<br /> &lt;/pre&gt;<br /> <br /> The policy shown above provides the NFS server read-only access to three file types (using the nfs_ro_export_dir_type macro):<br /> * mnt_t - /mnt, /mnt/export<br /> * home_root_t - /mnt/export/home<br /> <br /> The policy provides read-write access to one file type (using the nfs_rw_export_type macro):<br /> * user_home_t - /mnt/export/home/newuser<br /> <br /> The two macros should make it fairly easy to allow the NFS server to access additional file types. To allow the NFS server to access additional types, simply add the type in the requires block and apply the appropriate macro. There currently is no macro to provide read-only access to a file type, but it should be fairly trivial to create one modeled after the read-write macro.<br /> <br /> = Modifying the policy = <br /> For the example of policy modification we will be adding read-write access to the type httpd_user_content_t.<br /> <br /> Here are the steps required to modify the policy:<br /> * Install the server policy source RPM<br /> &lt;pre&gt;rpm -i sefos-server-policy-0.2-1.fc9.src.rpm&lt;/pre&gt;<br /> * Change directory to &lt;code&gt;/usr/src/redhat/SOURCES&lt;/code&gt;<br /> * Extract the policy archive:<br /> &lt;pre&gt;tar -xzf sefos-server-policy-0.2.tar.gz&lt;/pre&gt;<br /> * Edit the sefeosexports.te file:<br /> ** In the requires section add the following to allow us to later reference the httpd_user_content_t type:<br /> &lt;pre&gt;type httpd_user_content_t;&lt;/pre&gt;<br /> ** At the end of the file add a line to allow read-write access to the httpd_user_content_t type:<br /> &lt;pre&gt;nfs_rw_export_type(httpd_user_content_t);&lt;/pre&gt;<br /> * In /usr/src/redhat/SOURCES recreate the tarball: <br /> &lt;pre&gt;<br /> tar -czvf sefos-server-policy-0.2.tar.gz sefos-server-policy-0.2<br /> &lt;/pre&gt;<br /> <br /> = Building the policy =<br /> We recommend incrementing the release number to allow the package to be upgraded, instead of forcing the administrator to remove the old version and install the new version. To do so edit &lt;code&gt;/usr/src/redhat/SPECS/sefos-server-policy.spec. Increment the number in the line that looks similar to the following:<br /> &lt;pre&gt;<br /> Release: 1%{?dist}<br /> &lt;/pre&gt;<br /> <br /> <br /> To build the binary RPM run (use -ba to build binary and source packages or -bs for building just the source package):<br /> &lt;pre&gt;<br /> rpmbuild -bb /usr/src/redhat/SPECS/sefos-server-policy.spec<br /> &lt;/pre&gt;<br /> <br /> = Installing the policy = <br /> Use &lt;code&gt;rpm&lt;/code&gt; to upgrade the policy on the server:<br /> &lt;pre&gt;<br /> rpm --upgrade /usr/src/redhat/RPMS/i386/sefos-server-policy-0.2-2.fc9.i386.rpm<br /> &lt;/pre&gt;<br /> <br /> You should now be able to access the new file type through NFS.<br /> &lt;/pre&gt;</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-19T19:00:44Z <p>CraigGrube: /* Instructions */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service enables files to be accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users access files from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a simple network accessible directory service. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/CustomizingServerPolicy|Customizing the Server SELinux Policy]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc3-5.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-19T19:00:19Z <p>CraigGrube: /* Instructions */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service enables files to be accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users access files from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a simple network accessible directory service. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/CustomizingServerPolicy|Customizing the Server Policy]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc3-5.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Kickstart Labeled NFS/Demo/Kickstart 2008-12-19T16:58:53Z <p>CraigGrube: /* Boot Server Configuration (Optional) */</p> <hr /> <div>This page details the steps required to setup the SEFOS NFSv4 client and<br /> server, including some optional steps to provide basic network services<br /> and a build server. <br /> <br /> The services provided<br /> by the build server can be mixed and matched as needed to supplement existing<br /> network services to provide the <br /> basic functionality required to successfully build a client or server from <br /> a kickstart.<br /> <br /> The binary RPM packages required for the Labeled NFS to work properly were compiled<br /> for Fedora Core 9 systems. Source RPMs are available for compiling your own packages.<br /> <br /> = Boot Server Configuration (Optional) =<br /> The sample configurations assume a local network using the 192.168.201.0/24 <br /> address block. Network ranges/addresses should be modified to match<br /> those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration <br /> examples and in the demo environment. The domain may be modified to match<br /> an existing domain. Changes to the kickstarts will be required to set the<br /> new default domain and to change the creation of the ldap structure if the<br /> domain name is increased beyond two levels.<br /> <br /> The location of the configuration files identified for the boot server configuration<br /> are assuming Fedora Core 9 is the host operating system. Different release versions<br /> or distributions may place the configuration files in different locations.<br /> <br /> As the DNS, DHCP, and HTTP servers need to be accessible to remote systems, <br /> the boot server firewall may need to be configured to allow incoming <br /> connections from the local network to these ports:<br /> * 80/tcp<br /> * 67/udp<br /> * 53/udp <br /> <br /> == Installing packages ==<br /> <br /> The YUM package tool is used to install packages. This requires a<br /> connection to the Internet to connect to remote package repositories, or<br /> a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated<br /> packages.<br /> <br /> == Setting up the DHCP server ==<br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The<br /> example provided is one that is being used in a VMware environment.<br /> <br /> [excerpt from sample /etc/dhcpd.conf]<br /> &lt;pre&gt;<br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host seserver {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;seserver.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it<br /> might be useful to generate that portion of the DHCPD config file from a<br /> flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the DNS Server ==<br /> packages: named<br /> <br /> The default configuration will only listen on the localhost address. You will <br /> need to set the listen-on and allow-query addresses in the options section<br /> of /etc/named.conf so that named can respond to queries on the local network.<br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> Add forward and reverse zones for the address range in use:<br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> seserver A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client2 A 192.168.201.51<br /> client3 A 192.168.201.52<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR seserver.example.com.<br /> <br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> 52 IN PTR client3.example.com.<br /> &lt;/pre&gt;<br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the Web server ==<br /> packages: httpd<br /> <br /> Download the latest versions of the kickstart files and binary RPMs as identified on the main[[Labeled_NFS/Demo|Labeled NFS Demo]] page.<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Client Kickstart<br /> &lt;li&gt;Server Kickstart<br /> &lt;li&gt;Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;NFS Utils with Labeled NFS patches<br /> &lt;li&gt;SELinux policy for labeled NFS server<br /> &lt;li&gt;SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Create a directory to hold the kickstart files [/var/www/html/kickstart/]. Copy the client and server kickstart files into this directory.<br /> <br /> Create directories to hold the RPMs and eventually the server CA public certificate [/var/www/html/conf for packages, and /var/www/html/certs for the certificate]. Copy the Kernel, NFS Utils and SEFOS SELinux policies into /var/www/html/conf.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> Source and binary RPM packages are available at http://www.selinuxnow.org/sefos/packages/<br /> <br /> = Kickstart Customization and System Installation =<br /> <br /> Documentation at the beginning of the kickstart files details some boot time<br /> options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> &lt;ul&gt;<br /> &lt;li&gt;Depending on the network environment the kickstart can be configured to use<br /> DHCP for address provisioning or static addressing. The default is to use<br /> DHCP, however a sample static address configuration is included for reference.<br /> If addresses are assigned statically, the kickstarts will need to be modified<br /> for each client/server installation (to provide the appropriate address).<br /> &lt;li&gt; If installing FC9 from CD/DVD access to an up-to-date FC9 repository (via<br /> external network connection or local mirror) is required as some packages required<br /> for the installs are not included in the CD/DVD install media.<br /> &lt;li&gt;Additional customization of the ldap/kerberos/nfs installation can be <br /> performed in the %post section. <br /> &lt;li&gt;Installs are currently interactive. To convert the kickstarts to a fully automated<br /> install comment out the &quot;interactive&quot; directive at the beginning of the files.<br /> &lt;li&gt;Kerberos requires that client and server system times be synchronized to function<br /> properly. The install does not customize the default FC9 NTP configuration, though it <br /> does attempt to synchronize the system time following reboot against a fedora time server <br /> (0.fedora.pool.ntp.org).<br /> &lt;/ul&gt;<br /> <br /> == Server Kickstart == <br /> <br /> === Introduction ===<br /> The kickstart installs and configures the<br /> server portion of the Labeled NFS Demo environment.<br /> It includes many components that would be used in an<br /> enterprise to provide authentication and authorization<br /> services as well as directory and file sharing services.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are identified on the main demo page.<br /> * Linux kernel with Labeled NFS patches<br /> * NFS-Utils with Labeled NFS patches<br /> * SEFOS Server SELinux policy<br /> <br /> ==== DNS ====<br /> <br /> For Kerberos to function properly, forward and reverse resolution is required for all clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients and for<br /> providing the three custom packages for client <br /> installation.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time for customizing the installation:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - Server's fully qualified domain name.<br /> &lt;li&gt;se_krbpass - Kerberos password for root/admin principal.<br /> &lt;li&gt;se_kdbpass - Kerberos database password.<br /> &lt;li&gt;se_ldappass - LDAP administrator password<br /> &lt;li&gt;se_www - DNS name of web server hosting packages/config (default is www.example.com)<br /> &lt;/ul&gt;<br /> If customizing the LDAP certificate the following options can be used to override the defaults:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_certPW - Certificate Authority certificate password<br /> &lt;li&gt;se_certCountry <br /> &lt;li&gt;se_certState<br /> &lt;li&gt;se_certCity<br /> &lt;li&gt;se_certOrg<br /> &lt;li&gt;se_certEmail<br /> &lt;li&gt;se_certCN<br /> &lt;/ul&gt;<br /> <br /> === Assumptions ===<br /> ==== Kerberos Realm ====<br /> The server DNS name is used to generate the <br /> kerberos realm name and the ldap structure. The domain<br /> of the client and server are currently expected to contain<br /> two levels (i.e. DNS: example.com -&gt; LDAP: dc=example,dc=com -&gt; Kerberos: EXAMPLE.COM).<br /> <br /> ==== Packages ==== <br /> Packages are expected to be in a directory called<br /> conf off of the web server root directory (i.e. http://www.example.com/conf) <br /> <br /> ==== Time Zone ==== <br /> The current default time zone is Pacific. Change as desired.<br /> <br /> === Post Install === <br /> <br /> The client kickstart requires the LDAP<br /> CA certificate during installation time to for proper <br /> configuration. <br /> <br /> &lt;b&gt;The certificate (/etc/openldap/cacerts/cacert.pem)<br /> should be copied into conf/certs/cacert.pem on the web<br /> server.&lt;/b&gt;<br /> <br /> == Client Kickstart ==<br /> <br /> === Introduction ===<br /> This kickstart installs and configures the<br /> client portion of the Labeled NFS Demo.<br /> After a successfully client build, the client will be <br /> a fairly minimimal Fedora installation configured with<br /> GDM and GNOME. The client will be<br /> integrated with the authentication/authorization/directory<br /> services provided by the server component, and user <br /> home directories will be mounted via NFS.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> <br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are identified on the main Labeled NFS Demo page:<br /> * Linux kernel with Labeled NFS patches<br /> * NFS-Utils with Labeled NFS patches<br /> * SEFOS Client SELinux policy<br /> <br /> ==== DNS ====<br /> The kerberos configuration requires an external<br /> DNS service that supports forward and reverse resolution<br /> for the clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients, for<br /> providing the three custom packages, and for providing <br /> the ldap server CA certificate. The RPMS are expected to<br /> be in /conf, and the CA certificate is expected to be in<br /> conf/certs.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time to make client configuration customizations.<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - The fully qualified domain name of the client<br /> &lt;li&gt;se_krbpass - Password for the root/admin kerberos principal.<br /> &lt;li&gt;se_server - FQDN of the server component. Defaults to seserver.$dnsdomain<br /> &lt;/ul&gt;<br /> <br /> = Using the Environment = <br /> <br /> After the installation is complete the following accounts are available:<br /> <br /> * Server<br /> ** root - sefos1<br /> ** Kerberos Database (required to add slave KDCs)<br /> *** kdbpass<br /> ** Kerberos root/admin principal<br /> *** say#fos#<br /> * Client<br /> ** root - sefos1<br /> ** newuser - newuser1<br /> <br /> Passwords should be changed from the defaults after completing installation, especially if the clients or servers are reachable from the Internet.<br /> <br /> Using the '''newuser''' account you should now be able to login on the client using GDM or on a virtual console.<br /> <br /> = Troubleshooting (in progress)=<br /> <br /> Additional information that may be useful for troubleshooting is available in the manual installation guide with the appropriate service.<br /> <br /> * If the newuser account does not work on the client:<br /> ** Switch to a virtual console (ctrl-alt-f1) and login as root<br /> ** Verify that Kerberos was successfully configured:<br /> *** Use &lt;code&gt;klist -k /etc/krb5.keytab&lt;/code&gt;.<br /> *** If the keytab does not exist there was an error that prevented kadmin from creating the host and nfs principals during installation. Otherwise the output should show four keys for the host (i.e. host/client.example.com) and one for nfs (i.e. nfs/client.example.com). This is likely either a password mismatch issue or a time synchronization issue. <br /> *** Verify the client and server times are similar using '''date'''. <br /> **** If not, use &lt;code&gt; run_init service ntpd stop&lt;/code&gt; to turn of ntpd, then use &lt;code&gt;ntpdate -b -x 0.fedora.pool.ntp.org&lt;/code&gt; to sync time with the external time server. Use &lt;code&gt;run_init service ntpd start&lt;/code&gt; to start ntpd.<br /> **** If the external time server is unreachable, or an internal time source is preferred, reconfigure ntpd to use the desired time source and use that host instead of 0.fedora.pool.ntp.org in the ntpdate command.<br /> **** Manually synchronize both the client and server to ensure they are correct. <br /> *** Once syncronized time has been verified or established, follow the steps in the [[Labeled_NFS/Demo/Manual/Kerberos| Kerberos configuration guide]] to create the host and nfs principals, and store them locally in a keytab.<br /> ** Verify that LDAP was successfully configured:<br /> *** Examine /var/log/messages for LDAP related errors<br /> *** During testing we encountered errors where the client was unable to connect to the LDAP server. The errors were related to forgetting to copy the CA certificate into the appropriate area of the web server, forgetting to update the certificate if we built a new server, or having Apache serve an older certificate that was cached.<br /> *** Use scp to copy the CA certificate from the server to the client: &lt;code&gt; scp seserver:/etc/openldap/cacerts/cacert.pem /etc/openldap/cacerts/&lt;/code&gt;<br /> ** Verify that three SELinux booleans were correctly set on the client.<br /> *** Run &lt;code&gt;getsebool allow_kerberos allow_gssd_read_tmp use_nfs_home_dirs&lt;/code&gt; and verify the values are all set as '''on'''<br /> ** Verify that NFSv4 mounts work properly.<br /> *** Run &lt;code&gt;kinit -p root/admin&lt;/code&gt; to initialize your Kerberos credentials.<br /> *** Run &lt;code&gt;mount -v -t nfs4 -o sec=krb5,security_label seserver:/home /mnt&lt;/code&gt; to mount /mnt/home from the server.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Kickstart Labeled NFS/Demo/Kickstart 2008-12-19T16:58:20Z <p>CraigGrube: /* Boot Server Configuration (Optional) */</p> <hr /> <div>This page details the steps required to setup the SEFOS NFSv4 client and<br /> server, including some optional steps to provide basic network services<br /> and a build server. <br /> <br /> The services provided<br /> by the build server can be mixed and matched as needed to supplement existing<br /> network services to provide the <br /> basic functionality required to successfully build a client or server from <br /> a kickstart.<br /> <br /> The binary RPM packages required for the Labeled NFS to work properly were compiled<br /> for Fedora Core 9 systems. Source RPMs are available for compiling your own packages.<br /> <br /> = Boot Server Configuration (Optional) =<br /> The sample configurations assume a local network using the 192.168.201.0/24 <br /> address block. Network ranges/addresses should be modified to match<br /> those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration <br /> examples and in the demo environment. The domain may be modified to match<br /> an existing domain. Changes to the kickstarts will be required to set the<br /> new default domain and to change the creation of the ldap structure if the<br /> domain name is increased beyond two levels.<br /> <br /> The location of the configuration files identified for the boot server configuration<br /> are assuming Fedora Core 9 is the host operating system. Different release versions<br /> or distributions may place the configuration files in different locations.<br /> <br /> As the DNS, DHCP, and HTTP servers need to be accessible to remote systems, <br /> the boot server firewall may need to be configuration to allow incoming <br /> connections from the local network to these ports:<br /> * 80/tcp<br /> * 67/udp<br /> * 53/udp <br /> <br /> == Installing packages ==<br /> <br /> The YUM package tool is used to install packages. This requires a<br /> connection to the Internet to connect to remote package repositories, or<br /> a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated<br /> packages.<br /> <br /> == Setting up the DHCP server ==<br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The<br /> example provided is one that is being used in a VMware environment.<br /> <br /> [excerpt from sample /etc/dhcpd.conf]<br /> &lt;pre&gt;<br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host seserver {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;seserver.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it<br /> might be useful to generate that portion of the DHCPD config file from a<br /> flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the DNS Server ==<br /> packages: named<br /> <br /> The default configuration will only listen on the localhost address. You will <br /> need to set the listen-on and allow-query addresses in the options section<br /> of /etc/named.conf so that named can respond to queries on the local network.<br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> Add forward and reverse zones for the address range in use:<br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> seserver A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client2 A 192.168.201.51<br /> client3 A 192.168.201.52<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR seserver.example.com.<br /> <br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> 52 IN PTR client3.example.com.<br /> &lt;/pre&gt;<br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the Web server ==<br /> packages: httpd<br /> <br /> Download the latest versions of the kickstart files and binary RPMs as identified on the main[[Labeled_NFS/Demo|Labeled NFS Demo]] page.<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Client Kickstart<br /> &lt;li&gt;Server Kickstart<br /> &lt;li&gt;Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;NFS Utils with Labeled NFS patches<br /> &lt;li&gt;SELinux policy for labeled NFS server<br /> &lt;li&gt;SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Create a directory to hold the kickstart files [/var/www/html/kickstart/]. Copy the client and server kickstart files into this directory.<br /> <br /> Create directories to hold the RPMs and eventually the server CA public certificate [/var/www/html/conf for packages, and /var/www/html/certs for the certificate]. Copy the Kernel, NFS Utils and SEFOS SELinux policies into /var/www/html/conf.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> Source and binary RPM packages are available at http://www.selinuxnow.org/sefos/packages/<br /> <br /> = Kickstart Customization and System Installation =<br /> <br /> Documentation at the beginning of the kickstart files details some boot time<br /> options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> &lt;ul&gt;<br /> &lt;li&gt;Depending on the network environment the kickstart can be configured to use<br /> DHCP for address provisioning or static addressing. The default is to use<br /> DHCP, however a sample static address configuration is included for reference.<br /> If addresses are assigned statically, the kickstarts will need to be modified<br /> for each client/server installation (to provide the appropriate address).<br /> &lt;li&gt; If installing FC9 from CD/DVD access to an up-to-date FC9 repository (via<br /> external network connection or local mirror) is required as some packages required<br /> for the installs are not included in the CD/DVD install media.<br /> &lt;li&gt;Additional customization of the ldap/kerberos/nfs installation can be <br /> performed in the %post section. <br /> &lt;li&gt;Installs are currently interactive. To convert the kickstarts to a fully automated<br /> install comment out the &quot;interactive&quot; directive at the beginning of the files.<br /> &lt;li&gt;Kerberos requires that client and server system times be synchronized to function<br /> properly. The install does not customize the default FC9 NTP configuration, though it <br /> does attempt to synchronize the system time following reboot against a fedora time server <br /> (0.fedora.pool.ntp.org).<br /> &lt;/ul&gt;<br /> <br /> == Server Kickstart == <br /> <br /> === Introduction ===<br /> The kickstart installs and configures the<br /> server portion of the Labeled NFS Demo environment.<br /> It includes many components that would be used in an<br /> enterprise to provide authentication and authorization<br /> services as well as directory and file sharing services.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are identified on the main demo page.<br /> * Linux kernel with Labeled NFS patches<br /> * NFS-Utils with Labeled NFS patches<br /> * SEFOS Server SELinux policy<br /> <br /> ==== DNS ====<br /> <br /> For Kerberos to function properly, forward and reverse resolution is required for all clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients and for<br /> providing the three custom packages for client <br /> installation.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time for customizing the installation:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - Server's fully qualified domain name.<br /> &lt;li&gt;se_krbpass - Kerberos password for root/admin principal.<br /> &lt;li&gt;se_kdbpass - Kerberos database password.<br /> &lt;li&gt;se_ldappass - LDAP administrator password<br /> &lt;li&gt;se_www - DNS name of web server hosting packages/config (default is www.example.com)<br /> &lt;/ul&gt;<br /> If customizing the LDAP certificate the following options can be used to override the defaults:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_certPW - Certificate Authority certificate password<br /> &lt;li&gt;se_certCountry <br /> &lt;li&gt;se_certState<br /> &lt;li&gt;se_certCity<br /> &lt;li&gt;se_certOrg<br /> &lt;li&gt;se_certEmail<br /> &lt;li&gt;se_certCN<br /> &lt;/ul&gt;<br /> <br /> === Assumptions ===<br /> ==== Kerberos Realm ====<br /> The server DNS name is used to generate the <br /> kerberos realm name and the ldap structure. The domain<br /> of the client and server are currently expected to contain<br /> two levels (i.e. DNS: example.com -&gt; LDAP: dc=example,dc=com -&gt; Kerberos: EXAMPLE.COM).<br /> <br /> ==== Packages ==== <br /> Packages are expected to be in a directory called<br /> conf off of the web server root directory (i.e. http://www.example.com/conf) <br /> <br /> ==== Time Zone ==== <br /> The current default time zone is Pacific. Change as desired.<br /> <br /> === Post Install === <br /> <br /> The client kickstart requires the LDAP<br /> CA certificate during installation time to for proper <br /> configuration. <br /> <br /> &lt;b&gt;The certificate (/etc/openldap/cacerts/cacert.pem)<br /> should be copied into conf/certs/cacert.pem on the web<br /> server.&lt;/b&gt;<br /> <br /> == Client Kickstart ==<br /> <br /> === Introduction ===<br /> This kickstart installs and configures the<br /> client portion of the Labeled NFS Demo.<br /> After a successfully client build, the client will be <br /> a fairly minimimal Fedora installation configured with<br /> GDM and GNOME. The client will be<br /> integrated with the authentication/authorization/directory<br /> services provided by the server component, and user <br /> home directories will be mounted via NFS.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> <br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are identified on the main Labeled NFS Demo page:<br /> * Linux kernel with Labeled NFS patches<br /> * NFS-Utils with Labeled NFS patches<br /> * SEFOS Client SELinux policy<br /> <br /> ==== DNS ====<br /> The kerberos configuration requires an external<br /> DNS service that supports forward and reverse resolution<br /> for the clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients, for<br /> providing the three custom packages, and for providing <br /> the ldap server CA certificate. The RPMS are expected to<br /> be in /conf, and the CA certificate is expected to be in<br /> conf/certs.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time to make client configuration customizations.<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - The fully qualified domain name of the client<br /> &lt;li&gt;se_krbpass - Password for the root/admin kerberos principal.<br /> &lt;li&gt;se_server - FQDN of the server component. Defaults to seserver.$dnsdomain<br /> &lt;/ul&gt;<br /> <br /> = Using the Environment = <br /> <br /> After the installation is complete the following accounts are available:<br /> <br /> * Server<br /> ** root - sefos1<br /> ** Kerberos Database (required to add slave KDCs)<br /> *** kdbpass<br /> ** Kerberos root/admin principal<br /> *** say#fos#<br /> * Client<br /> ** root - sefos1<br /> ** newuser - newuser1<br /> <br /> Passwords should be changed from the defaults after completing installation, especially if the clients or servers are reachable from the Internet.<br /> <br /> Using the '''newuser''' account you should now be able to login on the client using GDM or on a virtual console.<br /> <br /> = Troubleshooting (in progress)=<br /> <br /> Additional information that may be useful for troubleshooting is available in the manual installation guide with the appropriate service.<br /> <br /> * If the newuser account does not work on the client:<br /> ** Switch to a virtual console (ctrl-alt-f1) and login as root<br /> ** Verify that Kerberos was successfully configured:<br /> *** Use &lt;code&gt;klist -k /etc/krb5.keytab&lt;/code&gt;.<br /> *** If the keytab does not exist there was an error that prevented kadmin from creating the host and nfs principals during installation. Otherwise the output should show four keys for the host (i.e. host/client.example.com) and one for nfs (i.e. nfs/client.example.com). This is likely either a password mismatch issue or a time synchronization issue. <br /> *** Verify the client and server times are similar using '''date'''. <br /> **** If not, use &lt;code&gt; run_init service ntpd stop&lt;/code&gt; to turn of ntpd, then use &lt;code&gt;ntpdate -b -x 0.fedora.pool.ntp.org&lt;/code&gt; to sync time with the external time server. Use &lt;code&gt;run_init service ntpd start&lt;/code&gt; to start ntpd.<br /> **** If the external time server is unreachable, or an internal time source is preferred, reconfigure ntpd to use the desired time source and use that host instead of 0.fedora.pool.ntp.org in the ntpdate command.<br /> **** Manually synchronize both the client and server to ensure they are correct. <br /> *** Once syncronized time has been verified or established, follow the steps in the [[Labeled_NFS/Demo/Manual/Kerberos| Kerberos configuration guide]] to create the host and nfs principals, and store them locally in a keytab.<br /> ** Verify that LDAP was successfully configured:<br /> *** Examine /var/log/messages for LDAP related errors<br /> *** During testing we encountered errors where the client was unable to connect to the LDAP server. The errors were related to forgetting to copy the CA certificate into the appropriate area of the web server, forgetting to update the certificate if we built a new server, or having Apache serve an older certificate that was cached.<br /> *** Use scp to copy the CA certificate from the server to the client: &lt;code&gt; scp seserver:/etc/openldap/cacerts/cacert.pem /etc/openldap/cacerts/&lt;/code&gt;<br /> ** Verify that three SELinux booleans were correctly set on the client.<br /> *** Run &lt;code&gt;getsebool allow_kerberos allow_gssd_read_tmp use_nfs_home_dirs&lt;/code&gt; and verify the values are all set as '''on'''<br /> ** Verify that NFSv4 mounts work properly.<br /> *** Run &lt;code&gt;kinit -p root/admin&lt;/code&gt; to initialize your Kerberos credentials.<br /> *** Run &lt;code&gt;mount -v -t nfs4 -o sec=krb5,security_label seserver:/home /mnt&lt;/code&gt; to mount /mnt/home from the server.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-16T17:37:34Z <p>CraigGrube: /* LDAP, Lightweight Directory Access Protocol */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service enables files to be accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users access files from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a simple network accessible directory service. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc3-5.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-16T17:25:38Z <p>CraigGrube: /* NFS, Network File System */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service enables files to be accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users access files from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a directory service. It is a simple database that is<br /> network accessible. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc3-5.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-16T17:24:27Z <p>CraigGrube: /* NFS, Network File System */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service enables files to be accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users can login from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a directory service. It is a simple database that is<br /> network accessible. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc3-5.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Manual/NFSv4 Labeled NFS/Demo/Manual/NFSv4 2008-12-15T15:53:41Z <p>CraigGrube: /* SELinux Policy tweaks */</p> <hr /> <div>= NFSv4 Server =<br /> == NFS Server Packages ==<br /> <br /> The NFS server installation requires three custom packages, two of which replace/upgrade<br /> existing packages to include support for Labeled NFS. The third package includes SELinux <br /> policy necessary for the NFS server to access and manage exported files and directories. The latest versions<br /> of the packages are identified on the main Labeled NFS demo page.<br /> <br /> * Linux Kernel with Labeled NFS patches<br /> * NFS Utils with Labeled NFS patches<br /> * SEFOS Server SELinux policy <br /> <br /> The NFS server is also a Kerberos client, so the packages identified in the Kerberos client configuration section are required.<br /> <br /> Other useful packages:<br /> * system-config-nfs<br /> * nfswatch<br /> <br /> == Create Kerberos Principals ==<br /> <br /> Run kadmin on the '''Kerberos Server''' and create the nfs principal<br /> for the server. Then, add the nfs principal's key to the local<br /> keytab file.<br /> * Replace nfsserver.example.com with the fully qualified name of the NFSv4 server machine.<br /> * The same machine may host the NFSv4 server and the Kerberos server. In that case, both the principle creation and the adding of the principle to the local key table are still required.<br /> * '''Note''' the special way in which the NFS principal is added. The encryption key type is specified.<br /> ** If this is not done, NFS will fail in mysterious ways and it will be difficult to track down the problem.<br /> ** This is apparently because the NFS kernel code only supports des-cbc-crc.<br /> <br /> &lt;pre&gt;<br /> # kadmin<br /> Authenticating as principal root/admin@server.example.com with password.<br /> Password for root/admin@server.example.com<br /> kadmin: addprinc -randkey nfs/nfsserver.example.com<br /> kadmin: ktadd -e des-cbc-crc:normal nfs/nfsserver.example.com<br /> kadmin: quit<br /> &lt;/pre&gt;<br /> <br /> == Server Configuration ==<br /> Create the necessary entries in /etc/exports. <br /> * create an NFSv4 mount point. <br /> ** e.g. /mnt/export. <br /> * Next bind the real path to the NFSv4 mount point. <br /> ** e.g. /mnt/export/home<br /> ** fstab entry binding the real path to the mount point should be added to to /etc/fstab so that it is remounted after each boot.<br /> <br /> &lt;pre&gt;<br /> mkdir -m 1777 /mnt/export<br /> mkdir /mnt/export/home<br /> echo &quot;/home /mnt/export/home none bind 0 0&quot; &gt;&gt; /etc/fstab<br /> mount -a<br /> &lt;/pre&gt;<br /> <br /> <br /> === /etc/exports ===<br /> The exported directories need to be added to /etc/exports:<br /> <br /> &lt;pre&gt;<br /> /mnt/export 192.168.201.0/24(sec=krb5:krb5i:krb5p,security_label,sync,rw,fsid=0,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash) <br /> <br /> /mnt/export/home 192.168.201.0/24(sec=krb5:krb5i:krb5p,security_label,sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash)<br /> &lt;/pre&gt;<br /> <br /> and if legacy NFSv3 mounts are desired add:<br /> <br /> &lt;pre&gt;<br /> # Legacy mounts<br /> /home 192.168.201.0/24(sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash)<br /> &lt;/pre&gt;<br /> <br /> '''Note''' On 64 bit machines, the anonuid and anongid above should be set to '4294967294'.<br /> <br /> === Modify /etc/idmapd.conf ===<br /> <br /> You must change the domain to your current domain. Also, The user<br /> mapping for nobody should be checked and updated to nfsnobody if<br /> necessary.<br /> * In general, the '''Domain''' value here should match Kerberos's krb5.conf file '''default_domain''' value.<br /> <br /> &lt;pre&gt;<br /> [General]<br /> Verbosity = 0<br /> Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br /> Domain = example.com<br /> <br /> [Mapping]<br /> <br /> Nobody-User = nfsnobody<br /> Nobody-Group = nfsnobody<br /> <br /> [Translation]<br /> Method = nsswitch<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/sysconfig/nfs ===<br /> <br /> To enable secure NFS, the following line must be added to /etc/sysconfig/nfs:<br /> <br /> &lt;pre&gt;<br /> SECURE_NFS=yes<br /> &lt;/pre&gt;<br /> <br /> The following are default ports. They may be reconfigured depending on local firewall setups.<br /> <br /> &lt;pre&gt;<br /> # Port rquotad should listen on.<br /> #RQUOTAD_PORT=875<br /> ...<br /> # TCP port rpc.lockd should listen on.<br /> #LOCKD_TCPPORT=32803<br /> # UDP port rpc.lockd should listen on.<br /> #LOCKD_UDPPORT=32769<br /> ...<br /> # Port rpc.mountd should listen on.<br /> #MOUNTD_PORT=892<br /> ...<br /> # Port rpc.statd should listen on.<br /> #STATD_PORT=662<br /> &lt;/pre&gt;<br /> <br /> For large number of connections, the number of NFS Daemons below may need to be increased:<br /> &lt;pre&gt;<br /> RPCNFSDCOUNT=8<br /> &lt;/pre&gt;<br /> <br /> == Firewalls ==<br /> <br /> If there is a firewall on the server, the following default port<br /> should be allowed through to enable NFSv4.<br /> <br /> NFSv4 Ports:<br /> * 2049 TCP<br /> <br /> To open this port through the firewall, add the following lines to &lt;code&gt;/etc/sysconfig/iptables&lt;/code&gt; right before the INPUT REJECT rule:<br /> # nfs server<br /> -A INPUT -m tcp -p tcp --dport 2049 -j ACCEPT<br /> <br /> Then restart iptables:<br /> run_init service iptables restart<br /> <br /> == NFS Start at Boot ==<br /> <br /> Make NFS start during boot:<br /> <br /> &lt;pre&gt;<br /> # chkconfig nfs on<br /> &lt;/pre&gt;<br /> <br /> '''Note:''' The rpcsvcgssd service needs to start after network services on your host. If it does not start properly at boot time, try moving it to start after network initialization (e.g. NetworkManager) in the initial start order (i.e. within /etc/rc.d/).<br /> <br /> === SELinux Policy tweaks ===<br /> Install the NFS Server SELinux policy binary RPM, or build and install from the available SRPM.<br /> <br /> == Start nfs ==<br /> run_init service nfs start<br /> <br /> = NFSv4 Client =<br /> == NFS Client Packages ==<br /> <br /> The NFS client requires the installation of one package, the SEFOS Client SELinux policy package. The latest version of the package is identified on the main Labeled NFS demo page.<br /> <br /> Other Useful Packages:<br /> * nfswatch<br /> <br /> == Create Kerberos Principals ==<br /> <br /> Run kadmin on the '''client''' and create an nfs principal for the<br /> client. Then, add the principal to the client's local key table.<br /> * Replace seclient.example.com with the fully qualified name of the client machine.<br /> * '''Note''' the special way in which the NFS principal is added. The encryption key type is specified.<br /> ** If this is not done, NFS will fail in mysterious ways and it will be difficult to track down the problem.<br /> ** This is apparently because the NFS kernel code only supports des-cbc-crc.<br /> <br /> &lt;pre&gt;<br /> # kadmin<br /> Authenticating as principal root/admin@server.example.com with password.<br /> Password for root/admin@server.example.com<br /> kadmin: addprinc -randkey nfs/seclient.example.com<br /> kadmin: ktadd -e des-cbc-crc:normal nfs/seclient.example.com<br /> kadmin: quit<br /> &lt;/pre&gt;<br /> <br /> == NFS Client File Configuration ==<br /> === Modify /etc/idmapd.conf ===<br /> <br /> You must change the domain to your current domain. Also, The user<br /> mapping for nobody should be checked and updated to nfsnobody if<br /> necessary.<br /> * In general, the '''Domain''' value here should match Kerberos's krb5.conf file '''default_domain''' value.<br /> <br /> &lt;pre&gt;<br /> [General]<br /> Verbosity = 0<br /> Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br /> Domain = example.com<br /> <br /> [Mapping]<br /> <br /> Nobody-User = nfsnobody<br /> Nobody-Group = nfsnobody<br /> <br /> [Translation]<br /> Method = nsswitch<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/sysconfig/nfs ===<br /> <br /> To enable secure NFS, the following line must be included in /etc/sysconfig/nfs:<br /> <br /> &lt;pre&gt;<br /> SECURE_NFS=yes<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/fstab ===<br /> Create a directory for the mount:<br /> mkdir /mnt/nfs4<br /> <br /> Add the directories to be mounted to fstab:<br /> &lt;pre&gt;<br /> sefos:/ /mnt/nfs4 nfs4 users,sec=krb5 0 0<br /> &lt;/pre&gt;<br /> <br /> == SELinux Policy tweaks ==<br /> <br /> The client package contains a script that performs some post install configuration. The core<br /> action performed by the script is to set these three SELinux booleans:<br /> &lt;ul&gt;<br /> &lt;li&gt;allow_kerberos - required for client-side Kerberos to function properly<br /> &lt;li&gt;allow_gssd_read_tmp - required for RPC GSSD to read cached Kerberos credentials in /tmp (for passing credentials between NFS client and server)<br /> &lt;li&gt;use_nfs_home_dirs - allow home directories (/home) to be mounted via NFS<br /> &lt;/ul&gt;<br /> <br /> The script is automatically run during the first normal system boot so no manual action beyond installing<br /> the package should be required.<br /> <br /> = Testing NFS =<br /> <br /> * Assumes that the Kerberos server is running and the client is configured for Kerberos.<br /> <br /> The following should not produce errors and should show the contents<br /> of /mnt/export on the NFS server:<br /> <br /> &lt;pre&gt;<br /> [root@seclient /]# kinit -p root/admin<br /> Password for root/admin@EXAMPLE.COM:<br /> [root@seclient /]# mount /mnt/nfs4<br /> [root@seclient /]# ls /mnt/nfs4<br /> &lt;/pre&gt;<br /> <br /> = NFS References =<br /> <br /> * Projects: NFS Version 4 Open Source [http://www.citi.umich.edu/projects/nfsv4/linux/ Reference Implementation]<br /> * Network File System (NFS) version 4 Protocol, RFC 3530<br /> * NFS Version 4 Design Considerations, RFC 2624</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Manual/NFSv4 Labeled NFS/Demo/Manual/NFSv4 2008-12-15T15:51:55Z <p>CraigGrube: /* NFS Client Packages */</p> <hr /> <div>= NFSv4 Server =<br /> == NFS Server Packages ==<br /> <br /> The NFS server installation requires three custom packages, two of which replace/upgrade<br /> existing packages to include support for Labeled NFS. The third package includes SELinux <br /> policy necessary for the NFS server to access and manage exported files and directories. The latest versions<br /> of the packages are identified on the main Labeled NFS demo page.<br /> <br /> * Linux Kernel with Labeled NFS patches<br /> * NFS Utils with Labeled NFS patches<br /> * SEFOS Server SELinux policy <br /> <br /> The NFS server is also a Kerberos client, so the packages identified in the Kerberos client configuration section are required.<br /> <br /> Other useful packages:<br /> * system-config-nfs<br /> * nfswatch<br /> <br /> == Create Kerberos Principals ==<br /> <br /> Run kadmin on the '''Kerberos Server''' and create the nfs principal<br /> for the server. Then, add the nfs principal's key to the local<br /> keytab file.<br /> * Replace nfsserver.example.com with the fully qualified name of the NFSv4 server machine.<br /> * The same machine may host the NFSv4 server and the Kerberos server. In that case, both the principle creation and the adding of the principle to the local key table are still required.<br /> * '''Note''' the special way in which the NFS principal is added. The encryption key type is specified.<br /> ** If this is not done, NFS will fail in mysterious ways and it will be difficult to track down the problem.<br /> ** This is apparently because the NFS kernel code only supports des-cbc-crc.<br /> <br /> &lt;pre&gt;<br /> # kadmin<br /> Authenticating as principal root/admin@server.example.com with password.<br /> Password for root/admin@server.example.com<br /> kadmin: addprinc -randkey nfs/nfsserver.example.com<br /> kadmin: ktadd -e des-cbc-crc:normal nfs/nfsserver.example.com<br /> kadmin: quit<br /> &lt;/pre&gt;<br /> <br /> == Server Configuration ==<br /> Create the necessary entries in /etc/exports. <br /> * create an NFSv4 mount point. <br /> ** e.g. /mnt/export. <br /> * Next bind the real path to the NFSv4 mount point. <br /> ** e.g. /mnt/export/home<br /> ** fstab entry binding the real path to the mount point should be added to to /etc/fstab so that it is remounted after each boot.<br /> <br /> &lt;pre&gt;<br /> mkdir -m 1777 /mnt/export<br /> mkdir /mnt/export/home<br /> echo &quot;/home /mnt/export/home none bind 0 0&quot; &gt;&gt; /etc/fstab<br /> mount -a<br /> &lt;/pre&gt;<br /> <br /> <br /> === /etc/exports ===<br /> The exported directories need to be added to /etc/exports:<br /> <br /> &lt;pre&gt;<br /> /mnt/export 192.168.201.0/24(sec=krb5:krb5i:krb5p,security_label,sync,rw,fsid=0,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash) <br /> <br /> /mnt/export/home 192.168.201.0/24(sec=krb5:krb5i:krb5p,security_label,sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash)<br /> &lt;/pre&gt;<br /> <br /> and if legacy NFSv3 mounts are desired add:<br /> <br /> &lt;pre&gt;<br /> # Legacy mounts<br /> /home 192.168.201.0/24(sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash)<br /> &lt;/pre&gt;<br /> <br /> '''Note''' On 64 bit machines, the anonuid and anongid above should be set to '4294967294'.<br /> <br /> === Modify /etc/idmapd.conf ===<br /> <br /> You must change the domain to your current domain. Also, The user<br /> mapping for nobody should be checked and updated to nfsnobody if<br /> necessary.<br /> * In general, the '''Domain''' value here should match Kerberos's krb5.conf file '''default_domain''' value.<br /> <br /> &lt;pre&gt;<br /> [General]<br /> Verbosity = 0<br /> Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br /> Domain = example.com<br /> <br /> [Mapping]<br /> <br /> Nobody-User = nfsnobody<br /> Nobody-Group = nfsnobody<br /> <br /> [Translation]<br /> Method = nsswitch<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/sysconfig/nfs ===<br /> <br /> To enable secure NFS, the following line must be added to /etc/sysconfig/nfs:<br /> <br /> &lt;pre&gt;<br /> SECURE_NFS=yes<br /> &lt;/pre&gt;<br /> <br /> The following are default ports. They may be reconfigured depending on local firewall setups.<br /> <br /> &lt;pre&gt;<br /> # Port rquotad should listen on.<br /> #RQUOTAD_PORT=875<br /> ...<br /> # TCP port rpc.lockd should listen on.<br /> #LOCKD_TCPPORT=32803<br /> # UDP port rpc.lockd should listen on.<br /> #LOCKD_UDPPORT=32769<br /> ...<br /> # Port rpc.mountd should listen on.<br /> #MOUNTD_PORT=892<br /> ...<br /> # Port rpc.statd should listen on.<br /> #STATD_PORT=662<br /> &lt;/pre&gt;<br /> <br /> For large number of connections, the number of NFS Daemons below may need to be increased:<br /> &lt;pre&gt;<br /> RPCNFSDCOUNT=8<br /> &lt;/pre&gt;<br /> <br /> == Firewalls ==<br /> <br /> If there is a firewall on the server, the following default port<br /> should be allowed through to enable NFSv4.<br /> <br /> NFSv4 Ports:<br /> * 2049 TCP<br /> <br /> To open this port through the firewall, add the following lines to &lt;code&gt;/etc/sysconfig/iptables&lt;/code&gt; right before the INPUT REJECT rule:<br /> # nfs server<br /> -A INPUT -m tcp -p tcp --dport 2049 -j ACCEPT<br /> <br /> Then restart iptables:<br /> run_init service iptables restart<br /> <br /> == NFS Start at Boot ==<br /> <br /> Make NFS start during boot:<br /> <br /> &lt;pre&gt;<br /> # chkconfig nfs on<br /> &lt;/pre&gt;<br /> <br /> '''Note:''' The rpcsvcgssd service needs to start after network services on your host. If it does not start properly at boot time, try moving it to start after network initialization (e.g. NetworkManager) in the initial start order (i.e. within /etc/rc.d/).<br /> <br /> === SELinux Policy tweaks ===<br /> Install the NFS Server SELinux policy binary RPM, or build and install from the available SRPM.<br /> <br /> == Start nfs ==<br /> run_init service nfs start<br /> <br /> = NFSv4 Client =<br /> == NFS Client Packages ==<br /> <br /> The NFS client requires the installation of one package, the SEFOS Client SELinux policy package. The latest version of the package is identified on the main Labeled NFS demo page.<br /> <br /> Other Useful Packages:<br /> * nfswatch<br /> <br /> == Create Kerberos Principals ==<br /> <br /> Run kadmin on the '''client''' and create an nfs principal for the<br /> client. Then, add the principal to the client's local key table.<br /> * Replace seclient.example.com with the fully qualified name of the client machine.<br /> * '''Note''' the special way in which the NFS principal is added. The encryption key type is specified.<br /> ** If this is not done, NFS will fail in mysterious ways and it will be difficult to track down the problem.<br /> ** This is apparently because the NFS kernel code only supports des-cbc-crc.<br /> <br /> &lt;pre&gt;<br /> # kadmin<br /> Authenticating as principal root/admin@server.example.com with password.<br /> Password for root/admin@server.example.com<br /> kadmin: addprinc -randkey nfs/seclient.example.com<br /> kadmin: ktadd -e des-cbc-crc:normal nfs/seclient.example.com<br /> kadmin: quit<br /> &lt;/pre&gt;<br /> <br /> == NFS Client File Configuration ==<br /> === Modify /etc/idmapd.conf ===<br /> <br /> You must change the domain to your current domain. Also, The user<br /> mapping for nobody should be checked and updated to nfsnobody if<br /> necessary.<br /> * In general, the '''Domain''' value here should match Kerberos's krb5.conf file '''default_domain''' value.<br /> <br /> &lt;pre&gt;<br /> [General]<br /> Verbosity = 0<br /> Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br /> Domain = example.com<br /> <br /> [Mapping]<br /> <br /> Nobody-User = nfsnobody<br /> Nobody-Group = nfsnobody<br /> <br /> [Translation]<br /> Method = nsswitch<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/sysconfig/nfs ===<br /> <br /> To enable secure NFS, the following line must be included in /etc/sysconfig/nfs:<br /> <br /> &lt;pre&gt;<br /> SECURE_NFS=yes<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/fstab ===<br /> Create a directory for the mount:<br /> mkdir /mnt/nfs4<br /> <br /> Add the directories to be mounted to fstab:<br /> &lt;pre&gt;<br /> sefos:/ /mnt/nfs4 nfs4 users,sec=krb5 0 0<br /> &lt;/pre&gt;<br /> <br /> == SELinux Policy tweaks ==<br /> <br /> The NFS client package contains a script that performs some post install configuration. The core<br /> action performed by the script is to set these three SELinux booleans:<br /> &lt;ul&gt;<br /> &lt;li&gt;allow_kerberos - required for client-side Kerberos to function properly<br /> &lt;li&gt;allow_gssd_read_tmp - required for RPC GSSD to read cached Kerberos credentials in /tmp (for passing credentials between NFS client and server)<br /> &lt;li&gt;use_nfs_home_dirs - allow home directories (/home) to be mounted via NFS<br /> &lt;/ul&gt;<br /> <br /> The script is automatically run during the first normal system boot so no manual action beyond installing<br /> the package should be required.<br /> <br /> = Testing NFS =<br /> <br /> * Assumes that the Kerberos server is running and the client is configured for Kerberos.<br /> <br /> The following should not produce errors and should show the contents<br /> of /mnt/export on the NFS server:<br /> <br /> &lt;pre&gt;<br /> [root@seclient /]# kinit -p root/admin<br /> Password for root/admin@EXAMPLE.COM:<br /> [root@seclient /]# mount /mnt/nfs4<br /> [root@seclient /]# ls /mnt/nfs4<br /> &lt;/pre&gt;<br /> <br /> = NFS References =<br /> <br /> * Projects: NFS Version 4 Open Source [http://www.citi.umich.edu/projects/nfsv4/linux/ Reference Implementation]<br /> * Network File System (NFS) version 4 Protocol, RFC 3530<br /> * NFS Version 4 Design Considerations, RFC 2624</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Manual/NFSv4 Labeled NFS/Demo/Manual/NFSv4 2008-12-15T15:50:51Z <p>CraigGrube: /* NFS Client Packages */</p> <hr /> <div>= NFSv4 Server =<br /> == NFS Server Packages ==<br /> <br /> The NFS server installation requires three custom packages, two of which replace/upgrade<br /> existing packages to include support for Labeled NFS. The third package includes SELinux <br /> policy necessary for the NFS server to access and manage exported files and directories. The latest versions<br /> of the packages are identified on the main Labeled NFS demo page.<br /> <br /> * Linux Kernel with Labeled NFS patches<br /> * NFS Utils with Labeled NFS patches<br /> * SEFOS Server SELinux policy <br /> <br /> The NFS server is also a Kerberos client, so the packages identified in the Kerberos client configuration section are required.<br /> <br /> Other useful packages:<br /> * system-config-nfs<br /> * nfswatch<br /> <br /> == Create Kerberos Principals ==<br /> <br /> Run kadmin on the '''Kerberos Server''' and create the nfs principal<br /> for the server. Then, add the nfs principal's key to the local<br /> keytab file.<br /> * Replace nfsserver.example.com with the fully qualified name of the NFSv4 server machine.<br /> * The same machine may host the NFSv4 server and the Kerberos server. In that case, both the principle creation and the adding of the principle to the local key table are still required.<br /> * '''Note''' the special way in which the NFS principal is added. The encryption key type is specified.<br /> ** If this is not done, NFS will fail in mysterious ways and it will be difficult to track down the problem.<br /> ** This is apparently because the NFS kernel code only supports des-cbc-crc.<br /> <br /> &lt;pre&gt;<br /> # kadmin<br /> Authenticating as principal root/admin@server.example.com with password.<br /> Password for root/admin@server.example.com<br /> kadmin: addprinc -randkey nfs/nfsserver.example.com<br /> kadmin: ktadd -e des-cbc-crc:normal nfs/nfsserver.example.com<br /> kadmin: quit<br /> &lt;/pre&gt;<br /> <br /> == Server Configuration ==<br /> Create the necessary entries in /etc/exports. <br /> * create an NFSv4 mount point. <br /> ** e.g. /mnt/export. <br /> * Next bind the real path to the NFSv4 mount point. <br /> ** e.g. /mnt/export/home<br /> ** fstab entry binding the real path to the mount point should be added to to /etc/fstab so that it is remounted after each boot.<br /> <br /> &lt;pre&gt;<br /> mkdir -m 1777 /mnt/export<br /> mkdir /mnt/export/home<br /> echo &quot;/home /mnt/export/home none bind 0 0&quot; &gt;&gt; /etc/fstab<br /> mount -a<br /> &lt;/pre&gt;<br /> <br /> <br /> === /etc/exports ===<br /> The exported directories need to be added to /etc/exports:<br /> <br /> &lt;pre&gt;<br /> /mnt/export 192.168.201.0/24(sec=krb5:krb5i:krb5p,security_label,sync,rw,fsid=0,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash) <br /> <br /> /mnt/export/home 192.168.201.0/24(sec=krb5:krb5i:krb5p,security_label,sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash)<br /> &lt;/pre&gt;<br /> <br /> and if legacy NFSv3 mounts are desired add:<br /> <br /> &lt;pre&gt;<br /> # Legacy mounts<br /> /home 192.168.201.0/24(sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash)<br /> &lt;/pre&gt;<br /> <br /> '''Note''' On 64 bit machines, the anonuid and anongid above should be set to '4294967294'.<br /> <br /> === Modify /etc/idmapd.conf ===<br /> <br /> You must change the domain to your current domain. Also, The user<br /> mapping for nobody should be checked and updated to nfsnobody if<br /> necessary.<br /> * In general, the '''Domain''' value here should match Kerberos's krb5.conf file '''default_domain''' value.<br /> <br /> &lt;pre&gt;<br /> [General]<br /> Verbosity = 0<br /> Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br /> Domain = example.com<br /> <br /> [Mapping]<br /> <br /> Nobody-User = nfsnobody<br /> Nobody-Group = nfsnobody<br /> <br /> [Translation]<br /> Method = nsswitch<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/sysconfig/nfs ===<br /> <br /> To enable secure NFS, the following line must be added to /etc/sysconfig/nfs:<br /> <br /> &lt;pre&gt;<br /> SECURE_NFS=yes<br /> &lt;/pre&gt;<br /> <br /> The following are default ports. They may be reconfigured depending on local firewall setups.<br /> <br /> &lt;pre&gt;<br /> # Port rquotad should listen on.<br /> #RQUOTAD_PORT=875<br /> ...<br /> # TCP port rpc.lockd should listen on.<br /> #LOCKD_TCPPORT=32803<br /> # UDP port rpc.lockd should listen on.<br /> #LOCKD_UDPPORT=32769<br /> ...<br /> # Port rpc.mountd should listen on.<br /> #MOUNTD_PORT=892<br /> ...<br /> # Port rpc.statd should listen on.<br /> #STATD_PORT=662<br /> &lt;/pre&gt;<br /> <br /> For large number of connections, the number of NFS Daemons below may need to be increased:<br /> &lt;pre&gt;<br /> RPCNFSDCOUNT=8<br /> &lt;/pre&gt;<br /> <br /> == Firewalls ==<br /> <br /> If there is a firewall on the server, the following default port<br /> should be allowed through to enable NFSv4.<br /> <br /> NFSv4 Ports:<br /> * 2049 TCP<br /> <br /> To open this port through the firewall, add the following lines to &lt;code&gt;/etc/sysconfig/iptables&lt;/code&gt; right before the INPUT REJECT rule:<br /> # nfs server<br /> -A INPUT -m tcp -p tcp --dport 2049 -j ACCEPT<br /> <br /> Then restart iptables:<br /> run_init service iptables restart<br /> <br /> == NFS Start at Boot ==<br /> <br /> Make NFS start during boot:<br /> <br /> &lt;pre&gt;<br /> # chkconfig nfs on<br /> &lt;/pre&gt;<br /> <br /> '''Note:''' The rpcsvcgssd service needs to start after network services on your host. If it does not start properly at boot time, try moving it to start after network initialization (e.g. NetworkManager) in the initial start order (i.e. within /etc/rc.d/).<br /> <br /> === SELinux Policy tweaks ===<br /> Install the NFS Server SELinux policy binary RPM, or build and install from the available SRPM.<br /> <br /> == Start nfs ==<br /> run_init service nfs start<br /> <br /> = NFSv4 Client =<br /> == NFS Client Packages ==<br /> <br /> The NFS client requires the installation of one package, the SEFOS Client SELinux policy package.<br /> <br /> Other Useful Packages:<br /> * nfswatch<br /> <br /> == Create Kerberos Principals ==<br /> <br /> Run kadmin on the '''client''' and create an nfs principal for the<br /> client. Then, add the principal to the client's local key table.<br /> * Replace seclient.example.com with the fully qualified name of the client machine.<br /> * '''Note''' the special way in which the NFS principal is added. The encryption key type is specified.<br /> ** If this is not done, NFS will fail in mysterious ways and it will be difficult to track down the problem.<br /> ** This is apparently because the NFS kernel code only supports des-cbc-crc.<br /> <br /> &lt;pre&gt;<br /> # kadmin<br /> Authenticating as principal root/admin@server.example.com with password.<br /> Password for root/admin@server.example.com<br /> kadmin: addprinc -randkey nfs/seclient.example.com<br /> kadmin: ktadd -e des-cbc-crc:normal nfs/seclient.example.com<br /> kadmin: quit<br /> &lt;/pre&gt;<br /> <br /> == NFS Client File Configuration ==<br /> === Modify /etc/idmapd.conf ===<br /> <br /> You must change the domain to your current domain. Also, The user<br /> mapping for nobody should be checked and updated to nfsnobody if<br /> necessary.<br /> * In general, the '''Domain''' value here should match Kerberos's krb5.conf file '''default_domain''' value.<br /> <br /> &lt;pre&gt;<br /> [General]<br /> Verbosity = 0<br /> Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br /> Domain = example.com<br /> <br /> [Mapping]<br /> <br /> Nobody-User = nfsnobody<br /> Nobody-Group = nfsnobody<br /> <br /> [Translation]<br /> Method = nsswitch<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/sysconfig/nfs ===<br /> <br /> To enable secure NFS, the following line must be included in /etc/sysconfig/nfs:<br /> <br /> &lt;pre&gt;<br /> SECURE_NFS=yes<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/fstab ===<br /> Create a directory for the mount:<br /> mkdir /mnt/nfs4<br /> <br /> Add the directories to be mounted to fstab:<br /> &lt;pre&gt;<br /> sefos:/ /mnt/nfs4 nfs4 users,sec=krb5 0 0<br /> &lt;/pre&gt;<br /> <br /> == SELinux Policy tweaks ==<br /> <br /> The NFS client package contains a script that performs some post install configuration. The core<br /> action performed by the script is to set these three SELinux booleans:<br /> &lt;ul&gt;<br /> &lt;li&gt;allow_kerberos - required for client-side Kerberos to function properly<br /> &lt;li&gt;allow_gssd_read_tmp - required for RPC GSSD to read cached Kerberos credentials in /tmp (for passing credentials between NFS client and server)<br /> &lt;li&gt;use_nfs_home_dirs - allow home directories (/home) to be mounted via NFS<br /> &lt;/ul&gt;<br /> <br /> The script is automatically run during the first normal system boot so no manual action beyond installing<br /> the package should be required.<br /> <br /> = Testing NFS =<br /> <br /> * Assumes that the Kerberos server is running and the client is configured for Kerberos.<br /> <br /> The following should not produce errors and should show the contents<br /> of /mnt/export on the NFS server:<br /> <br /> &lt;pre&gt;<br /> [root@seclient /]# kinit -p root/admin<br /> Password for root/admin@EXAMPLE.COM:<br /> [root@seclient /]# mount /mnt/nfs4<br /> [root@seclient /]# ls /mnt/nfs4<br /> &lt;/pre&gt;<br /> <br /> = NFS References =<br /> <br /> * Projects: NFS Version 4 Open Source [http://www.citi.umich.edu/projects/nfsv4/linux/ Reference Implementation]<br /> * Network File System (NFS) version 4 Protocol, RFC 3530<br /> * NFS Version 4 Design Considerations, RFC 2624</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Manual/NFSv4 Labeled NFS/Demo/Manual/NFSv4 2008-12-15T15:49:30Z <p>CraigGrube: /* NFS Server Packages */</p> <hr /> <div>= NFSv4 Server =<br /> == NFS Server Packages ==<br /> <br /> The NFS server installation requires three custom packages, two of which replace/upgrade<br /> existing packages to include support for Labeled NFS. The third package includes SELinux <br /> policy necessary for the NFS server to access and manage exported files and directories. The latest versions<br /> of the packages are identified on the main Labeled NFS demo page.<br /> <br /> * Linux Kernel with Labeled NFS patches<br /> * NFS Utils with Labeled NFS patches<br /> * SEFOS Server SELinux policy <br /> <br /> The NFS server is also a Kerberos client, so the packages identified in the Kerberos client configuration section are required.<br /> <br /> Other useful packages:<br /> * system-config-nfs<br /> * nfswatch<br /> <br /> == Create Kerberos Principals ==<br /> <br /> Run kadmin on the '''Kerberos Server''' and create the nfs principal<br /> for the server. Then, add the nfs principal's key to the local<br /> keytab file.<br /> * Replace nfsserver.example.com with the fully qualified name of the NFSv4 server machine.<br /> * The same machine may host the NFSv4 server and the Kerberos server. In that case, both the principle creation and the adding of the principle to the local key table are still required.<br /> * '''Note''' the special way in which the NFS principal is added. The encryption key type is specified.<br /> ** If this is not done, NFS will fail in mysterious ways and it will be difficult to track down the problem.<br /> ** This is apparently because the NFS kernel code only supports des-cbc-crc.<br /> <br /> &lt;pre&gt;<br /> # kadmin<br /> Authenticating as principal root/admin@server.example.com with password.<br /> Password for root/admin@server.example.com<br /> kadmin: addprinc -randkey nfs/nfsserver.example.com<br /> kadmin: ktadd -e des-cbc-crc:normal nfs/nfsserver.example.com<br /> kadmin: quit<br /> &lt;/pre&gt;<br /> <br /> == Server Configuration ==<br /> Create the necessary entries in /etc/exports. <br /> * create an NFSv4 mount point. <br /> ** e.g. /mnt/export. <br /> * Next bind the real path to the NFSv4 mount point. <br /> ** e.g. /mnt/export/home<br /> ** fstab entry binding the real path to the mount point should be added to to /etc/fstab so that it is remounted after each boot.<br /> <br /> &lt;pre&gt;<br /> mkdir -m 1777 /mnt/export<br /> mkdir /mnt/export/home<br /> echo &quot;/home /mnt/export/home none bind 0 0&quot; &gt;&gt; /etc/fstab<br /> mount -a<br /> &lt;/pre&gt;<br /> <br /> <br /> === /etc/exports ===<br /> The exported directories need to be added to /etc/exports:<br /> <br /> &lt;pre&gt;<br /> /mnt/export 192.168.201.0/24(sec=krb5:krb5i:krb5p,security_label,sync,rw,fsid=0,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash) <br /> <br /> /mnt/export/home 192.168.201.0/24(sec=krb5:krb5i:krb5p,security_label,sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash)<br /> &lt;/pre&gt;<br /> <br /> and if legacy NFSv3 mounts are desired add:<br /> <br /> &lt;pre&gt;<br /> # Legacy mounts<br /> /home 192.168.201.0/24(sync,rw,nohide,insecure,no_subtree_check,anonuid=65534,anongid=65534,no_root_squash)<br /> &lt;/pre&gt;<br /> <br /> '''Note''' On 64 bit machines, the anonuid and anongid above should be set to '4294967294'.<br /> <br /> === Modify /etc/idmapd.conf ===<br /> <br /> You must change the domain to your current domain. Also, The user<br /> mapping for nobody should be checked and updated to nfsnobody if<br /> necessary.<br /> * In general, the '''Domain''' value here should match Kerberos's krb5.conf file '''default_domain''' value.<br /> <br /> &lt;pre&gt;<br /> [General]<br /> Verbosity = 0<br /> Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br /> Domain = example.com<br /> <br /> [Mapping]<br /> <br /> Nobody-User = nfsnobody<br /> Nobody-Group = nfsnobody<br /> <br /> [Translation]<br /> Method = nsswitch<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/sysconfig/nfs ===<br /> <br /> To enable secure NFS, the following line must be added to /etc/sysconfig/nfs:<br /> <br /> &lt;pre&gt;<br /> SECURE_NFS=yes<br /> &lt;/pre&gt;<br /> <br /> The following are default ports. They may be reconfigured depending on local firewall setups.<br /> <br /> &lt;pre&gt;<br /> # Port rquotad should listen on.<br /> #RQUOTAD_PORT=875<br /> ...<br /> # TCP port rpc.lockd should listen on.<br /> #LOCKD_TCPPORT=32803<br /> # UDP port rpc.lockd should listen on.<br /> #LOCKD_UDPPORT=32769<br /> ...<br /> # Port rpc.mountd should listen on.<br /> #MOUNTD_PORT=892<br /> ...<br /> # Port rpc.statd should listen on.<br /> #STATD_PORT=662<br /> &lt;/pre&gt;<br /> <br /> For large number of connections, the number of NFS Daemons below may need to be increased:<br /> &lt;pre&gt;<br /> RPCNFSDCOUNT=8<br /> &lt;/pre&gt;<br /> <br /> == Firewalls ==<br /> <br /> If there is a firewall on the server, the following default port<br /> should be allowed through to enable NFSv4.<br /> <br /> NFSv4 Ports:<br /> * 2049 TCP<br /> <br /> To open this port through the firewall, add the following lines to &lt;code&gt;/etc/sysconfig/iptables&lt;/code&gt; right before the INPUT REJECT rule:<br /> # nfs server<br /> -A INPUT -m tcp -p tcp --dport 2049 -j ACCEPT<br /> <br /> Then restart iptables:<br /> run_init service iptables restart<br /> <br /> == NFS Start at Boot ==<br /> <br /> Make NFS start during boot:<br /> <br /> &lt;pre&gt;<br /> # chkconfig nfs on<br /> &lt;/pre&gt;<br /> <br /> '''Note:''' The rpcsvcgssd service needs to start after network services on your host. If it does not start properly at boot time, try moving it to start after network initialization (e.g. NetworkManager) in the initial start order (i.e. within /etc/rc.d/).<br /> <br /> === SELinux Policy tweaks ===<br /> Install the NFS Server SELinux policy binary RPM, or build and install from the available SRPM.<br /> <br /> == Start nfs ==<br /> run_init service nfs start<br /> <br /> = NFSv4 Client =<br /> == NFS Client Packages ==<br /> <br /> The NFS client requires the installation of one package:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Other Useful Packages:<br /> * nfswatch<br /> <br /> == Create Kerberos Principals ==<br /> <br /> Run kadmin on the '''client''' and create an nfs principal for the<br /> client. Then, add the principal to the client's local key table.<br /> * Replace seclient.example.com with the fully qualified name of the client machine.<br /> * '''Note''' the special way in which the NFS principal is added. The encryption key type is specified.<br /> ** If this is not done, NFS will fail in mysterious ways and it will be difficult to track down the problem.<br /> ** This is apparently because the NFS kernel code only supports des-cbc-crc.<br /> <br /> &lt;pre&gt;<br /> # kadmin<br /> Authenticating as principal root/admin@server.example.com with password.<br /> Password for root/admin@server.example.com<br /> kadmin: addprinc -randkey nfs/seclient.example.com<br /> kadmin: ktadd -e des-cbc-crc:normal nfs/seclient.example.com<br /> kadmin: quit<br /> &lt;/pre&gt;<br /> <br /> == NFS Client File Configuration ==<br /> === Modify /etc/idmapd.conf ===<br /> <br /> You must change the domain to your current domain. Also, The user<br /> mapping for nobody should be checked and updated to nfsnobody if<br /> necessary.<br /> * In general, the '''Domain''' value here should match Kerberos's krb5.conf file '''default_domain''' value.<br /> <br /> &lt;pre&gt;<br /> [General]<br /> Verbosity = 0<br /> Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br /> Domain = example.com<br /> <br /> [Mapping]<br /> <br /> Nobody-User = nfsnobody<br /> Nobody-Group = nfsnobody<br /> <br /> [Translation]<br /> Method = nsswitch<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/sysconfig/nfs ===<br /> <br /> To enable secure NFS, the following line must be included in /etc/sysconfig/nfs:<br /> <br /> &lt;pre&gt;<br /> SECURE_NFS=yes<br /> &lt;/pre&gt;<br /> <br /> === Modify /etc/fstab ===<br /> Create a directory for the mount:<br /> mkdir /mnt/nfs4<br /> <br /> Add the directories to be mounted to fstab:<br /> &lt;pre&gt;<br /> sefos:/ /mnt/nfs4 nfs4 users,sec=krb5 0 0<br /> &lt;/pre&gt;<br /> <br /> == SELinux Policy tweaks ==<br /> <br /> The NFS client package contains a script that performs some post install configuration. The core<br /> action performed by the script is to set these three SELinux booleans:<br /> &lt;ul&gt;<br /> &lt;li&gt;allow_kerberos - required for client-side Kerberos to function properly<br /> &lt;li&gt;allow_gssd_read_tmp - required for RPC GSSD to read cached Kerberos credentials in /tmp (for passing credentials between NFS client and server)<br /> &lt;li&gt;use_nfs_home_dirs - allow home directories (/home) to be mounted via NFS<br /> &lt;/ul&gt;<br /> <br /> The script is automatically run during the first normal system boot so no manual action beyond installing<br /> the package should be required.<br /> <br /> = Testing NFS =<br /> <br /> * Assumes that the Kerberos server is running and the client is configured for Kerberos.<br /> <br /> The following should not produce errors and should show the contents<br /> of /mnt/export on the NFS server:<br /> <br /> &lt;pre&gt;<br /> [root@seclient /]# kinit -p root/admin<br /> Password for root/admin@EXAMPLE.COM:<br /> [root@seclient /]# mount /mnt/nfs4<br /> [root@seclient /]# ls /mnt/nfs4<br /> &lt;/pre&gt;<br /> <br /> = NFS References =<br /> <br /> * Projects: NFS Version 4 Open Source [http://www.citi.umich.edu/projects/nfsv4/linux/ Reference Implementation]<br /> * Network File System (NFS) version 4 Protocol, RFC 3530<br /> * NFS Version 4 Design Considerations, RFC 2624</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Kickstart Labeled NFS/Demo/Kickstart 2008-12-15T15:47:31Z <p>CraigGrube: /* Packages */</p> <hr /> <div>This page details the steps required to setup the SEFOS NFSv4 client and<br /> server, including some optional steps to provide basic network services<br /> and a build server. <br /> <br /> The services provided<br /> by the build server can be mixed and matched as needed to supplement existing<br /> network services to provide the <br /> basic functionality required to successfully build a client or server from <br /> a kickstart.<br /> <br /> The binary RPM packages required for the Labeled NFS to work properly were compiled<br /> for Fedora Core 9 systems. Source RPMs are available for compiling your own packages.<br /> <br /> = Boot Server Configuration (Optional) =<br /> The sample configurations assume a local network using the 192.168.201.0/24 <br /> address block. Network ranges/addresses should be modified to match<br /> those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration <br /> examples and in the demo environment. The domain may be modified to match<br /> an existing domain. Changes to the kickstarts will be required to set the<br /> new default domain and to change the creation of the ldap structure if the<br /> domain name is increased beyond two levels.<br /> <br /> <br /> == Installing packages ==<br /> <br /> The YUM package tool is used to install packages. This requires a<br /> connection to the Internet to connect to remote package repositories, or<br /> a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated<br /> packages.<br /> <br /> == Setting up the DHCP server ==<br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The<br /> example provided is one that is being used in a VMware environment.<br /> <br /> [excerpt from sample /etc/dhcpd.conf]<br /> &lt;pre&gt;<br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host seserver {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;seserver.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it<br /> might be useful to generate that portion of the DHCPD config file from a<br /> flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the DNS Server ==<br /> packages: named<br /> <br /> The default configuration will only listen on the localhost address. You will <br /> need to set the listen-on and allow-query addresses in the options section<br /> of /etc/named.conf so that named can respond to queries on the local network.<br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> Add forward and reverse zones for the address range in use:<br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> seserver A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client2 A 192.168.201.51<br /> client3 A 192.168.201.52<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR seserver.example.com.<br /> <br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> 52 IN PTR client3.example.com.<br /> &lt;/pre&gt;<br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named start<br /> &lt;/pre&gt;<br /> <br /> == Setting up the Web server ==<br /> packages: httpd<br /> <br /> Download the latest versions of the kickstart files and binary RPMs as identified on the main[[Labeled_NFS/Demo|Labeled NFS Demo]] page.<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Client Kickstart<br /> &lt;li&gt;Server Kickstart<br /> &lt;li&gt;Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;NFS Utils with Labeled NFS patches<br /> &lt;li&gt;SELinux policy for labeled NFS server<br /> &lt;li&gt;SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Create a directory to hold the kickstart files [/var/www/html/kickstart/]. Copy the client and server kickstart files into this directory.<br /> <br /> Create directories to hold the RPMs and eventually the server CA public certificate [/var/www/html/conf for packages, and /var/www/html/certs for the certificate]. Copy the Kernel, NFS Utils and SEFOS SELinux policies into /var/www/html/conf.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> Source and binary RPM packages are available at http://www.selinuxnow.org/sefos/packages/<br /> <br /> = Kickstart Customization and System Installation =<br /> <br /> Documentation at the beginning of the kickstart files details some boot time<br /> options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> &lt;ul&gt;<br /> &lt;li&gt;Depending on the network environment the kickstart can be configured to use<br /> DHCP for address provisioning or static addressing. The default is to use<br /> DHCP, however a sample static address configuration is included for reference.<br /> If addresses are assigned statically, the kickstarts will need to be modified<br /> for each client/server installation (to provide the appropriate address).<br /> &lt;li&gt; If installing FC9 from CD/DVD access to an up-to-date FC9 repository (via<br /> external network connection or local mirror) is required as some packages required<br /> for the installs are not included in the CD/DVD install media.<br /> &lt;li&gt;Additional customization of the ldap/kerberos/nfs installation can be <br /> performed in the %post section. <br /> &lt;li&gt;Installs are currently interactive. To convert the kickstarts to a fully automated<br /> install comment out the &quot;interactive&quot; directive at the beginning of the files.<br /> &lt;li&gt;Kerberos requires that client and server system times be synchronized to function<br /> properly. The install does not customize the default FC9 NTP configuration, though it <br /> does attempt to synchronize the system time following reboot against a fedora time server <br /> (0.fedora.pool.ntp.org).<br /> &lt;/ul&gt;<br /> <br /> == Server Kickstart == <br /> <br /> === Introduction ===<br /> The kickstart installs and configures the<br /> server portion of the Labeled NFS Demo environment.<br /> It includes many components that would be used in an<br /> enterprise to provide authentication and authorization<br /> services as well as directory and file sharing services.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are identified on the main demo page.<br /> * Linux kernel with Labeled NFS patches<br /> * NFS-Utils with Labeled NFS patches<br /> * SEFOS Server SELinux policy<br /> <br /> ==== DNS ====<br /> <br /> For Kerberos to function properly, forward and reverse resolution is required for all clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients and for<br /> providing the three custom packages for client <br /> installation.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time for customizing the installation:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - Server's fully qualified domain name.<br /> &lt;li&gt;se_krbpass - Kerberos password for root/admin principal.<br /> &lt;li&gt;se_kdbpass - Kerberos database password.<br /> &lt;li&gt;se_ldappass - LDAP administrator password<br /> &lt;li&gt;se_www - DNS name of web server hosting packages/config (default is www.example.com)<br /> &lt;/ul&gt;<br /> If customizing the LDAP certificate the following options can be used to override the defaults:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_certPW - Certificate Authority certificate password<br /> &lt;li&gt;se_certCountry <br /> &lt;li&gt;se_certState<br /> &lt;li&gt;se_certCity<br /> &lt;li&gt;se_certOrg<br /> &lt;li&gt;se_certEmail<br /> &lt;li&gt;se_certCN<br /> &lt;/ul&gt;<br /> <br /> === Assumptions ===<br /> ==== Kerberos Realm ====<br /> The server DNS name is used to generate the <br /> kerberos realm name and the ldap structure. The domain<br /> of the client and server are currently expected to contain<br /> two levels (i.e. DNS: example.com -&gt; LDAP: dc=example,dc=com -&gt; Kerberos: EXAMPLE.COM).<br /> <br /> ==== Packages ==== <br /> Packages are expected to be in a directory called<br /> conf off of the web server root directory (i.e. http://www.example.com/conf) <br /> <br /> ==== Time Zone ==== <br /> The current default time zone is Pacific. Change as desired.<br /> <br /> === Post Install === <br /> <br /> The client kickstart requires the LDAP<br /> CA certificate during installation time to for proper <br /> configuration. <br /> <br /> &lt;b&gt;The certificate (/etc/openldap/cacerts/cacert.pem)<br /> should be copied into conf/certs/cacert.pem on the web<br /> server.&lt;/b&gt;<br /> <br /> == Client Kickstart ==<br /> <br /> === Introduction ===<br /> This kickstart installs and configures the<br /> client portion of the Labeled NFS Demo.<br /> After a successfully client build, the client will be <br /> a fairly minimimal Fedora installation configured with<br /> GDM and GNOME. The client will be<br /> integrated with the authentication/authorization/directory<br /> services provided by the server component, and user <br /> home directories will be mounted via NFS.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> <br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are identified on the main Labeled NFS Demo page:<br /> * Linux kernel with Labeled NFS patches<br /> * NFS-Utils with Labeled NFS patches<br /> * SEFOS Client SELinux policy<br /> <br /> ==== DNS ====<br /> The kerberos configuration requires an external<br /> DNS service that supports forward and reverse resolution<br /> for the clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients, for<br /> providing the three custom packages, and for providing <br /> the ldap server CA certificate. The RPMS are expected to<br /> be in /conf, and the CA certificate is expected to be in<br /> conf/certs.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time to make client configuration customizations.<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - The fully qualified domain name of the client<br /> &lt;li&gt;se_krbpass - Password for the root/admin kerberos principal.<br /> &lt;li&gt;se_server - FQDN of the server component. Defaults to seserver.$dnsdomain<br /> &lt;/ul&gt;<br /> <br /> = Using the Environment = <br /> <br /> After the installation is complete the following accounts are available:<br /> <br /> * Server<br /> ** root - sefos1<br /> ** Kerberos Database (required to add slave KDCs)<br /> *** kdbpass<br /> ** Kerberos root/admin principal<br /> *** say#fos#<br /> * Client<br /> ** root - sefos1<br /> ** newuser - newuser1<br /> <br /> Passwords should be changed from the defaults after completing installation, especially if the clients or servers are reachable from the Internet.<br /> <br /> Using the '''newuser''' account you should now be able to login on the client using GDM or on a virtual console.<br /> <br /> = Troubleshooting (in progress)=<br /> <br /> Additional information that may be useful for troubleshooting is available in the manual installation guide with the appropriate service.<br /> <br /> * If the newuser account does not work on the client:<br /> ** Switch to a virtual console (ctrl-alt-f1) and login as root<br /> ** Verify that Kerberos was successfully configured:<br /> *** Use &lt;code&gt;klist -k /etc/krb5.keytab&lt;/code&gt;.<br /> *** If the keytab does not exist there was an error that prevented kadmin from creating the host and nfs principals during installation. Otherwise the output should show four keys for the host (i.e. host/client.example.com) and one for nfs (i.e. nfs/client.example.com). This is likely either a password mismatch issue or a time synchronization issue. <br /> *** Verify the client and server times are similar using '''date'''. <br /> **** If not, use &lt;code&gt; run_init service ntpd stop&lt;/code&gt; to turn of ntpd, then use &lt;code&gt;ntpdate -b -x 0.fedora.pool.ntp.org&lt;/code&gt; to sync time with the external time server. Use &lt;code&gt;run_init service ntpd start&lt;/code&gt; to start ntpd.<br /> **** If the external time server is unreachable, or an internal time source is preferred, reconfigure ntpd to use the desired time source and use that host instead of 0.fedora.pool.ntp.org in the ntpdate command.<br /> **** Manually synchronize both the client and server to ensure they are correct. <br /> *** Once syncronized time has been verified or established, follow the steps in the [[Labeled_NFS/Demo/Manual/Kerberos| Kerberos configuration guide]] to create the host and nfs principals, and store them locally in a keytab.<br /> ** Verify that LDAP was successfully configured:<br /> *** Examine /var/log/messages for LDAP related errors<br /> *** During testing we encountered errors where the client was unable to connect to the LDAP server. The errors were related to forgetting to copy the CA certificate into the appropriate area of the web server, forgetting to update the certificate if we built a new server, or having Apache serve an older certificate that was cached.<br /> *** Use scp to copy the CA certificate from the server to the client: &lt;code&gt; scp seserver:/etc/openldap/cacerts/cacert.pem /etc/openldap/cacerts/&lt;/code&gt;<br /> ** Verify that three SELinux booleans were correctly set on the client.<br /> *** Run &lt;code&gt;getsebool allow_kerberos allow_gssd_read_tmp use_nfs_home_dirs&lt;/code&gt; and verify the values are all set as '''on'''<br /> ** Verify that NFSv4 mounts work properly.<br /> *** Run &lt;code&gt;kinit -p root/admin&lt;/code&gt; to initialize your Kerberos credentials.<br /> *** Run &lt;code&gt;mount -v -t nfs4 -o sec=krb5,security_label seserver:/home /mnt&lt;/code&gt; to mount /mnt/home from the server.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Kickstart Labeled NFS/Demo/Kickstart 2008-12-15T15:44:23Z <p>CraigGrube: /* Boot Options */</p> <hr /> <div>This page details the steps required to setup the SEFOS NFSv4 client and<br /> server, including some optional steps to provide basic network services<br /> and a build server. <br /> <br /> The services provided<br /> by the build server can be mixed and matched as needed to supplement existing<br /> network services to provide the <br /> basic functionality required to successfully build a client or server from <br /> a kickstart.<br /> <br /> The binary RPM packages required for the Labeled NFS to work properly were compiled<br /> for Fedora Core 9 systems. Source RPMs are available for compiling your own packages.<br /> <br /> = Boot Server Configuration (Optional) =<br /> The sample configurations assume a local network using the 192.168.201.0/24 <br /> address block. Network ranges/addresses should be modified to match<br /> those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration <br /> examples and in the demo environment. The domain may be modified to match<br /> an existing domain. Changes to the kickstarts will be required to set the<br /> new default domain and to change the creation of the ldap structure if the<br /> domain name is increased beyond two levels.<br /> <br /> <br /> == Installing packages ==<br /> <br /> The YUM package tool is used to install packages. This requires a<br /> connection to the Internet to connect to remote package repositories, or<br /> a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated<br /> packages.<br /> <br /> == Setting up the DHCP server ==<br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The<br /> example provided is one that is being used in a VMware environment.<br /> <br /> [excerpt from sample /etc/dhcpd.conf]<br /> &lt;pre&gt;<br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host seserver {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;seserver.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it<br /> might be useful to generate that portion of the DHCPD config file from a<br /> flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the DNS Server ==<br /> packages: named<br /> <br /> The default configuration will only listen on the localhost address. You will <br /> need to set the listen-on and allow-query addresses in the options section<br /> of /etc/named.conf so that named can respond to queries on the local network.<br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> Add forward and reverse zones for the address range in use:<br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> seserver A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client2 A 192.168.201.51<br /> client3 A 192.168.201.52<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR seserver.example.com.<br /> <br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> 52 IN PTR client3.example.com.<br /> &lt;/pre&gt;<br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named start<br /> &lt;/pre&gt;<br /> <br /> == Setting up the Web server ==<br /> packages: httpd<br /> <br /> Download the latest versions of the kickstart files and binary RPMs as identified on the main[[Labeled_NFS/Demo|Labeled NFS Demo]] page.<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Client Kickstart<br /> &lt;li&gt;Server Kickstart<br /> &lt;li&gt;Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;NFS Utils with Labeled NFS patches<br /> &lt;li&gt;SELinux policy for labeled NFS server<br /> &lt;li&gt;SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Create a directory to hold the kickstart files [/var/www/html/kickstart/]. Copy the client and server kickstart files into this directory.<br /> <br /> Create directories to hold the RPMs and eventually the server CA public certificate [/var/www/html/conf for packages, and /var/www/html/certs for the certificate]. Copy the Kernel, NFS Utils and SEFOS SELinux policies into /var/www/html/conf.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> Source and binary RPM packages are available at http://www.selinuxnow.org/sefos/packages/<br /> <br /> = Kickstart Customization and System Installation =<br /> <br /> Documentation at the beginning of the kickstart files details some boot time<br /> options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> &lt;ul&gt;<br /> &lt;li&gt;Depending on the network environment the kickstart can be configured to use<br /> DHCP for address provisioning or static addressing. The default is to use<br /> DHCP, however a sample static address configuration is included for reference.<br /> If addresses are assigned statically, the kickstarts will need to be modified<br /> for each client/server installation (to provide the appropriate address).<br /> &lt;li&gt; If installing FC9 from CD/DVD access to an up-to-date FC9 repository (via<br /> external network connection or local mirror) is required as some packages required<br /> for the installs are not included in the CD/DVD install media.<br /> &lt;li&gt;Additional customization of the ldap/kerberos/nfs installation can be <br /> performed in the %post section. <br /> &lt;li&gt;Installs are currently interactive. To convert the kickstarts to a fully automated<br /> install comment out the &quot;interactive&quot; directive at the beginning of the files.<br /> &lt;li&gt;Kerberos requires that client and server system times be synchronized to function<br /> properly. The install does not customize the default FC9 NTP configuration, though it <br /> does attempt to synchronize the system time following reboot against a fedora time server <br /> (0.fedora.pool.ntp.org).<br /> &lt;/ul&gt;<br /> <br /> == Server Kickstart == <br /> <br /> === Introduction ===<br /> The kickstart installs and configures the<br /> server portion of the Labeled NFS Demo environment.<br /> It includes many components that would be used in an<br /> enterprise to provide authentication and authorization<br /> services as well as directory and file sharing services.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are identified on the main demo page.<br /> * Linux kernel with Labeled NFS patches<br /> * NFS-Utils with Labeled NFS patches<br /> * SEFOS Server SELinux policy<br /> <br /> ==== DNS ====<br /> <br /> For Kerberos to function properly, forward and reverse resolution is required for all clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients and for<br /> providing the three custom packages for client <br /> installation.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time for customizing the installation:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - Server's fully qualified domain name.<br /> &lt;li&gt;se_krbpass - Kerberos password for root/admin principal.<br /> &lt;li&gt;se_kdbpass - Kerberos database password.<br /> &lt;li&gt;se_ldappass - LDAP administrator password<br /> &lt;li&gt;se_www - DNS name of web server hosting packages/config (default is www.example.com)<br /> &lt;/ul&gt;<br /> If customizing the LDAP certificate the following options can be used to override the defaults:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_certPW - Certificate Authority certificate password<br /> &lt;li&gt;se_certCountry <br /> &lt;li&gt;se_certState<br /> &lt;li&gt;se_certCity<br /> &lt;li&gt;se_certOrg<br /> &lt;li&gt;se_certEmail<br /> &lt;li&gt;se_certCN<br /> &lt;/ul&gt;<br /> <br /> === Assumptions ===<br /> ==== Kerberos Realm ====<br /> The server DNS name is used to generate the <br /> kerberos realm name and the ldap structure. The domain<br /> of the client and server are currently expected to contain<br /> two levels (i.e. DNS: example.com -&gt; LDAP: dc=example,dc=com -&gt; Kerberos: EXAMPLE.COM).<br /> <br /> ==== Packages ==== <br /> Packages are expected to be in a directory called<br /> conf off of the web server root directory (i.e. http://www.example.com/conf) <br /> <br /> ==== Time Zone ==== <br /> The current default time zone is Pacific. Change as desired.<br /> <br /> === Post Install === <br /> <br /> The client kickstart requires the LDAP<br /> CA certificate during installation time to for proper <br /> configuration. <br /> <br /> &lt;b&gt;The certificate (/etc/openldap/cacerts/cacert.pem)<br /> should be copied into conf/certs/cacert.pem on the web<br /> server.&lt;/b&gt;<br /> <br /> == Client Kickstart ==<br /> <br /> === Introduction ===<br /> This kickstart installs and configures the<br /> client portion of the Labeled NFS Demo.<br /> After a successfully client build, the client will be <br /> a fairly minimimal Fedora installation configured with<br /> GDM and GNOME. The client will be<br /> integrated with the authentication/authorization/directory<br /> services provided by the server component, and user <br /> home directories will be mounted via NFS.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> <br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-client-policy-0.1-1.fc9.i386.rpm <br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> The kerberos configuration requires an external<br /> DNS service that supports forward and reverse resolution<br /> for the clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients, for<br /> providing the three custom packages, and for providing <br /> the ldap server CA certificate. The RPMS are expected to<br /> be in /conf, and the CA certificate is expected to be in<br /> conf/certs.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time to make client configuration customizations.<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - The fully qualified domain name of the client<br /> &lt;li&gt;se_krbpass - Password for the root/admin kerberos principal.<br /> &lt;li&gt;se_server - FQDN of the server component. Defaults to seserver.$dnsdomain<br /> &lt;/ul&gt;<br /> <br /> = Using the Environment = <br /> <br /> After the installation is complete the following accounts are available:<br /> <br /> * Server<br /> ** root - sefos1<br /> ** Kerberos Database (required to add slave KDCs)<br /> *** kdbpass<br /> ** Kerberos root/admin principal<br /> *** say#fos#<br /> * Client<br /> ** root - sefos1<br /> ** newuser - newuser1<br /> <br /> Passwords should be changed from the defaults after completing installation, especially if the clients or servers are reachable from the Internet.<br /> <br /> Using the '''newuser''' account you should now be able to login on the client using GDM or on a virtual console.<br /> <br /> = Troubleshooting (in progress)=<br /> <br /> Additional information that may be useful for troubleshooting is available in the manual installation guide with the appropriate service.<br /> <br /> * If the newuser account does not work on the client:<br /> ** Switch to a virtual console (ctrl-alt-f1) and login as root<br /> ** Verify that Kerberos was successfully configured:<br /> *** Use &lt;code&gt;klist -k /etc/krb5.keytab&lt;/code&gt;.<br /> *** If the keytab does not exist there was an error that prevented kadmin from creating the host and nfs principals during installation. Otherwise the output should show four keys for the host (i.e. host/client.example.com) and one for nfs (i.e. nfs/client.example.com). This is likely either a password mismatch issue or a time synchronization issue. <br /> *** Verify the client and server times are similar using '''date'''. <br /> **** If not, use &lt;code&gt; run_init service ntpd stop&lt;/code&gt; to turn of ntpd, then use &lt;code&gt;ntpdate -b -x 0.fedora.pool.ntp.org&lt;/code&gt; to sync time with the external time server. Use &lt;code&gt;run_init service ntpd start&lt;/code&gt; to start ntpd.<br /> **** If the external time server is unreachable, or an internal time source is preferred, reconfigure ntpd to use the desired time source and use that host instead of 0.fedora.pool.ntp.org in the ntpdate command.<br /> **** Manually synchronize both the client and server to ensure they are correct. <br /> *** Once syncronized time has been verified or established, follow the steps in the [[Labeled_NFS/Demo/Manual/Kerberos| Kerberos configuration guide]] to create the host and nfs principals, and store them locally in a keytab.<br /> ** Verify that LDAP was successfully configured:<br /> *** Examine /var/log/messages for LDAP related errors<br /> *** During testing we encountered errors where the client was unable to connect to the LDAP server. The errors were related to forgetting to copy the CA certificate into the appropriate area of the web server, forgetting to update the certificate if we built a new server, or having Apache serve an older certificate that was cached.<br /> *** Use scp to copy the CA certificate from the server to the client: &lt;code&gt; scp seserver:/etc/openldap/cacerts/cacert.pem /etc/openldap/cacerts/&lt;/code&gt;<br /> ** Verify that three SELinux booleans were correctly set on the client.<br /> *** Run &lt;code&gt;getsebool allow_kerberos allow_gssd_read_tmp use_nfs_home_dirs&lt;/code&gt; and verify the values are all set as '''on'''<br /> ** Verify that NFSv4 mounts work properly.<br /> *** Run &lt;code&gt;kinit -p root/admin&lt;/code&gt; to initialize your Kerberos credentials.<br /> *** Run &lt;code&gt;mount -v -t nfs4 -o sec=krb5,security_label seserver:/home /mnt&lt;/code&gt; to mount /mnt/home from the server.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Kickstart Labeled NFS/Demo/Kickstart 2008-12-15T15:43:50Z <p>CraigGrube: /* Packages */</p> <hr /> <div>This page details the steps required to setup the SEFOS NFSv4 client and<br /> server, including some optional steps to provide basic network services<br /> and a build server. <br /> <br /> The services provided<br /> by the build server can be mixed and matched as needed to supplement existing<br /> network services to provide the <br /> basic functionality required to successfully build a client or server from <br /> a kickstart.<br /> <br /> The binary RPM packages required for the Labeled NFS to work properly were compiled<br /> for Fedora Core 9 systems. Source RPMs are available for compiling your own packages.<br /> <br /> = Boot Server Configuration (Optional) =<br /> The sample configurations assume a local network using the 192.168.201.0/24 <br /> address block. Network ranges/addresses should be modified to match<br /> those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration <br /> examples and in the demo environment. The domain may be modified to match<br /> an existing domain. Changes to the kickstarts will be required to set the<br /> new default domain and to change the creation of the ldap structure if the<br /> domain name is increased beyond two levels.<br /> <br /> <br /> == Installing packages ==<br /> <br /> The YUM package tool is used to install packages. This requires a<br /> connection to the Internet to connect to remote package repositories, or<br /> a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated<br /> packages.<br /> <br /> == Setting up the DHCP server ==<br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The<br /> example provided is one that is being used in a VMware environment.<br /> <br /> [excerpt from sample /etc/dhcpd.conf]<br /> &lt;pre&gt;<br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host seserver {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;seserver.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it<br /> might be useful to generate that portion of the DHCPD config file from a<br /> flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the DNS Server ==<br /> packages: named<br /> <br /> The default configuration will only listen on the localhost address. You will <br /> need to set the listen-on and allow-query addresses in the options section<br /> of /etc/named.conf so that named can respond to queries on the local network.<br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> Add forward and reverse zones for the address range in use:<br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> seserver A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client2 A 192.168.201.51<br /> client3 A 192.168.201.52<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR seserver.example.com.<br /> <br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> 52 IN PTR client3.example.com.<br /> &lt;/pre&gt;<br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named start<br /> &lt;/pre&gt;<br /> <br /> == Setting up the Web server ==<br /> packages: httpd<br /> <br /> Download the latest versions of the kickstart files and binary RPMs as identified on the main[[Labeled_NFS/Demo|Labeled NFS Demo]] page.<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Client Kickstart<br /> &lt;li&gt;Server Kickstart<br /> &lt;li&gt;Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;NFS Utils with Labeled NFS patches<br /> &lt;li&gt;SELinux policy for labeled NFS server<br /> &lt;li&gt;SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Create a directory to hold the kickstart files [/var/www/html/kickstart/]. Copy the client and server kickstart files into this directory.<br /> <br /> Create directories to hold the RPMs and eventually the server CA public certificate [/var/www/html/conf for packages, and /var/www/html/certs for the certificate]. Copy the Kernel, NFS Utils and SEFOS SELinux policies into /var/www/html/conf.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> Source and binary RPM packages are available at http://www.selinuxnow.org/sefos/packages/<br /> <br /> = Kickstart Customization and System Installation =<br /> <br /> Documentation at the beginning of the kickstart files details some boot time<br /> options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> &lt;ul&gt;<br /> &lt;li&gt;Depending on the network environment the kickstart can be configured to use<br /> DHCP for address provisioning or static addressing. The default is to use<br /> DHCP, however a sample static address configuration is included for reference.<br /> If addresses are assigned statically, the kickstarts will need to be modified<br /> for each client/server installation (to provide the appropriate address).<br /> &lt;li&gt; If installing FC9 from CD/DVD access to an up-to-date FC9 repository (via<br /> external network connection or local mirror) is required as some packages required<br /> for the installs are not included in the CD/DVD install media.<br /> &lt;li&gt;Additional customization of the ldap/kerberos/nfs installation can be <br /> performed in the %post section. <br /> &lt;li&gt;Installs are currently interactive. To convert the kickstarts to a fully automated<br /> install comment out the &quot;interactive&quot; directive at the beginning of the files.<br /> &lt;li&gt;Kerberos requires that client and server system times be synchronized to function<br /> properly. The install does not customize the default FC9 NTP configuration, though it <br /> does attempt to synchronize the system time following reboot against a fedora time server <br /> (0.fedora.pool.ntp.org).<br /> &lt;/ul&gt;<br /> <br /> == Server Kickstart == <br /> <br /> === Introduction ===<br /> The kickstart installs and configures the<br /> server portion of the Labeled NFS Demo environment.<br /> It includes many components that would be used in an<br /> enterprise to provide authentication and authorization<br /> services as well as directory and file sharing services.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are identified on the main demo page.<br /> * Linux kernel with Labeled NFS patches<br /> * NFS-Utils with Labeled NFS patches<br /> * SEFOS Server SELinux policy<br /> <br /> ==== DNS ====<br /> <br /> For Kerberos to function properly, forward and reverse resolution is required for all clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients and for<br /> providing the three custom packages for client <br /> installation.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time for customizing the installation:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - Server's fully qualified domain name.<br /> &lt;li&gt;se_krbpass - Kerberos password for root/admin principal.<br /> &lt;li&gt;se_kdbpass - Kerberos database password.<br /> &lt;li&gt;se_ldappass - LDAP administrator password<br /> &lt;li&gt;se_www - DNS name of web server hosting packages/config (default is www.example.com)<br /> &lt;/ul&gt;<br /> If customizing the LDAP certificate the following options can be used to override the defaults:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_certPW - Certificate Authority certificate password<br /> &lt;li&gt;se_certCountry <br /> &lt;li&gt;se_certState<br /> &lt;li&gt;se_certCity<br /> &lt;li&gt;se_certOrg<br /> &lt;li&gt;se_certEmail<br /> &lt;li&gt;se_certCN<br /> &lt;/ul&gt;<br /> <br /> === Assumptions ===<br /> ==== Kerberos Realm ====<br /> The server DNS name is used to generate the <br /> kerberos realm name and the ldap structure. The domain<br /> of the client and server are currently expected to contain<br /> two levels (i.e. DNS: example.com -&gt; LDAP: dc=example,dc=com -&gt; Kerberos: EXAMPLE.COM).<br /> <br /> ==== Packages ==== <br /> Packages are expected to be in a directory called<br /> conf off of the web server root directory (i.e. http://www.example.com/conf) <br /> <br /> ==== Time Zone ==== <br /> The current default time zone is Pacific. Change as desired.<br /> <br /> === Post Install === <br /> <br /> The client kickstart requires the LDAP<br /> CA certificate during installation time to for proper <br /> configuration. <br /> <br /> &lt;b&gt;The certificate (/etc/openldap/cacerts/cacert.pem)<br /> should be copied into conf/certs/cacert.pem on the web<br /> server.&lt;/b&gt;<br /> <br /> == Client Kickstart ==<br /> <br /> === Introduction ===<br /> This kickstart installs and configures the<br /> client portion of the Labeled NFS Demo.<br /> After a successfully client build, the client will be <br /> a fairly minimimal Fedora installation configured with<br /> GDM and GNOME. The client will be<br /> integrated with the authentication/authorization/directory<br /> services provided by the server component, and user <br /> home directories will be mounted via NFS.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> <br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-client-policy-0.1-1.fc9.i386.rpm <br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> The kerberos configuration requires an external<br /> DNS service that supports forward and reverse resolution<br /> for the clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients, for<br /> providing the three custom packages, and for providing <br /> the ldap server CA certificate. The RPMS are expected to<br /> be in /conf, and the CA certificate is expected to be in<br /> conf/certs.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time to make client configuration customizations.<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - The fully qualified domain name of the client<br /> &lt;li&gt;se_krbpass - Password for the root/admin kerberos principal.<br /> &lt;li&gt;se_server - FQDN of the server component. Defaults to seserver.example.com.<br /> &lt;/ul&gt;<br /> <br /> = Using the Environment = <br /> <br /> After the installation is complete the following accounts are available:<br /> <br /> * Server<br /> ** root - sefos1<br /> ** Kerberos Database (required to add slave KDCs)<br /> *** kdbpass<br /> ** Kerberos root/admin principal<br /> *** say#fos#<br /> * Client<br /> ** root - sefos1<br /> ** newuser - newuser1<br /> <br /> Passwords should be changed from the defaults after completing installation, especially if the clients or servers are reachable from the Internet.<br /> <br /> Using the '''newuser''' account you should now be able to login on the client using GDM or on a virtual console.<br /> <br /> = Troubleshooting (in progress)=<br /> <br /> Additional information that may be useful for troubleshooting is available in the manual installation guide with the appropriate service.<br /> <br /> * If the newuser account does not work on the client:<br /> ** Switch to a virtual console (ctrl-alt-f1) and login as root<br /> ** Verify that Kerberos was successfully configured:<br /> *** Use &lt;code&gt;klist -k /etc/krb5.keytab&lt;/code&gt;.<br /> *** If the keytab does not exist there was an error that prevented kadmin from creating the host and nfs principals during installation. Otherwise the output should show four keys for the host (i.e. host/client.example.com) and one for nfs (i.e. nfs/client.example.com). This is likely either a password mismatch issue or a time synchronization issue. <br /> *** Verify the client and server times are similar using '''date'''. <br /> **** If not, use &lt;code&gt; run_init service ntpd stop&lt;/code&gt; to turn of ntpd, then use &lt;code&gt;ntpdate -b -x 0.fedora.pool.ntp.org&lt;/code&gt; to sync time with the external time server. Use &lt;code&gt;run_init service ntpd start&lt;/code&gt; to start ntpd.<br /> **** If the external time server is unreachable, or an internal time source is preferred, reconfigure ntpd to use the desired time source and use that host instead of 0.fedora.pool.ntp.org in the ntpdate command.<br /> **** Manually synchronize both the client and server to ensure they are correct. <br /> *** Once syncronized time has been verified or established, follow the steps in the [[Labeled_NFS/Demo/Manual/Kerberos| Kerberos configuration guide]] to create the host and nfs principals, and store them locally in a keytab.<br /> ** Verify that LDAP was successfully configured:<br /> *** Examine /var/log/messages for LDAP related errors<br /> *** During testing we encountered errors where the client was unable to connect to the LDAP server. The errors were related to forgetting to copy the CA certificate into the appropriate area of the web server, forgetting to update the certificate if we built a new server, or having Apache serve an older certificate that was cached.<br /> *** Use scp to copy the CA certificate from the server to the client: &lt;code&gt; scp seserver:/etc/openldap/cacerts/cacert.pem /etc/openldap/cacerts/&lt;/code&gt;<br /> ** Verify that three SELinux booleans were correctly set on the client.<br /> *** Run &lt;code&gt;getsebool allow_kerberos allow_gssd_read_tmp use_nfs_home_dirs&lt;/code&gt; and verify the values are all set as '''on'''<br /> ** Verify that NFSv4 mounts work properly.<br /> *** Run &lt;code&gt;kinit -p root/admin&lt;/code&gt; to initialize your Kerberos credentials.<br /> *** Run &lt;code&gt;mount -v -t nfs4 -o sec=krb5,security_label seserver:/home /mnt&lt;/code&gt; to mount /mnt/home from the server.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Kickstart Labeled NFS/Demo/Kickstart 2008-12-15T15:43:18Z <p>CraigGrube: /* Packages */</p> <hr /> <div>This page details the steps required to setup the SEFOS NFSv4 client and<br /> server, including some optional steps to provide basic network services<br /> and a build server. <br /> <br /> The services provided<br /> by the build server can be mixed and matched as needed to supplement existing<br /> network services to provide the <br /> basic functionality required to successfully build a client or server from <br /> a kickstart.<br /> <br /> The binary RPM packages required for the Labeled NFS to work properly were compiled<br /> for Fedora Core 9 systems. Source RPMs are available for compiling your own packages.<br /> <br /> = Boot Server Configuration (Optional) =<br /> The sample configurations assume a local network using the 192.168.201.0/24 <br /> address block. Network ranges/addresses should be modified to match<br /> those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration <br /> examples and in the demo environment. The domain may be modified to match<br /> an existing domain. Changes to the kickstarts will be required to set the<br /> new default domain and to change the creation of the ldap structure if the<br /> domain name is increased beyond two levels.<br /> <br /> <br /> == Installing packages ==<br /> <br /> The YUM package tool is used to install packages. This requires a<br /> connection to the Internet to connect to remote package repositories, or<br /> a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated<br /> packages.<br /> <br /> == Setting up the DHCP server ==<br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The<br /> example provided is one that is being used in a VMware environment.<br /> <br /> [excerpt from sample /etc/dhcpd.conf]<br /> &lt;pre&gt;<br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host seserver {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;seserver.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it<br /> might be useful to generate that portion of the DHCPD config file from a<br /> flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the DNS Server ==<br /> packages: named<br /> <br /> The default configuration will only listen on the localhost address. You will <br /> need to set the listen-on and allow-query addresses in the options section<br /> of /etc/named.conf so that named can respond to queries on the local network.<br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> Add forward and reverse zones for the address range in use:<br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> seserver A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client2 A 192.168.201.51<br /> client3 A 192.168.201.52<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR seserver.example.com.<br /> <br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> 52 IN PTR client3.example.com.<br /> &lt;/pre&gt;<br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named start<br /> &lt;/pre&gt;<br /> <br /> == Setting up the Web server ==<br /> packages: httpd<br /> <br /> Download the latest versions of the kickstart files and binary RPMs as identified on the main[[Labeled_NFS/Demo|Labeled NFS Demo]] page.<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Client Kickstart<br /> &lt;li&gt;Server Kickstart<br /> &lt;li&gt;Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;NFS Utils with Labeled NFS patches<br /> &lt;li&gt;SELinux policy for labeled NFS server<br /> &lt;li&gt;SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Create a directory to hold the kickstart files [/var/www/html/kickstart/]. Copy the client and server kickstart files into this directory.<br /> <br /> Create directories to hold the RPMs and eventually the server CA public certificate [/var/www/html/conf for packages, and /var/www/html/certs for the certificate]. Copy the Kernel, NFS Utils and SEFOS SELinux policies into /var/www/html/conf.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> Source and binary RPM packages are available at http://www.selinuxnow.org/sefos/packages/<br /> <br /> = Kickstart Customization and System Installation =<br /> <br /> Documentation at the beginning of the kickstart files details some boot time<br /> options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> &lt;ul&gt;<br /> &lt;li&gt;Depending on the network environment the kickstart can be configured to use<br /> DHCP for address provisioning or static addressing. The default is to use<br /> DHCP, however a sample static address configuration is included for reference.<br /> If addresses are assigned statically, the kickstarts will need to be modified<br /> for each client/server installation (to provide the appropriate address).<br /> &lt;li&gt; If installing FC9 from CD/DVD access to an up-to-date FC9 repository (via<br /> external network connection or local mirror) is required as some packages required<br /> for the installs are not included in the CD/DVD install media.<br /> &lt;li&gt;Additional customization of the ldap/kerberos/nfs installation can be <br /> performed in the %post section. <br /> &lt;li&gt;Installs are currently interactive. To convert the kickstarts to a fully automated<br /> install comment out the &quot;interactive&quot; directive at the beginning of the files.<br /> &lt;li&gt;Kerberos requires that client and server system times be synchronized to function<br /> properly. The install does not customize the default FC9 NTP configuration, though it <br /> does attempt to synchronize the system time following reboot against a fedora time server <br /> (0.fedora.pool.ntp.org).<br /> &lt;/ul&gt;<br /> <br /> == Server Kickstart == <br /> <br /> === Introduction ===<br /> The kickstart installs and configures the<br /> server portion of the Labeled NFS Demo environment.<br /> It includes many components that would be used in an<br /> enterprise to provide authentication and authorization<br /> services as well as directory and file sharing services.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are identified on the main demo page.<br /> &lt;pre&gt;<br /> Linux kernel with Labeled NFS patches<br /> NFS-Utils with Labeled NFS patches<br /> SEFOS Server SELinux policy<br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> <br /> For Kerberos to function properly, forward and reverse resolution is required for all clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients and for<br /> providing the three custom packages for client <br /> installation.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time for customizing the installation:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - Server's fully qualified domain name.<br /> &lt;li&gt;se_krbpass - Kerberos password for root/admin principal.<br /> &lt;li&gt;se_kdbpass - Kerberos database password.<br /> &lt;li&gt;se_ldappass - LDAP administrator password<br /> &lt;li&gt;se_www - DNS name of web server hosting packages/config (default is www.example.com)<br /> &lt;/ul&gt;<br /> If customizing the LDAP certificate the following options can be used to override the defaults:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_certPW - Certificate Authority certificate password<br /> &lt;li&gt;se_certCountry <br /> &lt;li&gt;se_certState<br /> &lt;li&gt;se_certCity<br /> &lt;li&gt;se_certOrg<br /> &lt;li&gt;se_certEmail<br /> &lt;li&gt;se_certCN<br /> &lt;/ul&gt;<br /> <br /> === Assumptions ===<br /> ==== Kerberos Realm ====<br /> The server DNS name is used to generate the <br /> kerberos realm name and the ldap structure. The domain<br /> of the client and server are currently expected to contain<br /> two levels (i.e. DNS: example.com -&gt; LDAP: dc=example,dc=com -&gt; Kerberos: EXAMPLE.COM).<br /> <br /> ==== Packages ==== <br /> Packages are expected to be in a directory called<br /> conf off of the web server root directory (i.e. http://www.example.com/conf) <br /> <br /> ==== Time Zone ==== <br /> The current default time zone is Pacific. Change as desired.<br /> <br /> === Post Install === <br /> <br /> The client kickstart requires the LDAP<br /> CA certificate during installation time to for proper <br /> configuration. <br /> <br /> &lt;b&gt;The certificate (/etc/openldap/cacerts/cacert.pem)<br /> should be copied into conf/certs/cacert.pem on the web<br /> server.&lt;/b&gt;<br /> <br /> == Client Kickstart ==<br /> <br /> === Introduction ===<br /> This kickstart installs and configures the<br /> client portion of the Labeled NFS Demo.<br /> After a successfully client build, the client will be <br /> a fairly minimimal Fedora installation configured with<br /> GDM and GNOME. The client will be<br /> integrated with the authentication/authorization/directory<br /> services provided by the server component, and user <br /> home directories will be mounted via NFS.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> <br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-client-policy-0.1-1.fc9.i386.rpm <br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> The kerberos configuration requires an external<br /> DNS service that supports forward and reverse resolution<br /> for the clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients, for<br /> providing the three custom packages, and for providing <br /> the ldap server CA certificate. The RPMS are expected to<br /> be in /conf, and the CA certificate is expected to be in<br /> conf/certs.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time to make client configuration customizations.<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - The fully qualified domain name of the client<br /> &lt;li&gt;se_krbpass - Password for the root/admin kerberos principal.<br /> &lt;li&gt;se_server - FQDN of the server component. Defaults to seserver.example.com.<br /> &lt;/ul&gt;<br /> <br /> = Using the Environment = <br /> <br /> After the installation is complete the following accounts are available:<br /> <br /> * Server<br /> ** root - sefos1<br /> ** Kerberos Database (required to add slave KDCs)<br /> *** kdbpass<br /> ** Kerberos root/admin principal<br /> *** say#fos#<br /> * Client<br /> ** root - sefos1<br /> ** newuser - newuser1<br /> <br /> Passwords should be changed from the defaults after completing installation, especially if the clients or servers are reachable from the Internet.<br /> <br /> Using the '''newuser''' account you should now be able to login on the client using GDM or on a virtual console.<br /> <br /> = Troubleshooting (in progress)=<br /> <br /> Additional information that may be useful for troubleshooting is available in the manual installation guide with the appropriate service.<br /> <br /> * If the newuser account does not work on the client:<br /> ** Switch to a virtual console (ctrl-alt-f1) and login as root<br /> ** Verify that Kerberos was successfully configured:<br /> *** Use &lt;code&gt;klist -k /etc/krb5.keytab&lt;/code&gt;.<br /> *** If the keytab does not exist there was an error that prevented kadmin from creating the host and nfs principals during installation. Otherwise the output should show four keys for the host (i.e. host/client.example.com) and one for nfs (i.e. nfs/client.example.com). This is likely either a password mismatch issue or a time synchronization issue. <br /> *** Verify the client and server times are similar using '''date'''. <br /> **** If not, use &lt;code&gt; run_init service ntpd stop&lt;/code&gt; to turn of ntpd, then use &lt;code&gt;ntpdate -b -x 0.fedora.pool.ntp.org&lt;/code&gt; to sync time with the external time server. Use &lt;code&gt;run_init service ntpd start&lt;/code&gt; to start ntpd.<br /> **** If the external time server is unreachable, or an internal time source is preferred, reconfigure ntpd to use the desired time source and use that host instead of 0.fedora.pool.ntp.org in the ntpdate command.<br /> **** Manually synchronize both the client and server to ensure they are correct. <br /> *** Once syncronized time has been verified or established, follow the steps in the [[Labeled_NFS/Demo/Manual/Kerberos| Kerberos configuration guide]] to create the host and nfs principals, and store them locally in a keytab.<br /> ** Verify that LDAP was successfully configured:<br /> *** Examine /var/log/messages for LDAP related errors<br /> *** During testing we encountered errors where the client was unable to connect to the LDAP server. The errors were related to forgetting to copy the CA certificate into the appropriate area of the web server, forgetting to update the certificate if we built a new server, or having Apache serve an older certificate that was cached.<br /> *** Use scp to copy the CA certificate from the server to the client: &lt;code&gt; scp seserver:/etc/openldap/cacerts/cacert.pem /etc/openldap/cacerts/&lt;/code&gt;<br /> ** Verify that three SELinux booleans were correctly set on the client.<br /> *** Run &lt;code&gt;getsebool allow_kerberos allow_gssd_read_tmp use_nfs_home_dirs&lt;/code&gt; and verify the values are all set as '''on'''<br /> ** Verify that NFSv4 mounts work properly.<br /> *** Run &lt;code&gt;kinit -p root/admin&lt;/code&gt; to initialize your Kerberos credentials.<br /> *** Run &lt;code&gt;mount -v -t nfs4 -o sec=krb5,security_label seserver:/home /mnt&lt;/code&gt; to mount /mnt/home from the server.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Kickstart Labeled NFS/Demo/Kickstart 2008-12-15T15:41:47Z <p>CraigGrube: /* Setting up the Web server */</p> <hr /> <div>This page details the steps required to setup the SEFOS NFSv4 client and<br /> server, including some optional steps to provide basic network services<br /> and a build server. <br /> <br /> The services provided<br /> by the build server can be mixed and matched as needed to supplement existing<br /> network services to provide the <br /> basic functionality required to successfully build a client or server from <br /> a kickstart.<br /> <br /> The binary RPM packages required for the Labeled NFS to work properly were compiled<br /> for Fedora Core 9 systems. Source RPMs are available for compiling your own packages.<br /> <br /> = Boot Server Configuration (Optional) =<br /> The sample configurations assume a local network using the 192.168.201.0/24 <br /> address block. Network ranges/addresses should be modified to match<br /> those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration <br /> examples and in the demo environment. The domain may be modified to match<br /> an existing domain. Changes to the kickstarts will be required to set the<br /> new default domain and to change the creation of the ldap structure if the<br /> domain name is increased beyond two levels.<br /> <br /> <br /> == Installing packages ==<br /> <br /> The YUM package tool is used to install packages. This requires a<br /> connection to the Internet to connect to remote package repositories, or<br /> a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated<br /> packages.<br /> <br /> == Setting up the DHCP server ==<br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The<br /> example provided is one that is being used in a VMware environment.<br /> <br /> [excerpt from sample /etc/dhcpd.conf]<br /> &lt;pre&gt;<br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host seserver {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;seserver.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it<br /> might be useful to generate that portion of the DHCPD config file from a<br /> flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the DNS Server ==<br /> packages: named<br /> <br /> The default configuration will only listen on the localhost address. You will <br /> need to set the listen-on and allow-query addresses in the options section<br /> of /etc/named.conf so that named can respond to queries on the local network.<br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> Add forward and reverse zones for the address range in use:<br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> seserver A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client2 A 192.168.201.51<br /> client3 A 192.168.201.52<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR seserver.example.com.<br /> <br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> 52 IN PTR client3.example.com.<br /> &lt;/pre&gt;<br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named start<br /> &lt;/pre&gt;<br /> <br /> == Setting up the Web server ==<br /> packages: httpd<br /> <br /> Download the latest versions of the kickstart files and binary RPMs as identified on the main[[Labeled_NFS/Demo|Labeled NFS Demo]] page.<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Client Kickstart<br /> &lt;li&gt;Server Kickstart<br /> &lt;li&gt;Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;NFS Utils with Labeled NFS patches<br /> &lt;li&gt;SELinux policy for labeled NFS server<br /> &lt;li&gt;SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Create a directory to hold the kickstart files [/var/www/html/kickstart/]. Copy the client and server kickstart files into this directory.<br /> <br /> Create directories to hold the RPMs and eventually the server CA public certificate [/var/www/html/conf for packages, and /var/www/html/certs for the certificate]. Copy the Kernel, NFS Utils and SEFOS SELinux policies into /var/www/html/conf.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> Source and binary RPM packages are available at http://www.selinuxnow.org/sefos/packages/<br /> <br /> = Kickstart Customization and System Installation =<br /> <br /> Documentation at the beginning of the kickstart files details some boot time<br /> options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> &lt;ul&gt;<br /> &lt;li&gt;Depending on the network environment the kickstart can be configured to use<br /> DHCP for address provisioning or static addressing. The default is to use<br /> DHCP, however a sample static address configuration is included for reference.<br /> If addresses are assigned statically, the kickstarts will need to be modified<br /> for each client/server installation (to provide the appropriate address).<br /> &lt;li&gt; If installing FC9 from CD/DVD access to an up-to-date FC9 repository (via<br /> external network connection or local mirror) is required as some packages required<br /> for the installs are not included in the CD/DVD install media.<br /> &lt;li&gt;Additional customization of the ldap/kerberos/nfs installation can be <br /> performed in the %post section. <br /> &lt;li&gt;Installs are currently interactive. To convert the kickstarts to a fully automated<br /> install comment out the &quot;interactive&quot; directive at the beginning of the files.<br /> &lt;li&gt;Kerberos requires that client and server system times be synchronized to function<br /> properly. The install does not customize the default FC9 NTP configuration, though it <br /> does attempt to synchronize the system time following reboot against a fedora time server <br /> (0.fedora.pool.ntp.org).<br /> &lt;/ul&gt;<br /> <br /> == Server Kickstart == <br /> <br /> === Introduction ===<br /> The kickstart installs and configures the<br /> server portion of the Labeled NFS Demo environment.<br /> It includes many components that would be used in an<br /> enterprise to provide authentication and authorization<br /> services as well as directory and file sharing services.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-server-policy-0.2-1.fc9.i386.rpm<br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> <br /> For Kerberos to function properly, forward and reverse resolution is required for all clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients and for<br /> providing the three custom packages for client <br /> installation.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time for customizing the installation:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - Server's fully qualified domain name.<br /> &lt;li&gt;se_krbpass - Kerberos password for root/admin principal.<br /> &lt;li&gt;se_kdbpass - Kerberos database password.<br /> &lt;li&gt;se_ldappass - LDAP administrator password<br /> &lt;li&gt;se_www - DNS name of web server hosting packages/config (default is www.example.com)<br /> &lt;/ul&gt;<br /> If customizing the LDAP certificate the following options can be used to override the defaults:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_certPW - Certificate Authority certificate password<br /> &lt;li&gt;se_certCountry <br /> &lt;li&gt;se_certState<br /> &lt;li&gt;se_certCity<br /> &lt;li&gt;se_certOrg<br /> &lt;li&gt;se_certEmail<br /> &lt;li&gt;se_certCN<br /> &lt;/ul&gt;<br /> <br /> === Assumptions ===<br /> ==== Kerberos Realm ====<br /> The server DNS name is used to generate the <br /> kerberos realm name and the ldap structure. The domain<br /> of the client and server are currently expected to contain<br /> two levels (i.e. DNS: example.com -&gt; LDAP: dc=example,dc=com -&gt; Kerberos: EXAMPLE.COM).<br /> <br /> ==== Packages ==== <br /> Packages are expected to be in a directory called<br /> conf off of the web server root directory (i.e. http://www.example.com/conf) <br /> <br /> ==== Time Zone ==== <br /> The current default time zone is Pacific. Change as desired.<br /> <br /> === Post Install === <br /> <br /> The client kickstart requires the LDAP<br /> CA certificate during installation time to for proper <br /> configuration. <br /> <br /> &lt;b&gt;The certificate (/etc/openldap/cacerts/cacert.pem)<br /> should be copied into conf/certs/cacert.pem on the web<br /> server.&lt;/b&gt;<br /> <br /> == Client Kickstart ==<br /> <br /> === Introduction ===<br /> This kickstart installs and configures the<br /> client portion of the Labeled NFS Demo.<br /> After a successfully client build, the client will be <br /> a fairly minimimal Fedora installation configured with<br /> GDM and GNOME. The client will be<br /> integrated with the authentication/authorization/directory<br /> services provided by the server component, and user <br /> home directories will be mounted via NFS.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> <br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-client-policy-0.1-1.fc9.i386.rpm <br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> The kerberos configuration requires an external<br /> DNS service that supports forward and reverse resolution<br /> for the clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients, for<br /> providing the three custom packages, and for providing <br /> the ldap server CA certificate. The RPMS are expected to<br /> be in /conf, and the CA certificate is expected to be in<br /> conf/certs.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time to make client configuration customizations.<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - The fully qualified domain name of the client<br /> &lt;li&gt;se_krbpass - Password for the root/admin kerberos principal.<br /> &lt;li&gt;se_server - FQDN of the server component. Defaults to seserver.example.com.<br /> &lt;/ul&gt;<br /> <br /> = Using the Environment = <br /> <br /> After the installation is complete the following accounts are available:<br /> <br /> * Server<br /> ** root - sefos1<br /> ** Kerberos Database (required to add slave KDCs)<br /> *** kdbpass<br /> ** Kerberos root/admin principal<br /> *** say#fos#<br /> * Client<br /> ** root - sefos1<br /> ** newuser - newuser1<br /> <br /> Passwords should be changed from the defaults after completing installation, especially if the clients or servers are reachable from the Internet.<br /> <br /> Using the '''newuser''' account you should now be able to login on the client using GDM or on a virtual console.<br /> <br /> = Troubleshooting (in progress)=<br /> <br /> Additional information that may be useful for troubleshooting is available in the manual installation guide with the appropriate service.<br /> <br /> * If the newuser account does not work on the client:<br /> ** Switch to a virtual console (ctrl-alt-f1) and login as root<br /> ** Verify that Kerberos was successfully configured:<br /> *** Use &lt;code&gt;klist -k /etc/krb5.keytab&lt;/code&gt;.<br /> *** If the keytab does not exist there was an error that prevented kadmin from creating the host and nfs principals during installation. Otherwise the output should show four keys for the host (i.e. host/client.example.com) and one for nfs (i.e. nfs/client.example.com). This is likely either a password mismatch issue or a time synchronization issue. <br /> *** Verify the client and server times are similar using '''date'''. <br /> **** If not, use &lt;code&gt; run_init service ntpd stop&lt;/code&gt; to turn of ntpd, then use &lt;code&gt;ntpdate -b -x 0.fedora.pool.ntp.org&lt;/code&gt; to sync time with the external time server. Use &lt;code&gt;run_init service ntpd start&lt;/code&gt; to start ntpd.<br /> **** If the external time server is unreachable, or an internal time source is preferred, reconfigure ntpd to use the desired time source and use that host instead of 0.fedora.pool.ntp.org in the ntpdate command.<br /> **** Manually synchronize both the client and server to ensure they are correct. <br /> *** Once syncronized time has been verified or established, follow the steps in the [[Labeled_NFS/Demo/Manual/Kerberos| Kerberos configuration guide]] to create the host and nfs principals, and store them locally in a keytab.<br /> ** Verify that LDAP was successfully configured:<br /> *** Examine /var/log/messages for LDAP related errors<br /> *** During testing we encountered errors where the client was unable to connect to the LDAP server. The errors were related to forgetting to copy the CA certificate into the appropriate area of the web server, forgetting to update the certificate if we built a new server, or having Apache serve an older certificate that was cached.<br /> *** Use scp to copy the CA certificate from the server to the client: &lt;code&gt; scp seserver:/etc/openldap/cacerts/cacert.pem /etc/openldap/cacerts/&lt;/code&gt;<br /> ** Verify that three SELinux booleans were correctly set on the client.<br /> *** Run &lt;code&gt;getsebool allow_kerberos allow_gssd_read_tmp use_nfs_home_dirs&lt;/code&gt; and verify the values are all set as '''on'''<br /> ** Verify that NFSv4 mounts work properly.<br /> *** Run &lt;code&gt;kinit -p root/admin&lt;/code&gt; to initialize your Kerberos credentials.<br /> *** Run &lt;code&gt;mount -v -t nfs4 -o sec=krb5,security_label seserver:/home /mnt&lt;/code&gt; to mount /mnt/home from the server.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-15T15:38:15Z <p>CraigGrube: /* Packages */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service provides files that are accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home/ directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users can login from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a directory service. It is a simple database that is<br /> network accessible. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures. <br /> <br /> The most recent versions of the packages binary packages and kickstart files are:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc3-5.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Source RPMs and older binary packages are available at the same location: http://www.selinuxnow.org/sefos/packages</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Kickstart Labeled NFS/Demo/Kickstart 2008-12-12T19:41:28Z <p>CraigGrube: /* Boot Options */</p> <hr /> <div>This page details the steps required to setup the SEFOS NFSv4 client and<br /> server, including some optional steps to provide basic network services<br /> and a build server. <br /> <br /> The services provided<br /> by the build server can be mixed and matched as needed to supplement existing<br /> network services to provide the <br /> basic functionality required to successfully build a client or server from <br /> a kickstart.<br /> <br /> The binary RPM packages required for the Labeled NFS to work properly were compiled<br /> for Fedora Core 9 systems. Source RPMs are available for compiling your own packages.<br /> <br /> = Boot Server Configuration (Optional) =<br /> The sample configurations assume a local network using the 192.168.201.0/24 <br /> address block. Network ranges/addresses should be modified to match<br /> those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration <br /> examples and in the demo environment. The domain may be modified to match<br /> an existing domain. Changes to the kickstarts will be required to set the<br /> new default domain and to change the creation of the ldap structure if the<br /> domain name is increased beyond two levels.<br /> <br /> <br /> == Installing packages ==<br /> <br /> The YUM package tool is used to install packages. This requires a<br /> connection to the Internet to connect to remote package repositories, or<br /> a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated<br /> packages.<br /> <br /> == Setting up the DHCP server ==<br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The<br /> example provided is one that is being used in a VMware environment.<br /> <br /> [excerpt from sample /etc/dhcpd.conf]<br /> &lt;pre&gt;<br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host seserver {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;seserver.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it<br /> might be useful to generate that portion of the DHCPD config file from a<br /> flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the DNS Server ==<br /> packages: named<br /> <br /> The default configuration will only listen on the localhost address. You will <br /> need to set the listen-on and allow-query addresses in the options section<br /> of /etc/named.conf so that named can respond to queries on the local network.<br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> Add forward and reverse zones for the address range in use:<br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> seserver A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client2 A 192.168.201.51<br /> client3 A 192.168.201.52<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR seserver.example.com.<br /> <br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> 52 IN PTR client3.example.com.<br /> &lt;/pre&gt;<br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named start<br /> &lt;/pre&gt;<br /> <br /> == Setting up the Web server ==<br /> packages: httpd<br /> <br /> Download the following kickstart files and binary RPMs:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc3-5.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Create a directory to hold the kickstart files [/var/www/html/kickstart/]. Copy the client and server kickstart files into this directory.<br /> <br /> Create directories to hold the RPMs and eventually the server CA public certificate [/var/www/html/conf for packages, and /var/www/html/certs for the certificate]. Copy the Kernel, NFS Utils and SEFOS SELinux policies into /var/www/html/conf.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> Source RPM packages are available at http://www.selinuxnow.org/sefos/packages/<br /> <br /> = Kickstart Customization and System Installation =<br /> <br /> Documentation at the beginning of the kickstart files details some boot time<br /> options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> &lt;ul&gt;<br /> &lt;li&gt;Depending on the network environment the kickstart can be configured to use<br /> DHCP for address provisioning or static addressing. The default is to use<br /> DHCP, however a sample static address configuration is included for reference.<br /> If addresses are assigned statically, the kickstarts will need to be modified<br /> for each client/server installation (to provide the appropriate address).<br /> &lt;li&gt; If installing FC9 from CD/DVD access to an up-to-date FC9 repository (via<br /> external network connection or local mirror) is required as some packages required<br /> for the installs are not included in the CD/DVD install media.<br /> &lt;li&gt;Additional customization of the ldap/kerberos/nfs installation can be <br /> performed in the %post section. <br /> &lt;li&gt;Installs are currently interactive. To convert the kickstarts to a fully automated<br /> install comment out the &quot;interactive&quot; directive at the beginning of the files.<br /> &lt;li&gt;Kerberos requires that client and server system times be synchronized to function<br /> properly. The install does not customize the default FC9 NTP configuration, though it <br /> does attempt to synchronize the system time following reboot against a fedora time server <br /> (0.fedora.pool.ntp.org).<br /> &lt;/ul&gt;<br /> <br /> == Server Kickstart == <br /> <br /> === Introduction ===<br /> The kickstart installs and configures the<br /> server portion of the Labeled NFS Demo environment.<br /> It includes many components that would be used in an<br /> enterprise to provide authentication and authorization<br /> services as well as directory and file sharing services.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-server-policy-0.2-1.fc9.i386.rpm<br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> <br /> For Kerberos to function properly, forward and reverse resolution is required for all clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients and for<br /> providing the three custom packages for client <br /> installation.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time for customizing the installation:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - Server's fully qualified domain name.<br /> &lt;li&gt;se_krbpass - Kerberos password for root/admin principal.<br /> &lt;li&gt;se_kdbpass - Kerberos database password.<br /> &lt;li&gt;se_ldappass - LDAP administrator password<br /> &lt;li&gt;se_www - DNS name of web server hosting packages/config (default is www.example.com)<br /> &lt;/ul&gt;<br /> If customizing the LDAP certificate the following options can be used to override the defaults:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_certPW - Certificate Authority certificate password<br /> &lt;li&gt;se_certCountry <br /> &lt;li&gt;se_certState<br /> &lt;li&gt;se_certCity<br /> &lt;li&gt;se_certOrg<br /> &lt;li&gt;se_certEmail<br /> &lt;li&gt;se_certCN<br /> &lt;/ul&gt;<br /> <br /> === Assumptions ===<br /> ==== Kerberos Realm ====<br /> The server DNS name is used to generate the <br /> kerberos realm name and the ldap structure. The domain<br /> of the client and server are currently expected to contain<br /> two levels (i.e. DNS: example.com -&gt; LDAP: dc=example,dc=com -&gt; Kerberos: EXAMPLE.COM).<br /> <br /> ==== Packages ==== <br /> Packages are expected to be in a directory called<br /> conf off of the web server root directory (i.e. http://www.example.com/conf) <br /> <br /> ==== Time Zone ==== <br /> The current default time zone is Pacific. Change as desired.<br /> <br /> === Post Install === <br /> <br /> The client kickstart requires the LDAP<br /> CA certificate during installation time to for proper <br /> configuration. <br /> <br /> &lt;b&gt;The certificate (/etc/openldap/cacerts/cacert.pem)<br /> should be copied into conf/certs/cacert.pem on the web<br /> server.&lt;/b&gt;<br /> <br /> == Client Kickstart ==<br /> <br /> === Introduction ===<br /> This kickstart installs and configures the<br /> client portion of the Labeled NFS Demo.<br /> After a successfully client build, the client will be <br /> a fairly minimimal Fedora installation configured with<br /> GDM and GNOME. The client will be<br /> integrated with the authentication/authorization/directory<br /> services provided by the server component, and user <br /> home directories will be mounted via NFS.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> <br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-client-policy-0.1-1.fc9.i386.rpm <br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> The kerberos configuration requires an external<br /> DNS service that supports forward and reverse resolution<br /> for the clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients, for<br /> providing the three custom packages, and for providing <br /> the ldap server CA certificate. The RPMS are expected to<br /> be in /conf, and the CA certificate is expected to be in<br /> conf/certs.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time to make client configuration customizations.<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - The fully qualified domain name of the client<br /> &lt;li&gt;se_krbpass - Password for the root/admin kerberos principal.<br /> &lt;li&gt;se_server - FQDN of the server component. Defaults to seserver.example.com.<br /> &lt;/ul&gt;<br /> <br /> = Using the Environment = <br /> <br /> After the installation is complete the following accounts are available:<br /> <br /> * Server<br /> ** root - sefos1<br /> ** Kerberos Database (required to add slave KDCs)<br /> *** kdbpass<br /> ** Kerberos root/admin principal<br /> *** say#fos#<br /> * Client<br /> ** root - sefos1<br /> ** newuser - newuser1<br /> <br /> Passwords should be changed from the defaults after completing installation, especially if the clients or servers are reachable from the Internet.<br /> <br /> Using the '''newuser''' account you should now be able to login on the client using GDM or on a virtual console.<br /> <br /> = Troubleshooting (in progress)=<br /> <br /> Additional information that may be useful for troubleshooting is available in the manual installation guide with the appropriate service.<br /> <br /> * If the newuser account does not work on the client:<br /> ** Switch to a virtual console (ctrl-alt-f1) and login as root<br /> ** Verify that Kerberos was successfully configured:<br /> *** Use &lt;code&gt;klist -k /etc/krb5.keytab&lt;/code&gt;.<br /> *** If the keytab does not exist there was an error that prevented kadmin from creating the host and nfs principals during installation. Otherwise the output should show four keys for the host (i.e. host/client.example.com) and one for nfs (i.e. nfs/client.example.com). This is likely either a password mismatch issue or a time synchronization issue. <br /> *** Verify the client and server times are similar using '''date'''. <br /> **** If not, use &lt;code&gt; run_init service ntpd stop&lt;/code&gt; to turn of ntpd, then use &lt;code&gt;ntpdate -b -x 0.fedora.pool.ntp.org&lt;/code&gt; to sync time with the external time server. Use &lt;code&gt;run_init service ntpd start&lt;/code&gt; to start ntpd.<br /> **** If the external time server is unreachable, or an internal time source is preferred, reconfigure ntpd to use the desired time source and use that host instead of 0.fedora.pool.ntp.org in the ntpdate command.<br /> **** Manually synchronize both the client and server to ensure they are correct. <br /> *** Once syncronized time has been verified or established, follow the steps in the [[Labeled_NFS/Demo/Manual/Kerberos| Kerberos configuration guide]] to create the host and nfs principals, and store them locally in a keytab.<br /> ** Verify that LDAP was successfully configured:<br /> *** Examine /var/log/messages for LDAP related errors<br /> *** During testing we encountered errors where the client was unable to connect to the LDAP server. The errors were related to forgetting to copy the CA certificate into the appropriate area of the web server, forgetting to update the certificate if we built a new server, or having Apache serve an older certificate that was cached.<br /> *** Use scp to copy the CA certificate from the server to the client: &lt;code&gt; scp seserver:/etc/openldap/cacerts/cacert.pem /etc/openldap/cacerts/&lt;/code&gt;<br /> ** Verify that three SELinux booleans were correctly set on the client.<br /> *** Run &lt;code&gt;getsebool allow_kerberos allow_gssd_read_tmp use_nfs_home_dirs&lt;/code&gt; and verify the values are all set as '''on'''<br /> ** Verify that NFSv4 mounts work properly.<br /> *** Run &lt;code&gt;kinit -p root/admin&lt;/code&gt; to initialize your Kerberos credentials.<br /> *** Run &lt;code&gt;mount -v -t nfs4 -o sec=krb5,security_label seserver:/home /mnt&lt;/code&gt; to mount /mnt/home from the server.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Kickstart Labeled NFS/Demo/Kickstart 2008-12-12T19:23:04Z <p>CraigGrube: /* Using the Environment */</p> <hr /> <div>This page details the steps required to setup the SEFOS NFSv4 client and<br /> server, including some optional steps to provide basic network services<br /> and a build server. <br /> <br /> The services provided<br /> by the build server can be mixed and matched as needed to supplement existing<br /> network services to provide the <br /> basic functionality required to successfully build a client or server from <br /> a kickstart.<br /> <br /> The binary RPM packages required for the Labeled NFS to work properly were compiled<br /> for Fedora Core 9 systems. Source RPMs are available for compiling your own packages.<br /> <br /> = Boot Server Configuration (Optional) =<br /> The sample configurations assume a local network using the 192.168.201.0/24 <br /> address block. Network ranges/addresses should be modified to match<br /> those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration <br /> examples and in the demo environment. The domain may be modified to match<br /> an existing domain. Changes to the kickstarts will be required to set the<br /> new default domain and to change the creation of the ldap structure if the<br /> domain name is increased beyond two levels.<br /> <br /> <br /> == Installing packages ==<br /> <br /> The YUM package tool is used to install packages. This requires a<br /> connection to the Internet to connect to remote package repositories, or<br /> a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated<br /> packages.<br /> <br /> == Setting up the DHCP server ==<br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The<br /> example provided is one that is being used in a VMware environment.<br /> <br /> [excerpt from sample /etc/dhcpd.conf]<br /> &lt;pre&gt;<br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host seserver {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;seserver.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it<br /> might be useful to generate that portion of the DHCPD config file from a<br /> flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the DNS Server ==<br /> packages: named<br /> <br /> The default configuration will only listen on the localhost address. You will <br /> need to set the listen-on and allow-query addresses in the options section<br /> of /etc/named.conf so that named can respond to queries on the local network.<br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> Add forward and reverse zones for the address range in use:<br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> seserver A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client2 A 192.168.201.51<br /> client3 A 192.168.201.52<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR seserver.example.com.<br /> <br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> 52 IN PTR client3.example.com.<br /> &lt;/pre&gt;<br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named start<br /> &lt;/pre&gt;<br /> <br /> == Setting up the Web server ==<br /> packages: httpd<br /> <br /> Download the following kickstart files and binary RPMs:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc3-5.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Create a directory to hold the kickstart files [/var/www/html/kickstart/]. Copy the client and server kickstart files into this directory.<br /> <br /> Create directories to hold the RPMs and eventually the server CA public certificate [/var/www/html/conf for packages, and /var/www/html/certs for the certificate]. Copy the Kernel, NFS Utils and SEFOS SELinux policies into /var/www/html/conf.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> Source RPM packages are available at http://www.selinuxnow.org/sefos/packages/<br /> <br /> = Kickstart Customization and System Installation =<br /> <br /> Documentation at the beginning of the kickstart files details some boot time<br /> options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> &lt;ul&gt;<br /> &lt;li&gt;Depending on the network environment the kickstart can be configured to use<br /> DHCP for address provisioning or static addressing. The default is to use<br /> DHCP, however a sample static address configuration is included for reference.<br /> If addresses are assigned statically, the kickstarts will need to be modified<br /> for each client/server installation (to provide the appropriate address).<br /> &lt;li&gt; If installing FC9 from CD/DVD access to an up-to-date FC9 repository (via<br /> external network connection or local mirror) is required as some packages required<br /> for the installs are not included in the CD/DVD install media.<br /> &lt;li&gt;Additional customization of the ldap/kerberos/nfs installation can be <br /> performed in the %post section. <br /> &lt;li&gt;Installs are currently interactive. To convert the kickstarts to a fully automated<br /> install comment out the &quot;interactive&quot; directive at the beginning of the files.<br /> &lt;li&gt;Kerberos requires that client and server system times be synchronized to function<br /> properly. The install does not customize the default FC9 NTP configuration, though it <br /> does attempt to synchronize the system time following reboot against a fedora time server <br /> (0.fedora.pool.ntp.org).<br /> &lt;/ul&gt;<br /> <br /> == Server Kickstart == <br /> <br /> === Introduction ===<br /> The kickstart installs and configures the<br /> server portion of the Labeled NFS Demo environment.<br /> It includes many components that would be used in an<br /> enterprise to provide authentication and authorization<br /> services as well as directory and file sharing services.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-server-policy-0.2-1.fc9.i386.rpm<br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> <br /> For Kerberos to function properly, forward and reverse resolution is required for all clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients and for<br /> providing the three custom packages for client <br /> installation.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time for customizing the installation:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - Server's fully qualified domain name.<br /> &lt;li&gt;se_krbpass - Kerberos password for root/admin principal.<br /> &lt;li&gt;se_kdbpass - Kerberos database password.<br /> &lt;li&gt;se_ldappass - LDAP administrator password<br /> &lt;li&gt;se_www - DNS name of web server hosting packages/config (default is www.example.com)<br /> &lt;/ul&gt;<br /> If customizing the LDAP certificate the following options can be used to override the defaults:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_certPW - Certificate Authority certificate password<br /> &lt;li&gt;se_certCountry <br /> &lt;li&gt;se_certState<br /> &lt;li&gt;se_certCity<br /> &lt;li&gt;se_certOrg<br /> &lt;li&gt;se_certEmail<br /> &lt;li&gt;se_certCN<br /> &lt;/ul&gt;<br /> <br /> === Assumptions ===<br /> ==== Kerberos Realm ====<br /> The server DNS name is used to generate the <br /> kerberos realm name and the ldap structure. The domain<br /> of the client and server are currently expected to contain<br /> two levels (i.e. DNS: example.com -&gt; LDAP: dc=example,dc=com -&gt; Kerberos: EXAMPLE.COM).<br /> <br /> ==== Packages ==== <br /> Packages are expected to be in a directory called<br /> conf off of the web server root directory (i.e. http://www.example.com/conf) <br /> <br /> ==== Time Zone ==== <br /> The current default time zone is Pacific. Change as desired.<br /> <br /> === Post Install === <br /> <br /> The client kickstart requires the LDAP<br /> CA certificate during installation time to for proper <br /> configuration. <br /> <br /> &lt;b&gt;The certificate (/etc/openldap/cacerts/cacert.pem)<br /> should be copied into conf/certs/cacert.pem on the web<br /> server.&lt;/b&gt;<br /> <br /> == Client Kickstart ==<br /> <br /> === Introduction ===<br /> This kickstart installs and configures the<br /> client portion of the Labeled NFS Demo.<br /> After a successfully client build, the client will be <br /> a fairly minimimal Fedora installation configured with<br /> GDM and GNOME. The client will be<br /> integrated with the authentication/authorization/directory<br /> services provided by the server component, and user <br /> home directories will be mounted via NFS.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> <br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-client-policy-0.1-1.fc9.i386.rpm <br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> The kerberos configuration requires an external<br /> DNS service that supports forward and reverse resolution<br /> for the clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients, for<br /> providing the three custom packages, and for providing <br /> the ldap server CA certificate. The RPMS are expected to<br /> be in /conf, and the CA certificate is expected to be in<br /> conf/certs.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time to make client configuration customizations.<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - The fully qualified domain name of the client<br /> &lt;li&gt;se_krbpass - Password for the root/admin kerberos principal.<br /> &lt;/ul&gt;<br /> <br /> = Using the Environment = <br /> <br /> After the installation is complete the following accounts are available:<br /> <br /> * Server<br /> ** root - sefos1<br /> ** Kerberos Database (required to add slave KDCs)<br /> *** kdbpass<br /> ** Kerberos root/admin principal<br /> *** say#fos#<br /> * Client<br /> ** root - sefos1<br /> ** newuser - newuser1<br /> <br /> Passwords should be changed from the defaults after completing installation, especially if the clients or servers are reachable from the Internet.<br /> <br /> Using the '''newuser''' account you should now be able to login on the client using GDM or on a virtual console.<br /> <br /> = Troubleshooting (in progress)=<br /> <br /> Additional information that may be useful for troubleshooting is available in the manual installation guide with the appropriate service.<br /> <br /> * If the newuser account does not work on the client:<br /> ** Switch to a virtual console (ctrl-alt-f1) and login as root<br /> ** Verify that Kerberos was successfully configured:<br /> *** Use &lt;code&gt;klist -k /etc/krb5.keytab&lt;/code&gt;.<br /> *** If the keytab does not exist there was an error that prevented kadmin from creating the host and nfs principals during installation. Otherwise the output should show four keys for the host (i.e. host/client.example.com) and one for nfs (i.e. nfs/client.example.com). This is likely either a password mismatch issue or a time synchronization issue. <br /> *** Verify the client and server times are similar using '''date'''. <br /> **** If not, use &lt;code&gt; run_init service ntpd stop&lt;/code&gt; to turn of ntpd, then use &lt;code&gt;ntpdate -b -x 0.fedora.pool.ntp.org&lt;/code&gt; to sync time with the external time server. Use &lt;code&gt;run_init service ntpd start&lt;/code&gt; to start ntpd.<br /> **** If the external time server is unreachable, or an internal time source is preferred, reconfigure ntpd to use the desired time source and use that host instead of 0.fedora.pool.ntp.org in the ntpdate command.<br /> **** Manually synchronize both the client and server to ensure they are correct. <br /> *** Once syncronized time has been verified or established, follow the steps in the [[Labeled_NFS/Demo/Manual/Kerberos| Kerberos configuration guide]] to create the host and nfs principals, and store them locally in a keytab.<br /> ** Verify that LDAP was successfully configured:<br /> *** Examine /var/log/messages for LDAP related errors<br /> *** During testing we encountered errors where the client was unable to connect to the LDAP server. The errors were related to forgetting to copy the CA certificate into the appropriate area of the web server, forgetting to update the certificate if we built a new server, or having Apache serve an older certificate that was cached.<br /> *** Use scp to copy the CA certificate from the server to the client: &lt;code&gt; scp seserver:/etc/openldap/cacerts/cacert.pem /etc/openldap/cacerts/&lt;/code&gt;<br /> ** Verify that three SELinux booleans were correctly set on the client.<br /> *** Run &lt;code&gt;getsebool allow_kerberos allow_gssd_read_tmp use_nfs_home_dirs&lt;/code&gt; and verify the values are all set as '''on'''<br /> ** Verify that NFSv4 mounts work properly.<br /> *** Run &lt;code&gt;kinit -p root/admin&lt;/code&gt; to initialize your Kerberos credentials.<br /> *** Run &lt;code&gt;mount -v -t nfs4 -o sec=krb5,security_label seserver:/home /mnt&lt;/code&gt; to mount /mnt/home from the server.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo/Kickstart Labeled NFS/Demo/Kickstart 2008-12-12T19:21:14Z <p>CraigGrube: /* Using the Environment */</p> <hr /> <div>This page details the steps required to setup the SEFOS NFSv4 client and<br /> server, including some optional steps to provide basic network services<br /> and a build server. <br /> <br /> The services provided<br /> by the build server can be mixed and matched as needed to supplement existing<br /> network services to provide the <br /> basic functionality required to successfully build a client or server from <br /> a kickstart.<br /> <br /> The binary RPM packages required for the Labeled NFS to work properly were compiled<br /> for Fedora Core 9 systems. Source RPMs are available for compiling your own packages.<br /> <br /> = Boot Server Configuration (Optional) =<br /> The sample configurations assume a local network using the 192.168.201.0/24 <br /> address block. Network ranges/addresses should be modified to match<br /> those currently in use if desired.<br /> <br /> A default domain of &quot;example.com&quot; is used throughout the configuration <br /> examples and in the demo environment. The domain may be modified to match<br /> an existing domain. Changes to the kickstarts will be required to set the<br /> new default domain and to change the creation of the ldap structure if the<br /> domain name is increased beyond two levels.<br /> <br /> <br /> == Installing packages ==<br /> <br /> The YUM package tool is used to install packages. This requires a<br /> connection to the Internet to connect to remote package repositories, or<br /> a local repository containing the packages.<br /> <br /> Use the command 'yum install &lt;packagename&gt;' to install the indicated<br /> packages.<br /> <br /> == Setting up the DHCP server ==<br /> packages: dhcp<br /> <br /> Edit /etc/dhcpd.conf and configure a subnet range to be served. The<br /> example provided is one that is being used in a VMware environment.<br /> <br /> [excerpt from sample /etc/dhcpd.conf]<br /> &lt;pre&gt;<br /> default-lease-time 1800; # 30 minutes<br /> max-lease-time 7200; # 2 hours<br /> <br /> subnet 192.168.201.0 netmask 255.255.255.0 {<br /> range 192.168.201.64 192.168.201.96;<br /> option broadcast-address 192.168.201.255;<br /> option domain-name-servers 192.168.201.3;<br /> option domain-name &quot;example.com&quot;;<br /> option routers 192.168.201.2;<br /> <br /> host seserver {<br /> hardware ethernet 0:c:29:42:3a:25;<br /> fixed-address 192.168.201.13;<br /> option host-name &quot;seserver.example.com&quot;;<br /> }<br /> host client1 {<br /> hardware ethernet 0:c:29:42:c4:7c;<br /> fixed-address 192.168.201.50;<br /> option host-name &quot;client1.example.com&quot;;<br /> }<br /> host client2 {<br /> hardware ethernet 0:c:29:42:9f:8e;<br /> fixed-address 192.168.201.51;<br /> option host-name &quot;client2.example.com&quot;;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> <br /> As each client machine must be listed in the above group section, it<br /> might be useful to generate that portion of the DHCPD config file from a<br /> flat text file that contains a list of names and MAC addresses.<br /> <br /> Start the dhcpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service dhcpd start<br /> # chkconfig dhcpd on<br /> &lt;/pre&gt;<br /> <br /> == Setting up the DNS Server ==<br /> packages: named<br /> <br /> The default configuration will only listen on the localhost address. You will <br /> need to set the listen-on and allow-query addresses in the options section<br /> of /etc/named.conf so that named can respond to queries on the local network.<br /> &lt;pre&gt;<br /> options {<br /> // ...<br /> listen-on port 53 { 192.168.201.3; 127.0.0.1; };<br /> allow-query { 192.168.201.0/24; 127.0.0.1/32; };<br /> <br /> };<br /> &lt;/pre&gt;<br /> Add forward and reverse zones for the address range in use:<br /> &lt;pre&gt;<br /> zone &quot;example.com&quot; in{<br /> type master;<br /> file &quot;example.com&quot;;<br /> };<br /> // reverse map for class C 192.168.1.0<br /> zone &quot;201.168.192.IN-ADDR.ARPA&quot; in{<br /> type master;<br /> file &quot;192.168.201.rev&quot;;<br /> };<br /> &lt;/pre&gt;<br /> <br /> Create the forward zone in /var/named/example.com:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806256 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> localhost A 127.0.0.1<br /> <br /> ; address of machine acting as DNS server<br /> dns A 192.168.201.3<br /> seserver A 192.168.201.13<br /> <br /> client1 A 192.168.201.50<br /> client2 A 192.168.201.51<br /> client3 A 192.168.201.52<br /> &lt;/pre&gt;<br /> <br /> Create the reverse zone in /var/named/192.168.201.rev:<br /> &lt;pre&gt;<br /> $TTL 6D<br /> @ IN SOA dns.example.com. root.example.com. (<br /> 200806201 ; Serial<br /> 1H ; Refresh<br /> 300 ; Retry<br /> 2D ; Expire<br /> 12H) ; Minimum TTL<br /> NS dns.example.com.<br /> ;<br /> ;<br /> 3 IN PTR dns.example.com.<br /> 13 IN PTR seserver.example.com.<br /> <br /> 50 IN PTR client1.example.com.<br /> 51 IN PTR client2.example.com.<br /> 52 IN PTR client3.example.com.<br /> &lt;/pre&gt;<br /> Start the named service and enable it to run on bootup.<br /> &lt;pre&gt;<br /> # service named start<br /> # chkconfig named start<br /> &lt;/pre&gt;<br /> <br /> == Setting up the Web server ==<br /> packages: httpd<br /> <br /> Download the following kickstart files and binary RPMs:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.client.en.cfg - Client Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/ks.server.en.cfg - Server Kickstart<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/kernel-2.6.28rc3-5.i386.rpm - Linux Kernel with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/nfs-utils-1.1.2-7.fc9.labeled.i386.rpm - NFS Utils with Labeled NFS patches<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-server-policy-0.2-1.fc9.i386.rpm - SELinux policy for labeled NFS server<br /> &lt;li&gt;http://www.selinuxnow.org/sefos/packages/sefos-client-policy-0.1-1.fc9.i386.rpm - SELinux policy for labeled NFS client<br /> &lt;/ul&gt;<br /> <br /> Create a directory to hold the kickstart files [/var/www/html/kickstart/]. Copy the client and server kickstart files into this directory.<br /> <br /> Create directories to hold the RPMs and eventually the server CA public certificate [/var/www/html/conf for packages, and /var/www/html/certs for the certificate]. Copy the Kernel, NFS Utils and SEFOS SELinux policies into /var/www/html/conf.<br /> <br /> Start the httpd service and enable it to be run on bootup.<br /> &lt;pre&gt;<br /> # service httpd start<br /> # chkconfig httpd on<br /> &lt;/pre&gt;<br /> <br /> Source RPM packages are available at http://www.selinuxnow.org/sefos/packages/<br /> <br /> = Kickstart Customization and System Installation =<br /> <br /> Documentation at the beginning of the kickstart files details some boot time<br /> options that can be specified to customize the installation.<br /> <br /> Some generic notes about the kickstarts:<br /> &lt;ul&gt;<br /> &lt;li&gt;Depending on the network environment the kickstart can be configured to use<br /> DHCP for address provisioning or static addressing. The default is to use<br /> DHCP, however a sample static address configuration is included for reference.<br /> If addresses are assigned statically, the kickstarts will need to be modified<br /> for each client/server installation (to provide the appropriate address).<br /> &lt;li&gt; If installing FC9 from CD/DVD access to an up-to-date FC9 repository (via<br /> external network connection or local mirror) is required as some packages required<br /> for the installs are not included in the CD/DVD install media.<br /> &lt;li&gt;Additional customization of the ldap/kerberos/nfs installation can be <br /> performed in the %post section. <br /> &lt;li&gt;Installs are currently interactive. To convert the kickstarts to a fully automated<br /> install comment out the &quot;interactive&quot; directive at the beginning of the files.<br /> &lt;li&gt;Kerberos requires that client and server system times be synchronized to function<br /> properly. The install does not customize the default FC9 NTP configuration, though it <br /> does attempt to synchronize the system time following reboot against a fedora time server <br /> (0.fedora.pool.ntp.org).<br /> &lt;/ul&gt;<br /> <br /> == Server Kickstart == <br /> <br /> === Introduction ===<br /> The kickstart installs and configures the<br /> server portion of the Labeled NFS Demo environment.<br /> It includes many components that would be used in an<br /> enterprise to provide authentication and authorization<br /> services as well as directory and file sharing services.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-server-policy-0.2-1.fc9.i386.rpm<br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> <br /> For Kerberos to function properly, forward and reverse resolution is required for all clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients and for<br /> providing the three custom packages for client <br /> installation.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time for customizing the installation:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - Server's fully qualified domain name.<br /> &lt;li&gt;se_krbpass - Kerberos password for root/admin principal.<br /> &lt;li&gt;se_kdbpass - Kerberos database password.<br /> &lt;li&gt;se_ldappass - LDAP administrator password<br /> &lt;li&gt;se_www - DNS name of web server hosting packages/config (default is www.example.com)<br /> &lt;/ul&gt;<br /> If customizing the LDAP certificate the following options can be used to override the defaults:<br /> &lt;ul&gt;<br /> &lt;li&gt;se_certPW - Certificate Authority certificate password<br /> &lt;li&gt;se_certCountry <br /> &lt;li&gt;se_certState<br /> &lt;li&gt;se_certCity<br /> &lt;li&gt;se_certOrg<br /> &lt;li&gt;se_certEmail<br /> &lt;li&gt;se_certCN<br /> &lt;/ul&gt;<br /> <br /> === Assumptions ===<br /> ==== Kerberos Realm ====<br /> The server DNS name is used to generate the <br /> kerberos realm name and the ldap structure. The domain<br /> of the client and server are currently expected to contain<br /> two levels (i.e. DNS: example.com -&gt; LDAP: dc=example,dc=com -&gt; Kerberos: EXAMPLE.COM).<br /> <br /> ==== Packages ==== <br /> Packages are expected to be in a directory called<br /> conf off of the web server root directory (i.e. http://www.example.com/conf) <br /> <br /> ==== Time Zone ==== <br /> The current default time zone is Pacific. Change as desired.<br /> <br /> === Post Install === <br /> <br /> The client kickstart requires the LDAP<br /> CA certificate during installation time to for proper <br /> configuration. <br /> <br /> &lt;b&gt;The certificate (/etc/openldap/cacerts/cacert.pem)<br /> should be copied into conf/certs/cacert.pem on the web<br /> server.&lt;/b&gt;<br /> <br /> == Client Kickstart ==<br /> <br /> === Introduction ===<br /> This kickstart installs and configures the<br /> client portion of the Labeled NFS Demo.<br /> After a successfully client build, the client will be <br /> a fairly minimimal Fedora installation configured with<br /> GDM and GNOME. The client will be<br /> integrated with the authentication/authorization/directory<br /> services provided by the server component, and user <br /> home directories will be mounted via NFS.<br /> <br /> * Warning: Using the kickstart installation will repartition the primary system disk, destroying existing partitions and operating systems already present.<br /> <br /> === External Dependencies ===<br /> For successful completion of the<br /> kickstart and configuration of the demo environment there <br /> several external dependencies that must be met:<br /> <br /> ==== Packages ====<br /> Three custom RPM packages must be available<br /> on a web server for installation. The current versions<br /> of these packages are:<br /> &lt;pre&gt;<br /> kernel-2.6.28rc3-5.i386.rpm<br /> nfs-utils-1.1.2-7.fc9.labeled.i386.rpm<br /> sefos-client-policy-0.1-1.fc9.i386.rpm <br /> &lt;/pre&gt;<br /> <br /> ==== DNS ====<br /> The kerberos configuration requires an external<br /> DNS service that supports forward and reverse resolution<br /> for the clients and servers.<br /> <br /> ==== Web Server ====<br /> The kickstart requires a local web server<br /> for providing the kickstart itself to clients, for<br /> providing the three custom packages, and for providing <br /> the ldap server CA certificate. The RPMS are expected to<br /> be in /conf, and the CA certificate is expected to be in<br /> conf/certs.<br /> <br /> === Installation ===<br /> To install boot the system from FC9 <br /> installation media (DVD, CD, netboot, etc). When the <br /> grub interface appears, modify the boot options to load<br /> the kickstart and provide the desired boot options to <br /> customize the installation (i.e. ks=http://webserver/dir/ks.cfg se_var1=val1 ...).<br /> <br /> === Boot Options ===<br /> The following options are available at <br /> installation time to make client configuration customizations.<br /> &lt;ul&gt;<br /> &lt;li&gt;se_fqdn - The fully qualified domain name of the client<br /> &lt;li&gt;se_krbpass - Password for the root/admin kerberos principal.<br /> &lt;/ul&gt;<br /> <br /> = Using the Environment = <br /> <br /> After the installation is complete the following accounts are available:<br /> <br /> * Server<br /> ** root - sefos1<br /> ** Kerberos Database (required to add slave KDCs)<br /> *** kdbpass<br /> ** Kerberos root/admin principal<br /> *** say#fos#<br /> * Client<br /> ** root - sefos1<br /> ** newuser - newuser1<br /> <br /> <br /> Using the '''newuser''' account you should now be able to login on the client using GDM or on a virtual console.<br /> <br /> = Troubleshooting (in progress)=<br /> <br /> Additional information that may be useful for troubleshooting is available in the manual installation guide with the appropriate service.<br /> <br /> * If the newuser account does not work on the client:<br /> ** Switch to a virtual console (ctrl-alt-f1) and login as root<br /> ** Verify that Kerberos was successfully configured:<br /> *** Use &lt;code&gt;klist -k /etc/krb5.keytab&lt;/code&gt;.<br /> *** If the keytab does not exist there was an error that prevented kadmin from creating the host and nfs principals during installation. Otherwise the output should show four keys for the host (i.e. host/client.example.com) and one for nfs (i.e. nfs/client.example.com). This is likely either a password mismatch issue or a time synchronization issue. <br /> *** Verify the client and server times are similar using '''date'''. <br /> **** If not, use &lt;code&gt; run_init service ntpd stop&lt;/code&gt; to turn of ntpd, then use &lt;code&gt;ntpdate -b -x 0.fedora.pool.ntp.org&lt;/code&gt; to sync time with the external time server. Use &lt;code&gt;run_init service ntpd start&lt;/code&gt; to start ntpd.<br /> **** If the external time server is unreachable, or an internal time source is preferred, reconfigure ntpd to use the desired time source and use that host instead of 0.fedora.pool.ntp.org in the ntpdate command.<br /> **** Manually synchronize both the client and server to ensure they are correct. <br /> *** Once syncronized time has been verified or established, follow the steps in the [[Labeled_NFS/Demo/Manual/Kerberos| Kerberos configuration guide]] to create the host and nfs principals, and store them locally in a keytab.<br /> ** Verify that LDAP was successfully configured:<br /> *** Examine /var/log/messages for LDAP related errors<br /> *** During testing we encountered errors where the client was unable to connect to the LDAP server. The errors were related to forgetting to copy the CA certificate into the appropriate area of the web server, forgetting to update the certificate if we built a new server, or having Apache serve an older certificate that was cached.<br /> *** Use scp to copy the CA certificate from the server to the client: &lt;code&gt; scp seserver:/etc/openldap/cacerts/cacert.pem /etc/openldap/cacerts/&lt;/code&gt;<br /> ** Verify that three SELinux booleans were correctly set on the client.<br /> *** Run &lt;code&gt;getsebool allow_kerberos allow_gssd_read_tmp use_nfs_home_dirs&lt;/code&gt; and verify the values are all set as '''on'''<br /> ** Verify that NFSv4 mounts work properly.<br /> *** Run &lt;code&gt;kinit -p root/admin&lt;/code&gt; to initialize your Kerberos credentials.<br /> *** Run &lt;code&gt;mount -v -t nfs4 -o sec=krb5,security_label seserver:/home /mnt&lt;/code&gt; to mount /mnt/home from the server.</div> CraigGrube http://selinuxproject.org/page/Labeled_NFS/Demo Labeled NFS/Demo 2008-12-12T19:08:38Z <p>CraigGrube: /* NFS, Network File System */</p> <hr /> <div>The goal of the demonstration is to show passing of security labels over NFSv4 in a configuration similar to what might be found in a typical enterprise environment. Modern enterprise environments provide a number of centralized services for authentication and authorization, directory services, and network storage of user data, which are provided by the server component of the demonstration. These common services are provided using the following packages: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Authentication Services - Kerberos<br /> &lt;li&gt;Directory Services / Authorization Services - OpenLDAP<br /> &lt;li&gt;Centralized User Data Storage - NFSv4<br /> &lt;/ul&gt;<br /> <br /> The client component of the demonstration utilizes these services to provide users with login access. Automated installation scripts allow clients to be rapidly installed and configured, differing only by the client kerberos credentials. The demonstration user will be able to access each client, with their user data available on each system.<br /> <br /> Mandatory access controls are enforced on both the client and server in Multi Layer Security mode using SELinux.<br /> <br /> = NFS, Network File System =<br /> <br /> The NFS service provides files that are accessible across a network<br /> domain. The NFS service will provide user data directories (e.g. home/ directories). It will allow<br /> users to access their files from anywhere within the demo enterprise<br /> network.<br /> <br /> NFS is a commonly used to provide distributed file services within<br /> enterprise networks. Using it for the network's user directories<br /> provides for:<br /> * Centralized file control <br /> * User based access control<br /> * Easier data protection<br /> ** Backups<br /> ** Recovery<br /> ** Integrity<br /> * Centralized access control<br /> * User mobility between hosts within the enterprise (i.e. users can login from any machine)<br /> <br /> NFS is standard on most Unix/Linux distributions. It is also supported by Microsoft Windows, OS X, and other operating systems.<br /> <br /> = Modifed Kernel for NFS =<br /> <br /> Support for labeled files was added to the NFS version 4 client and server. Label management interfaces are provided and the mounted file system functions as any other local, labeled file system.<br /> <br /> = Kerberos Authentication Service =<br /> <br /> Kerberos is an authentication system for distributed systems. Its<br /> use in the demo is to provide authentication services for access to<br /> the client hosts and the NFS and LDAP servers.<br /> <br /> As Security is a key part of this NFS demo, Kerberos was chosen for<br /> its ability to provide an enterprise level authentication system.<br /> Kerberos has a number of qualities that lends itself to this:<br /> * Integrates easily with NFS<br /> * It is a mature service used in many enterprises<br /> * Designed to be secure within open networks<br /> * Support for Kerberos exists on almost all major platforms<br /> ** Unix/NetBSD/Linux Kerberos is integrated into many popular distributions (and some embedded Linux OS's.<br /> ** default authentication within the Windows family of clients/servers since Windows 2000 Professional/Server.<br /> ** default authentication product in Mac OS X.<br /> ** SUN<br /> ** Cisco<br /> * It is an open standard, IETF RFC 1510.<br /> <br /> = LDAP, Lightweight Directory Access Protocol =<br /> <br /> LDAP is a directory service. It is a simple database that is<br /> network accessible. It is used in this demo is to provide the user<br /> information necessary for client machines to perform user logins and mount<br /> the NFS provided home directories. More specifically, the LDAP<br /> server provides to the client machines:<br /> * user name, uid, gid<br /> * home directory locations<br /> * login shell<br /> <br /> The combination of these three services provide an example of a<br /> secure network file system that would be acceptable for a<br /> contemporary enterprise.<br /> <br /> For the demo, the servers will<br /> most likely all run on the same host and there will be 1+ client<br /> hosts using the servers' services.<br /> <br /> = Under the hood =<br /> <br /> Once the demo is setup, what happens when a user logs in? <br /> <br /> If it the demo was setup properly, and the right username and password are used, the user should be able to login through GDM<br /> and have their home directory mounted with a normal and functional GNOME session initiated. Under the covers a complex series<br /> of steps involving Kerberos, RPC services, LDAP, automount and NFS that ensures authentication of the user as well as<br /> client and server systems and services. In a nutshell, here are the important steps that occur during a 'normal' user login:<br /> <br /> &lt;ol&gt;<br /> &lt;li&gt; User account information is pulled from the LDAP server.<br /> &lt;ol&gt;<br /> &lt;li&gt;Using the supplied username the server returns available account related <br /> information (UID, GID, shell, home dir, etc.)<br /> &lt;/ol&gt;<br /> &lt;li&gt; User authentication is provided through PAM, which is configured to use Kerberos<br /> &lt;ol&gt;<br /> &lt;li&gt;Prior to acquiring the user Kerberos ticket, the client and server systems mutually authenticate to ensure<br /> the correct systems are being involved in the authentication steps.<br /> &lt;li&gt;Assuming the correct password is supplied, the client system is able to authenticate the user and caches<br /> the users Kerberos credentials for later use.<br /> &lt;/ol&gt;<br /> &lt;li&gt; User home directories are mounted via NFSv4 by automount.<br /> &lt;ol&gt;<br /> &lt;li&gt;Automount attempts to mount the users home directory and RPC GSSD provides the user's cached Kerberos credentials to the NFS server as only authenticated users are allowed to mount exported shares.<br /> &lt;li&gt;UID/GID -&gt; user name/group name mapping information (provided by the LDAP server) is used to associated user names with the UIDs and GIDs denoting ownership of the mounted files and directories. This information is used by the operating system to enforce discretionary access controls.<br /> &lt;li&gt;The NFS client and server exchange security labels to allow SELinux to appropriately label files and enforce mandatory access controls.<br /> &lt;/ol&gt;<br /> &lt;/ol&gt;<br /> <br /> <br /> More specific information describing how the services on the clients and servers interact, and mapping between different<br /> service namespaces can be found here: <br /> <br /> [[Labeled_NFS/Demo/UserMapping|Service Interaction and User Name Mapping]]<br /> <br /> = Instructions =<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Labeled_NFS/Demo/Kickstart| Automated Client and Server installation via Kickstart]]<br /> &lt;li&gt;[[Labeled_NFS/Demo/Manual|Manual Client and Server installation]]<br /> &lt;/ul&gt;<br /> <br /> Information helpful for troubleshooting issues is included in-line in the manual installation instructions and at the end of the automated installation.<br /> <br /> = Packages =<br /> <br /> Kickstart files, binary RPMs and source RPMS are available for download at: <br /> <br /> http://www.selinuxnow.org/sefos/packages <br /> <br /> More information on the specific packages required is included in the automated install guide.<br /> <br /> Binary packages are compiled for Fedora Core 9 systems using the Intel x86 architecture. <br /> Source RPMS are available (but not tested) for use on other releases or architectures.</div> CraigGrube