spelling fixes

This commit is contained in:
Chris PeBenito 2005-06-15 21:30:16 +00:00
parent 9b57ae78e4
commit 5fa7825da8
2 changed files with 3 additions and 3 deletions

View File

@ -7,7 +7,7 @@ This guide will walk you through the basics of creating a new reference policy m
Modules are the principal organizing component in refpolicy. They are conceptually similar to the source modules in the current strict and targeted policy, but have additional meaning. A module contains the policy for an application or related group of applications, private and shared resources, labeling information, and interfaces that allow other modules access to the modules resources. The majority of the global policy has been eliminated in refpolicy. Certain policy components, like users and object classes, are still global in refpolicy, but almost all TE policy is now contained within a module.
</p>
<p>
Modules should be placed in refpolicy/policy/LAYER, where LAYER is the name of the appropriate layer. The current layers can be seen in the <A href="refpolicy-www/api-docs/">interface documentation</A>. Let's create a new module in the services layer called myapp. This is done by creating three files: myapp.te, mayapp.fc, and myapp.if, all in directory refpolicy/policy/services. The file myapp.te file will contain all of the policy private to this module, including any types or attributes. The file myapp.fc file will containt the file context labeling statement for this module. Finally, the file myapp.if will contain the inferfaces for this module (interfaces will be explained below).
Modules should be placed in refpolicy/policy/LAYER, where LAYER is the name of the appropriate layer. The current layers can be seen in the <A href="refpolicy-www/api-docs/">interface documentation</A>. Let's create a new module in the services layer called myapp. This is done by creating three files: myapp.te, mayapp.fc, and myapp.if, all in directory refpolicy/policy/services. The file myapp.te file will contain all of the policy private to this module, including any types or attributes. The file myapp.fc file will contain the file context labeling statement for this module. Finally, the file myapp.if will contain the interfaces for this module (interfaces will be explained below).
</p>
<h3>Module TE Policy</h3>
<p>
@ -28,7 +28,7 @@ files_tmp_file(myapp_tmp_t)
</div>
</p>
<p>
This creates all fo the types needed for this module, including a type for the process, executables, log files, and temporary files. The first thing to notice is that there are no attributes applied to any of these types. In refpolicy all types and attributes can only be referred to in the module that declares them. This means that it is not possible, for example, to directly refer to the domain attribute. Instead, macros in other modules are used to declare that a type will be used for a certain purpose. These macros will likely use attributes (but not necessarily), but it allows the module that declared the attribute to strictly control how it can be used. In this example interfaces are used to transform the types into a domain, entry file, log file, and temporary file.
This creates all of the types needed for this module, including a type for the process, executables, log files, and temporary files. The first thing to notice is that there are no attributes applied to any of these types. In refpolicy all types and attributes can only be referred to in the module that declares them. This means that it is not possible, for example, to directly refer to the domain attribute. Instead, macros in other modules are used to declare that a type will be used for a certain purpose. These macros will likely use attributes (but not necessarily), but it allows the module that declared the attribute to strictly control how it can be used. In this example interfaces are used to transform the types into a domain, entry file, log file, and temporary file.
</p>
<p>
Let's expand this example further by allowing some access for these types. My application needs access between it's own types and access to read random numbers. The access between private types is written exactly the same way current policy rules are written, i.e.:

View File

@ -15,7 +15,7 @@ Refpolicy is under active development, with support and full time development st
<ul>
<li><b>Security Goals:</b> clearly stated security goals will for each component of the policy. This will allow policy developers to determine if a given component meets their security needs.</li>
<LI><b>Flexible Base Policy:</b> a base policy that protects the basic operating system and serves as a foundation to the rest of the policy. This base policy should be able to support a variety of application policies with differing security goals.</LI>
<li><b>Application Policy Variations:</b> application policy variations that make different security tradeoffs. For example, two apache policies might be created. One that is for serving read-only, static content that is severely restricted and another that is appropriate for dynamic content.</li>
<li><b>Application Policy Variations:</b> application policy variations that make different security tradeoffs. For example, two Apache policies might be created. One that is for serving read-only, static content that is severely restricted and another that is appropriate for dynamic content.</li>
<li><b>Configuration Tools:</b> configuration tools that allow the policy developer to make important security decisions including defining roles, configuring networking, and trading legacy compatibility for increased security.</li>
<li><b>Multi-Level Security</b>: MLS will be supported out-of-the-box without requiring destructive changes to the policy. It will be possible to compile and MLS and non-MLS policy from the same policy files by switching a configuration option.</li>