diff options
Diffstat (limited to 'el_GR.ISO8859-7/books/handbook/mac/chapter.sgml')
| -rw-r--r-- | el_GR.ISO8859-7/books/handbook/mac/chapter.sgml | 2098 |
1 files changed, 0 insertions, 2098 deletions
diff --git a/el_GR.ISO8859-7/books/handbook/mac/chapter.sgml b/el_GR.ISO8859-7/books/handbook/mac/chapter.sgml deleted file mode 100644 index 7acf3a2b30..0000000000 --- a/el_GR.ISO8859-7/books/handbook/mac/chapter.sgml +++ /dev/null @@ -1,2098 +0,0 @@ -<?xml version="1.0" encoding="iso-8859-7" standalone="no"?> -<!-- - - Το Εγχειρίδιο του FreeBSD: Υποχρεωτικός Έλεγχος Πρόσβασης - - The FreeBSD Greek Documentation Project - - $FreeBSD$ - - %SOURCE% en_US.ISO8859-1/books/handbook/mac/chapter.sgml - %SRCID% 1.1 - ---> - -<chapter id="mac"> - <chapterinfo> - <authorgroup> - <author> - <firstname>Tom</firstname> - <surname>Rhodes</surname> - <contrib>Γράφτηκε από τον </contrib> - </author> - </authorgroup> - </chapterinfo> - - <title>Υποχρεωτικός Έλεγχος Πρόσβασης</title> - - <sect1 id="mac-synopsis"> - <title>Σύνοψη</title> - - <indexterm><primary>MAC</primary></indexterm> - <indexterm> - <primary>Υποχρεωτικός Έλεγχος Πρόσβασης</primary> - <see>MAC</see> - </indexterm> - - <para>Το &os; 5.X εισήγαγε νέες επεκτάσεις ασφαλείας από το - TrustedBSD project, που βασίζονται στο προσχέδιο &posix;.1e. Δύο από - τους πιο σημαντικούς νέους μηχανισμούς ασφαλείας, είναι οι Λίστες - Ελέγχου Πρόσβασης (Access Control Lists, <acronym>ACL</acronym>s) στο - σύστημα αρχείων και ο Υποχρεωτικός Έλεγχος Πρόσβασης (Mandatory Access - Control, <acronym>MAC</acronym>). Ο Υποχρεωτικός Έλεγχος Πρόσβασης - δίνει την δυνατότητας φόρτωσης αρθρωμάτων (modules) ελέγχου τα οποία - υλοποιούν νέες πολιτικές ασφαλείας. Μερικά παρέχουν προστασία σε ένα - στενό υποσύνολο του συστήματος, ενδυναμώνοντας την ασφάλεια μιας - συγκεκριμένης υπηρεσίας. Άλλα παρέχουν συνοπτική ασφάλεια προς όλες - τις υπηρεσίες και το σύστημα. Ο έλεγχος ονομάζεται υποχρεωτικός από - το γεγονός ότι η επιβολή γίνεται από τους διαχειριστές και το σύστημα, - και δεν αφήνεται στη διακριτική ευχέρεια των χρηστών όπως γίνεται με το - διακριτικό έλεγχο πρόσβασης (Discretionary Access Control, <acronym> - DAC</acronym>, τις τυποποιημένες άδειες αρχείων και <acronym>IPC - </acronym> του System V στο &os;).</para> - - <para>Το κεφάλαιο αυτό εστιάζει στο πλαίσιο του Υποχρεωτικού Ελέγχου - Πρόσβασης (<acronym>MAC</acronym> Framework), και σε ένα σύνολο - πρόσθετων αρθρωμάτων για πολιτικές ασφάλειας, που ενεργοποιούν διάφορους - μηχανισμούς ασφάλειας.</para> - - <para>Αφού διαβάσετε αυτό το κεφάλαιο, θα ξέρετε:</para> - - <itemizedlist> - <listitem> - <para>Τι <acronym>MAC</acronym> αρθρώματα πολιτικών ασφαλείας - περιλαμβάνονται αυτή τη στιγμή στο &os; και τους σχετικούς - μηχανισμούς τους.</para> - </listitem> - - <listitem> - <para>Τι υλοποιούν τα <acronym>MAC</acronym> αρθρώματα πολιτικών - ασφαλείας καθώς και τη διαφορά μεταξύ μια χαρακτηρισμένης (labeled) - και μη χαρακτηρισμένης (non-labeled) πολιτικής.</para> - </listitem> - - <listitem> - <para>Πως να ρυθμίσετε αποδοτικά ένα σύστημα για χρήση του - πλαισίου λειτουργιών <acronym>MAC</acronym>.</para> - </listitem> - - <listitem> - <para>Πως να ρυθμίσετε τα διαφορετικά αρθρώματα πολιτικών ασφάλειας - τα οποία περιλαμβάνονται στο πλαίσιο λειτουργιών <acronym>MAC - </acronym>.</para> - </listitem> - - <listitem> - <para>Πως να υλοποιήσετε ένα πιο ασφαλές περιβάλλον, χρησιμοποιώντας - το πλαίσιο λειτουργιών <acronym>MAC</acronym> και τα παραδείγματα - που φαίνονται.</para> - </listitem> - - <listitem> - <para>Πως να ελέγξετε τη ρύθμιση του <acronym>MAC</acronym> για να - εξασφαλίσετε ότι έχει γίνει σωστή υλοποίηση του πλαισίου - λειτουργιών.</para> - </listitem> - </itemizedlist> - - <para>Πριν διαβάσετε αυτό το κεφάλαιο, θα πρέπει:</para> - - <itemizedlist> - <listitem> - <para>Να κατανοείτε τις βασικές έννοιες του &unix; και του &os;. - (<xref linkend="basics"/>).</para> - </listitem> - - <listitem> - <para>Να είστε εξοικειωμένος με τις βασικές έννοιες της ρύθμισης - και μεταγλώττισης του πυρήνα (<xref linkend="kernelconfig"/>).</para> - </listitem> - - <listitem> - <para>Να έχετε κάποια εξοικείωση με την ασφάλεια και πως αυτή - σχετίζεται με το &os; (<xref linkend="security"/>).</para> - </listitem> - </itemizedlist> - - <warning> - <para>Η κακή χρήση των πληροφοριών που παρέχονται εδώ μπορεί να - προκαλέσει απώλεια πρόσβασης στο σύστημα, εκνευρισμό στους χρήστες - ή αδυναμία πρόσβασης στις υπηρεσίες που παρέχονται από το Χ11. - Ακόμα πιο σημαντικό είναι ότι δεν πρέπει να βασίζεστε στο <acronym> - MAC</acronym> για την πλήρη ασφάλιση ενός συστήματος. Το πλαίσιο - λειτουργιών <acronym>MAC</acronym> παρέχει απλώς επιπλέον υποστήριξη - σε μια υπάρχουσα πολιτική ασφαλείας. Χωρίς σωστές πρακτικές και - τακτικούς ελέγχους ασφαλείας, το σύστημα δεν θα είναι ποτέ απόλυτα - ασφαλές.</para> - - <para>Θα πρέπει επίσης να σημειωθεί ότι τα παραδείγματα που περιέχονται - σε αυτό το κεφάλαιο είναι ακριβώς και μόνο αυτό: παραδείγματα. Δεν - συνίσταται να χρησιμοποιηθούν ακριβώς αυτές οι ρυθμίσεις σε ένα - σύστημα παραγωγής. Η υλοποίηση των διάφορων αρθρωμάτων πολιτικών - ασφαλείας απαιτεί αρκετή σκέψη και δοκιμές. Αν δεν κατανοείτε - την ακριβή λειτουργία τους, μπορεί να βρεθείτε στη θέση να ελέγχετε - ξανά ολόκληρο το σύστημα και να αλλάζετε ρυθμίσεις σε πολλά αρχεία και - καταλόγους.</para> - </warning> - - <sect2> - <title>Τι δεν Περιλαμβάνεται στο Κεφάλαιο</title> - - <para>Το κεφάλαιο αυτό καλύπτει μια ευρεία περιοχή προβλημάτων ασφαλείας - που σχετίζονται με το πλαίσιο λειτουργιών <acronym>MAC</acronym>. Δεν - θα καλυφθεί η ανάπτυξη νέων αρθρωμάτων πολιτικών ασφαλείας <acronym> - MAC</acronym>. Ένας αριθμός από αρθρώματα που περιλαμβάνονται στο - πλαίσιο <acronym>MAC</acronym>, έχουν ειδικά χαρακτηριστικά που - παρέχονται τόσο για δοκιμές όσο και για ανάπτυξη νέων αρθρωμάτων. Αυτά - περιλαμβάνουν τα &man.mac.test.4;, &man.mac.stub.4; και - &man.mac.none.4;. Για περισσότερες πληροφορίες σχετικά με αυτά τα - αρθρώματα και τους διάφορους μηχανισμούς που παρέχουν, παρακαλούμε - ανατρέξτε στις αντίστοιχες σελίδες manual.</para> - </sect2> - </sect1> - - <sect1 id="mac-inline-glossary"> - <title>Key Terms in this Chapter</title> - - <para>Before reading this chapter, a few key terms must be - explained. This will hopefully clear up any confusion that - may occur and avoid the abrupt introduction of new terms - and information.</para> - - <itemizedlist> - <listitem> - <para><emphasis>compartment</emphasis>: A compartment is a - set of programs and data to be partitioned or separated, - where users are given explicit access to specific components - of a system. Also, a compartment represents a grouping, - such as a work group, department, project, or topic. Using - compartments, it is possible to implement a need-to-know - security policy.</para> - </listitem> - - <listitem> - <para><emphasis>high water mark</emphasis>: A high water mark - policy is one which permits the raising of security levels - for the purpose of accessing higher level information. In - most cases, the original level is restored after the process - is complete. Currently, the &os; <acronym>MAC</acronym> - framework does not have a policy for this, but the definition - is included for completeness.</para> - </listitem> - - <listitem> - <para><emphasis>integrity</emphasis>: Integrity, as a key - concept, is the level of trust which can be placed on data. - As the integrity of the data is elevated, so does the ability - to trust that data.</para> - </listitem> - - <listitem> - <para><emphasis>label</emphasis>: A label is a security - attribute which can be applied to files, directories, or - other items in the system. It could be considered - a confidentiality stamp; when a label is placed on - a file it describes the security properties for that specific - file and will only permit access by files, users, resources, - etc. with a similar security setting. The meaning and - interpretation of label values depends on the policy configuration: while - some policies might treat a label as representing the - integrity or secrecy of an object, other policies might use - labels to hold rules for access.</para> - </listitem> - - <listitem> - <para><emphasis>level</emphasis>: The increased or decreased - setting of a security attribute. As the level increases, - its security is considered to elevate as well.</para> - </listitem> - - <listitem> - <para><emphasis>low water mark</emphasis>: A low water mark - policy is one which permits lowering of the security levels - for the purpose of accessing information which is less - secure. In most cases, the original security level of the - user is restored after the process is complete. The only - security policy module in &os; to use this is - &man.mac.lomac.4;.</para> - </listitem> - - <listitem> - <para><emphasis>multilabel</emphasis>: The - <option>multilabel</option> property is a file system option - which can be set in single user mode using the - &man.tunefs.8; utility, during the boot operation - using the &man.fstab.5; file, or during the creation of - a new file system. This option will permit an administrator - to apply different <acronym>MAC</acronym> labels on different - objects. This option - only applies to security policy modules which support labeling.</para> - </listitem> - - <listitem> - <para><emphasis>object</emphasis>: An object or system - object is an entity through which information flows - under the direction of a <emphasis>subject</emphasis>. - This includes directories, files, fields, screens, keyboards, - memory, magnetic storage, printers or any other data - storage/moving device. Basically, an object is a data container or - a system resource; access to an <emphasis>object</emphasis> - effectively means access to the data.</para> - </listitem> - - <listitem> - <para><emphasis>policy</emphasis>: A collection of rules - which defines how objectives are to be achieved. A - <emphasis>policy</emphasis> usually documents how certain - items are to be handled. This chapter will - consider the term <emphasis>policy</emphasis> in this - context as a <emphasis>security policy</emphasis>; i.e. - a collection of rules which will control the flow of data - and information and define whom will have access to that - data and information.</para> - </listitem> - - <listitem> - <para><emphasis>sensitivity</emphasis>: Usually used when - discussing <acronym>MLS</acronym>. A sensitivity level is - a term used to describe how important or secret the data - should be. As the sensitivity level increases, so does the - importance of the secrecy, or confidentiality of the data.</para> - </listitem> - - <listitem> - <para><emphasis>single label</emphasis>: A single label is - when the entire file system uses one label to - enforce access control over the flow of data. When a file - system has this set, which is any time when the - <option>multilabel</option> option is not set, all - files will conform to the same label setting.</para> - </listitem> - - <listitem> - <para><emphasis>subject</emphasis>: a subject is any - active entity that causes information to flow between - <emphasis>objects</emphasis>; e.g. a user, user processor, - system process, etc. On &os;, this is almost always a thread - acting in a process on behalf of a user.</para> - </listitem> - </itemizedlist> - </sect1> - - <sect1 id="mac-initial"> - <title>Explanation of MAC</title> - - <para>With all of these new terms in mind, consider how the - <acronym>MAC</acronym> framework augments the security of - the system as a whole. The various security policy modules provided by - the <acronym>MAC</acronym> framework could be used to - protect the network and file systems, block users from - accessing certain ports and sockets, and more. Perhaps - the best use of the policy modules is to blend them together, by loading - several security policy modules at a time for a multi-layered - security environment. In a multi-layered security environment, - multiple policy modules are in effect to keep security in check. This - is different to a hardening policy, which typically hardens - elements of a system that is used only for specific purposes. - The only downside is administrative overhead in cases of - multiple file system labels, setting network access control - user by user, etc.</para> - - <para>These downsides are minimal when compared to the lasting - effect of the framework; for instance, the ability to pick and choose - which policies are required for a specific configuration keeps - performance overhead down. The reduction of support for unneeded - policies can increase the overall performance of the system as well as - offer flexibility of choice. A good implementation would - consider the overall security requirements and effectively implement - the various security policy modules offered by the framework.</para> - - <para>Thus a system utilizing <acronym>MAC</acronym> features - should at least guarantee that a user will not be permitted - to change security attributes at will; all user utilities, - programs and scripts must work within the constraints of - the access rules provided by the selected security policy modules; and - that total control of the <acronym>MAC</acronym> access - rules are in the hands of the system administrator.</para> - - <para>It is the sole duty of the system administrator to - carefully select the correct security policy modules. Some environments - may need to limit access control over the network; in these - cases, the &man.mac.portacl.4;, &man.mac.ifoff.4; and even - &man.mac.biba.4; policy modules might make good starting points. In other - cases, strict confidentiality of file system objects might - be required. Policy modules such as &man.mac.bsdextended.4; - and &man.mac.mls.4; exist for this purpose.</para> - - <para>Policy decisions could be made based on network - configuration. Perhaps only certain users should be permitted - access to facilities provided by &man.ssh.1; to access the - network or the Internet. The &man.mac.portacl.4; would be - the policy module of choice for these situations. But what should be - done in the case of file systems? Should all access to certain - directories be severed from other groups or specific - users? Or should we limit user or utility access to specific - files by setting certain objects as classified?</para> - - <para>In the file system case, access to objects might be - considered confidential to some users, but not to others. - For an example, a large development team might be broken - off into smaller groups of individuals. Developers in - project A might not be permitted to access objects written - by developers in project B. Yet they might need to access - objects created by developers in project C; that is quite a - situation indeed. Using the different security policy modules provided by - the <acronym>MAC</acronym> framework; users could - be divided into these groups and then given access to the - appropriate areas without fear of information - leakage.</para> - - <para>Thus, each security policy module has a unique way of dealing with - the overall security of a system. Module selection should be based - on a well thought out security policy. In many cases, the - overall policy may need to be revised and reimplemented on - the system. Understanding the different security policy modules offered by - the <acronym>MAC</acronym> framework will help administrators - choose the best policies for their situations.</para> - - <para>The default &os; kernel does not include the option for - the <acronym>MAC</acronym> framework; thus the following - kernel option must be added before trying any of the examples or - information in this chapter:</para> - - <programlisting>options MAC</programlisting> - - <para>And the kernel will require a rebuild and a reinstall.</para> - - <caution> - <para>While the various manual pages for <acronym>MAC</acronym> - policy modules state that they may be built into the kernel, - it is possible to lock the system out of - the network and more. Implementing <acronym>MAC</acronym> - is much like implementing a firewall, care must be taken - to prevent being completely locked out of the system. The - ability to revert back to a previous configuration should be - considered while the implementation of <acronym>MAC</acronym> - remotely should be done with extreme caution.</para> - </caution> - </sect1> - - <sect1 id="mac-understandlabel"> - <title>Understanding MAC Labels</title> - - <para>A <acronym>MAC</acronym> label is a security attribute - which may be applied to subjects and objects throughout - the system.</para> - - <para>When setting a label, the user must be able to comprehend - what it is, exactly, that is being done. The attributes - available on an object depend on the policy module loaded, and that - policy modules interpret their attributes in different - ways. If improperly configured due to lack of comprehension, or - the inability to understand the implications, the result will - be the unexpected and perhaps, undesired, behavior of the - system.</para> - - <para>The security label on an object is used as a part of a - security access control decision by a policy. With some - policies, the label by itself contains all information necessary - to make a decision; in other models, the labels may be processed - as part of a larger rule set, etc.</para> - - <para>For instance, setting the label of <literal>biba/low</literal> - on a file will represent a label maintained by the Biba security policy module, - with a value of <quote>low</quote>.</para> - - <para>A few policy modules which support the labeling feature in - &os; offer three specific predefined labels. These - are the low, high, and equal labels. Although they enforce - access control in a different manner with each policy module, you - can be sure that the low label will be the lowest setting, - the equal label will set the subject or object to be disabled - or unaffected, and the high label will enforce the highest - setting available in the Biba and <acronym>MLS</acronym> - policy modules.</para> - - <para>Within single label file system environments, only one label may be - used on objects. This will enforce one set of - access permissions across the entire system and in many - environments may be all that is required. There are a few - cases where multiple labels may be set on objects - or subjects in the file system. For those cases, the - <option>multilabel</option> option may be passed to - &man.tunefs.8;.</para> - - <para>In the case of Biba and <acronym>MLS</acronym>, a numeric - label may be set to indicate the precise level of hierarchical - control. This numeric level is used to partition or sort - information into different groups of say, classification only - permitting access to that group or a higher group level.</para> - - <para>In most cases the administrator will only be setting up a - single label to use throughout the file system.</para> - - <para><emphasis>Hey wait, this is similar to <acronym>DAC</acronym>! - I thought <acronym>MAC</acronym> gave control strictly to the - administrator.</emphasis> That statement still holds true, to some - extent as <username>root</username> is the one in control and who - configures the policies so that users are placed in the - appropriate categories/access levels. Alas, many policy modules can - restrict the <username>root</username> user as well. Basic - control over objects will then be released to the group, but - <username>root</username> may revoke or modify the settings - at any time. This is the hierarchal/clearance model covered - by policies such as Biba and <acronym>MLS</acronym>.</para> - - <sect2> - <title>Label Configuration</title> - - <para>Virtually all aspects of label policy module configuration - will be performed using the base system utilities. These - commands provide a simple interface for object or subject - configuration or the manipulation and verification of - the configuration.</para> - - <para>All configuration may be done by use of the - &man.setfmac.8; and &man.setpmac.8; utilities. - The <command>setfmac</command> command is used to set - <acronym>MAC</acronym> labels on system objects while the - <command>setpmac</command> command is used to set the labels - on system subjects. Observe:</para> - - <screen>&prompt.root; <userinput>setfmac biba/high test</userinput></screen> - - <para>If no errors occurred with the command above, a prompt - will be returned. The only time these commands are not - quiescent is when an error occurred; similarly to the - &man.chmod.1; and &man.chown.8; commands. In some cases this - error may be a <errorname>Permission denied</errorname> and - is usually obtained when the label is being set or modified - on an object which is restricted.<footnote><para>Other conditions - may produce different failures. For instance, the file may not - be owned by the user attempting to relabel the object, the - object may not exist or may be read only. A mandatory policy - will not allow the process to relabel the file, maybe because - of a property of the file, a property of the process, or a - property of the proposed new label value. For example: a user - running at low integrity tries to change the label of a high - integrity file. Or perhaps a user running at low integrity - tries to change the label of a low integrity file to a high - integrity label.</para></footnote> The system administrator - may use the following commands to overcome this:</para> - - <screen>&prompt.root; <userinput>setfmac biba/high test</userinput> -<errorname>Permission denied</errorname> -&prompt.root; <userinput>setpmac biba/low setfmac biba/high test</userinput> -&prompt.root; <userinput>getfmac test</userinput> -test: biba/high</screen> - - <para>As we see above, <command>setpmac</command> - can be used to override the policy module's settings by assigning - a different label to the invoked process. The - <command>getpmac</command> utility is usually used with currently - running processes, such as <application>sendmail</application>: - although it takes a process ID in place of - a command the logic is extremely similar. If users - attempt to manipulate a file not in their access, subject to the - rules of the loaded policy modules, the - <errorname>Operation not permitted</errorname> error - will be displayed by the <function>mac_set_link</function> - function.</para> - - <sect3> - <title>Common Label Types</title> - - <para>For the &man.mac.biba.4;, &man.mac.mls.4; and - &man.mac.lomac.4; policy modules, the ability to assign - simple labels is provided. These take the form of high, - equal and low, what follows is a brief description of - what these labels provide:</para> - - <itemizedlist> - <listitem> - <para>The <literal>low</literal> label is considered the - lowest label setting an object or subject may have. - Setting this on objects or subjects will block their - access to objects or subjects marked high.</para> - </listitem> - - <listitem> - <para>The <literal>equal</literal> label should only be - placed on objects considered to be exempt from the - policy.</para> - </listitem> - - <listitem> - <para>The <literal>high</literal> label grants an object or - subject the highest possible setting.</para> - </listitem> - </itemizedlist> - - <para>With respect to each policy module, each of those settings - will instate a different information flow directive. Reading - the proper manual pages will further explain the traits of - these generic label configurations.</para> - - <sect4> - <title>Advanced Label Configuration</title> - - <para>Numeric grade labels are used for - <literal>comparison:compartment+compartment</literal>; thus - the following:</para> - - <programlisting>biba/10:2+3+6(5:2+3-20:2+3+4+5+6)</programlisting> - - <para>May be interpreted as:</para> - - <para><quote>Biba Policy Label</quote>/<quote>Grade 10</quote> - :<quote>Compartments 2, 3 and 6</quote>: - (<quote>grade 5 ...</quote>)</para> - - <para>In this example, the first grade would be considered - the <quote>effective grade</quote> with - <quote>effective compartments</quote>, the second grade - is the low grade and the last one is the high grade. - In most configurations these settings will not be used; - indeed, they offered for more advanced - configurations.</para> - - <para>When applied to system objects, they will only have a - current grade/compartments as opposed to system subjects - as they reflect the range of available rights in the system, - and network interfaces, where they are used for access - control.</para> - - <para>The grade and compartments in a subject and object pair - are used to construct a relationship referred to as - <quote>dominance</quote>, in which a subject dominates an - object, the object dominates the subject, neither dominates - the other, or both dominate each other. The - <quote>both dominate</quote> case occurs when the two labels - are equal. Due to the information flow nature of Biba, you - have rights to a set of compartments, - <quote>need to know</quote>, that might correspond to - projects, but objects also have a set of compartments. - Users may have to subset their rights using - <command>su</command> or <command>setpmac</command> in order - to access objects in a compartment from which they are not - restricted.</para> - </sect4> - </sect3> - - <sect3> - <title>Users and Label Settings</title> - - <para>Users themselves are required to have labels so that - their files and processes may properly interact with the - security policy defined on the system. This is - configured through the <filename>login.conf</filename> file - by use of login classes. Every policy module that uses labels - will implement the user class setting.</para> - - <para>An example entry containing every policy module setting is displayed - below:</para> - - <programlisting>default:\ - :copyright=/etc/COPYRIGHT:\ - :welcome=/etc/motd:\ - :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ - :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\ - :manpath=/usr/share/man /usr/local/man:\ - :nologin=/usr/sbin/nologin:\ - :cputime=1h30m:\ - :datasize=8M:\ - :vmemoryuse=100M:\ - :stacksize=2M:\ - :memorylocked=4M:\ - :memoryuse=8M:\ - :filesize=8M:\ - :coredumpsize=8M:\ - :openfiles=24:\ - :maxproc=32:\ - :priority=0:\ - :requirehome:\ - :passwordtime=91d:\ - :umask=022:\ - :ignoretime@:\ - :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]:</programlisting> - - <para>The <literal>label</literal> option is used to set the - user class default label which will be enforced by - <acronym>MAC</acronym>. Users will never be permitted to - modify this value, thus it can be considered not optional - in the user case. In a real configuration, however, the - administrator will never wish to enable every policy module. - It is recommended that the rest of this chapter be reviewed - before any of this configuration is implemented.</para> - - <note> - <para>Users may change their label after the initial login; - however, this change is subject constraints of the policy. - The example above tells the Biba policy that a process's - minimum integrity is 5, its maximum is 15, but the default - effective label is 10. The process will run at 10 until - it chooses to change label, perhaps due to the user using - the setpmac command, which will be constrained by Biba to - the range set at login.</para> - </note> - - <para>In all cases, after a change to - <filename>login.conf</filename>, the login class capability - database must be rebuilt using <command>cap_mkdb</command> - and this will be reflected throughout every forthcoming - example or discussion.</para> - - <para>It is useful to note that many sites may have a - particularly large number of users requiring several - different user classes. In depth planning is required - as this may get extremely difficult to manage.</para> - - <para>Future versions of &os; will include a new way to - deal with mapping users to labels; however, this will - not be available until some time after &os; 5.3.</para> - </sect3> - - <sect3> - <title>Network Interfaces and Label Settings</title> - - <para>Labels may also be set on network interfaces to help - control the flow of data across the network. In all cases - they function in the same way the policies function with - respect to objects. Users at high settings in - <literal>biba</literal>, for example, will not be permitted - to access network interfaces with a label of low.</para> - - <para>The <option>maclabel</option> may be passed to - <command>ifconfig</command> when setting the - <acronym>MAC</acronym> label on network interfaces. For - example:</para> - - <screen>&prompt.root; <userinput>ifconfig bge0 maclabel biba/equal</userinput></screen> - - <para>will set the <acronym>MAC</acronym> label of - <literal>biba/equal</literal> on the &man.bge.4; interface. - When using a setting similar to - <literal>biba/high(low-high)</literal> the entire label should - be quoted; otherwise an error will be returned.</para> - - <para>Each policy module which supports labeling has a tunable - which may be used to disable the <acronym>MAC</acronym> - label on network interfaces. Setting the label to - <option>equal</option> will have a similar effect. Review - the output from <command>sysctl</command>, the policy manual - pages, or even the information found later in this chapter - for those tunables.</para> - </sect3> - </sect2> - - <sect2> - <title>Singlelabel or Multilabel?</title> -<!-- Stopped here with my edits --> - <para>By default the system will use the - <option>singlelabel</option> option. But what does this - mean to the administrator? There are several differences - which, in their own right, offer pros and cons to the - flexibility in the systems security model.</para> - - <para>The <option>singlelabel</option> only permits for one - label, for instance <literal>biba/high</literal> to be used - for each subject or object. It provides for lower - administration overhead but decreases the flexibility of - policies which support labeling. Many administrators may - want to use the <option>multilabel</option> option in - their security policy.</para> - - <para>The <option>multilabel</option> option will permit each - subject or object to have its own independent - <acronym>MAC</acronym> label in - place of the standard <option>singlelabel</option> option - which will allow only one label throughout the partition. - The <option>multilabel</option> and <option>single</option> - label options are only required for the policies which - implement the labeling feature, including the Biba, Lomac, - <acronym>MLS</acronym> and <acronym>SEBSD</acronym> - policies.</para> - - <para>In many cases, the <option>multilabel</option> may not need - to be set at all. Consider the following situation and - security model:</para> - - <itemizedlist> - <listitem> - <para>&os; web-server using the <acronym>MAC</acronym> - framework and a mix of the various policies.</para> - </listitem> - - <listitem> - <para>This machine only requires one label, - <literal>biba/high</literal>, for everything in the system. - Here the file system would not require the - <option>multilabel</option> option as a single label - will always be in effect.</para> - </listitem> - - <listitem> - <para>But, this machine will be a web server and should have - the web server run at <literal>biba/low</literal> to prevent - write up capabilities. The Biba policy and how it works - will be discussed later, so if the previous comment was - difficult to interpret just continue reading and return. - The server could use a separate partition set at - <literal>biba/low</literal> for most if not all of its - runtime state. Much is lacking from this example, for - instance the restrictions on data, configuration and user - settings; however, this is just a quick example to prove the - aforementioned point.</para> - </listitem> - </itemizedlist> - - <para>If any of the non-labeling policies are to be used, - then the <option>multilabel</option> option would never - be required. These include the <literal>seeotheruids</literal>, - <literal>portacl</literal> and <literal>partition</literal> - policies.</para> - - <para>It should also be noted that using - <option>multilabel</option> with a partition and establishing - a security model based on <option>multilabel</option> - functionality could open the doors for higher administrative - overhead as everything in the file system would have a label. - This includes directories, files, and even device - nodes.</para> - - <para>The following command will set <option>multilabel</option> - on the file systems to have multiple labels. This may only be - done in single user mode:</para> - - <screen>&prompt.root; <userinput>tunefs -l enable /</userinput></screen> - - <para>This is not a requirement for the swap file - system.</para> - - <note> - <para>Some users have experienced problems with setting the - <option>multilabel</option> flag on the root partition. - If this is the case, please review the - <xref linkend="mac-troubleshoot"/> of this chapter.</para> - </note> - </sect2> - </sect1> - - <sect1 id="mac-planning"> - <title>Planning the Security Configuration</title> - - <para>Whenever a new technology is implemented, a planning phase is - always a good idea. During the planning stages, an administrator - should in general look at the <quote>big picture</quote>, trying - to keep in view at least the following:</para> - - <itemizedlist> - <listitem> - <para>The implementation requirements;</para> - </listitem> - - <listitem> - <para>The implementation goals;</para> - </listitem> - </itemizedlist> - - <para>For <acronym>MAC</acronym> installations, these include:</para> - - <itemizedlist> - <listitem> - <para>How to classify information and resources available on - the target systems.</para> - </listitem> - - <listitem> - <para>What sorts of information or resources to restrict - access to along with the type of restrictions that should be - applied.</para> - </listitem> - - <listitem> - <para>Which <acronym>MAC</acronym> module or modules will be - required to achieve this goal.</para> - </listitem> - </itemizedlist> - - <para>It is always possible to reconfigure and change the - system resources and security settings, it is quite often very inconvenient to - search through the system and fix existing files and user - accounts. Planning helps to ensure a trouble-free and efficient - trusted system implementation. A trial run of the trusted system, - including the configuration, is often vital and definitely - beneficial <emphasis>before</emphasis> a <acronym>MAC</acronym> - implementation is used on production systems. The idea of just - letting loose on a system - with <acronym>MAC</acronym> is like setting up for failure.</para> - - <para>Different environments may have explicit needs and - requirements. Establishing an in depth and complete security - profile will decrease the need of changes once the system - goes live. As such, the future sections will cover the - different modules available to administrators; describe their - use and configuration; and in some cases provide insight on - what situations they would be most suitable for. For instance, - a web server might roll out the &man.mac.biba.4; and - &man.mac.bsdextended.4; policies. In other cases, a machine - with very few local users, the &man.mac.partition.4; might - be a good choice.</para> - </sect1> - - <sect1 id="mac-modules"> - <title>Module Configuration</title> - - <para>Every module included with the <acronym>MAC</acronym> - framework may be either compiled into the kernel as noted above - or loaded as a run-time kernel module. - The recommended method is to add the module name to the - <filename>/boot/loader.conf</filename> file so that it will load - during the initial boot operation.</para> - - <para>The following sections will discuss the various - <acronym>MAC</acronym> modules and cover their features. - Implementing them into a specific environment will also - be a consideration of this chapter. Some modules support - the use of labeling, which is controlling access by enforcing - a label such as <quote>this is allowed and this is not</quote>. - A label configuration file may control how files may be accessed, - network communication can be exchanged, and more. The previous - section showed how the <option>multilabel</option> flag could - be set on file systems to enable per-file or per-partition - access control.</para> - - <para>A single label configuration would enforce only one label - across the system, that is why the <command>tunefs</command> - option is called <option>multilabel</option>.</para> - - <sect2 id="mac-seeotheruids"> - <title>The MAC seeotheruids Module</title> - - <indexterm> - <primary>MAC See Other UIDs Policy</primary> - </indexterm> - <para>Module name: <filename>mac_seeotheruids.ko</filename></para> - - <para>Kernel configuration line: - <literal>options MAC_SEEOTHERUIDS</literal></para> - - <para>Boot option: - <literal>mac_seeotheruids_load="YES"</literal></para> - - <para>The &man.mac.seeotheruids.4; module mimics and extends - the <literal>security.bsd.see_other_uids</literal> and - <literal>security.bsd.see_other_gids</literal> - <command>sysctl</command> tunables. This option does - not require any labels to be set before configuration and - can operate transparently with the other modules.</para> - - <para>After loading the module, the following - <command>sysctl</command> tunables may be used to control - the features:</para> - - <itemizedlist> - <listitem> - <para><literal>security.mac.seeotheruids.enabled</literal> - will enable the module's features and use the default - settings. These default settings will deny users the - ability to view processes and sockets owned by other - users.</para> - </listitem> - - <listitem> - <para> - <literal>security.mac.seeotheruids.specificgid_enabled</literal> - will allow a certain group to be exempt from this policy. - To exempt specific groups from this policy, use the - <literal>security.mac.seeotheruids.specificgid=<replaceable>XXX</replaceable></literal> - <command>sysctl</command> tunable. In the above example, - the <replaceable>XXX</replaceable> should be replaced with the - numeric group ID to be exempted.</para> - </listitem> - - <listitem> - <para> - <literal>security.mac.seeotheruids.primarygroup_enabled</literal> - is used to exempt specific primary groups from this policy. - When using this tunable, the - <literal>security.mac.seeotheruids.specificgid_enabled</literal> - may not be set.</para> - </listitem> - </itemizedlist> - </sect2> - </sect1> - - <sect1 id="mac-bsdextended"> - <title>The MAC bsdextended Module</title> - - <indexterm> - <primary>MAC</primary> - <secondary>File System Firewall Policy</secondary> - </indexterm> - <para>Module name: <filename>mac_bsdextended.ko</filename></para> - - <para>Kernel configuration line: - <literal>options MAC_BSDEXTENDED</literal></para> - - <para>Boot option: - <literal>mac_bsdextended_load="YES"</literal></para> - - <para>The &man.mac.bsdextended.4; module enforces the file system - firewall. This module's policy provides an extension to the - standard file system permissions model, permitting an - administrator to create a firewall-like ruleset to protect files, - utilities, and directories in the file system hierarchy. When - access to a file system object is attempted, the list of rules - is iterated until either a matching rule is located or the end - is reached. This behavior may be changed by the use of a - &man.sysctl.8; parameter, - security.mac.bsdextended.firstmatch_enabled. Similar to - other firewall modules in &os;, a file containing access control - rules can be created and read by the system at boot time using - an &man.rc.conf.5; variable.</para> - - <para>The rule list may be entered using a utility, &man.ugidfw.8;, - that has a syntax similar to that of &man.ipfw.8;. More tools - can be written by using the functions in the - &man.libugidfw.3; library.</para> - - <para>Extreme caution should be taken when working with this - module; incorrect use could block access to certain parts of - the file system.</para> - - <sect2> - <title>Examples</title> - - <para>After the &man.mac.bsdextended.4; module has - been loaded, the following command may be used to list the - current rule configuration:</para> - - <screen>&prompt.root; <userinput>ugidfw list</userinput> -0 slots, 0 rules</screen> - - <para>As expected, there are no rules defined. This means that - everything is still completely accessible. To create a rule - which will block all access by users but leave - <username>root</username> unaffected, simply run the - following command:</para> - - <screen>&prompt.root; <userinput>ugidfw add subject not uid root new object not uid root mode n</userinput></screen> - - <note> - <para>In releases prior to &os; 5.3, the - <parameter>add</parameter> parameter did not exist. In those - cases the <parameter>set</parameter> should be used - instead. See below for a command example.</para></note> - - <para>This is a very bad idea as it will block all users from - issuing even the most simple commands, such as - <command>ls</command>. A more patriotic list of rules - might be:</para> - - <screen>&prompt.root; <userinput>ugidfw set 2 subject uid <replaceable>user1</replaceable> object uid <replaceable>user2</replaceable> mode n</userinput> -&prompt.root; <userinput>ugidfw set 3 subject uid <replaceable>user1</replaceable> object gid <replaceable>user2</replaceable> mode n</userinput></screen> - - <para>This will block any and all access, including directory - listings, to <username><replaceable>user2</replaceable></username>'s home - directory from the username <username>user1</username>.</para> - - <para>In place of <username>user1</username>, the - <option>not uid <replaceable>user2</replaceable></option> could - be passed. This will enforce the same access restrictions - above for all users in place of just one user.</para> - - <note> - <para>The <username>root</username> user will be unaffected - by these changes.</para> - </note> - - <para>This should provide a general idea of how the - &man.mac.bsdextended.4; module may be used to help fortify - a file system. For more information, see the - &man.mac.bsdextended.4; and the &man.ugidfw.8; manual - pages.</para> - </sect2> - </sect1> - - <sect1 id="mac-ifoff"> - <title>The MAC ifoff Module</title> - - <indexterm> - <primary>MAC Interface Silencing Policy</primary> - </indexterm> - <para>Module name: <filename>mac_ifoff.ko</filename></para> - - <para>Kernel configuration line: - <literal>options MAC_IFOFF</literal></para> - - <para>Boot option: <literal>mac_ifoff_load="YES"</literal></para> - - <para>The &man.mac.ifoff.4; module exists solely to disable network - interfaces on the fly and keep network interfaces from being - brought up during the initial system boot. It does not require - any labels to be set up on the system, nor does it have a - dependency on other <acronym>MAC</acronym> modules.</para> - - <para>Most of the control is done through the - <command>sysctl</command> tunables listed below.</para> - - <itemizedlist> - <listitem> - <para><literal>security.mac.ifoff.lo_enabled</literal> will - enable/disable all traffic on the loopback (&man.lo.4;) - interface.</para> - </listitem> - - <listitem> - <para><literal>security.mac.ifoff.bpfrecv_enabled</literal> will - enable/disable all traffic on the Berkeley Packet Filter - interface (&man.bpf.4;)</para> - </listitem> - - <listitem> - <para><literal>security.mac.ifoff.other_enabled</literal> will - enable/disable traffic on all other interfaces.</para> - </listitem> - </itemizedlist> - - <para>One of the most common uses of &man.mac.ifoff.4; is network - monitoring in an environment where network traffic should not - be permitted during the boot sequence. Another suggested use - would be to write a script which uses - <filename role="package">security/aide</filename> to automatically - block network traffic if it finds new or altered files in - protected directories.</para> - </sect1> - - <sect1 id="mac-portacl"> - <title>The MAC portacl Module</title> - - <indexterm> - <primary>MAC Port Access Control List Policy</primary> - </indexterm> - <para>Module name: <filename>mac_portacl.ko</filename></para> - - <para>Kernel configuration line: - <literal>MAC_PORTACL</literal></para> - - <para>Boot option: <literal>mac_portacl_load="YES"</literal></para> - - <para>The &man.mac.portacl.4; module is used to limit binding to - local <acronym>TCP</acronym> and <acronym>UDP</acronym> ports - using a variety of <command>sysctl</command> variables. In - essence &man.mac.portacl.4; makes it possible to allow - non-<username>root</username> users to bind to specified - privileged ports, i.e. ports fewer than 1024.</para> - - <para>Once loaded, this module will enable the - <acronym>MAC</acronym> policy on all sockets. The following - tunables are available:</para> - - <itemizedlist> - <listitem> - <para><literal>security.mac.portacl.enabled</literal> will - enable/disable the policy completely.<footnote><para>Due to - a bug the <literal>security.mac.portacl.enabled</literal> - <command>sysctl</command> variable will not work on - &os; 5.2.1 or previous releases.</para></footnote></para> - </listitem> - - <listitem> - <para><literal>security.mac.portacl.port_high</literal> will set - the highest port number that &man.mac.portacl.4; - will enable protection for.</para> - </listitem> - - <listitem> - <para><literal>security.mac.portacl.suser_exempt</literal> will, - when set to a non-zero value, exempt the - <username>root</username> user from this policy.</para> - </listitem> - - <listitem> - <para><literal>security.mac.portacl.rules</literal> will - specify the actual mac_portacl policy; see below.</para> - </listitem> - </itemizedlist> - - <para>The actual <literal>mac_portacl</literal> policy, as - specified in the <literal>security.mac.portacl.rules</literal> - sysctl, is a text string of the form: - <literal>rule[,rule,...]</literal> with as many rules as - needed. Each rule is of the form: - <literal>idtype:id:protocol:port</literal>. The - <parameter>idtype</parameter> parameter can be - <literal>uid</literal> or <literal>gid</literal> and used to - interpret the <parameter>id</parameter> parameter as either a - user id or group id, respectively. The - <parameter>protocol</parameter> parameter is used to determine if - the rule should apply to <acronym>TCP</acronym> or - <acronym>UDP</acronym> by setting the parameter to - <literal>tcp</literal> or <literal>udp</literal>. The final - <parameter>port</parameter> parameter is the port number to allow - the specified user or group to bind to.</para> - - <note> - <para>Since the ruleset is interpreted directly by the kernel - only numeric values can be used for the user ID, group ID, and - port parameters. I.e. user, group, and port service names - cannot be used.</para> - </note> - - <para>By default, on &unix;-like systems, ports fewer than 1024 - can only be used by/bound to privileged processes, - i.e. those run as <username>root</username>. For - &man.mac.portacl.4; to allow non-privileged processes to bind - to ports below 1024 this standard &unix; restriction has to be - disabled. This can be accomplished by setting the &man.sysctl.8; - variables <literal>net.inet.ip.portrange.reservedlow</literal> and - <literal>net.inet.ip.portrange.reservedhigh</literal> - to zero.</para> - - <para>See the examples below or review the &man.mac.portacl.4; - manual page for further information.</para> - - <sect2> - <title>Examples</title> - - <para>The following examples should illuminate the above - discussion a little better:</para> - - <screen>&prompt.root; <userinput>sysctl security.mac.portacl.port_high=1023</userinput> -&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0</userinput></screen> - - <para>First we set &man.mac.portacl.4; to cover the standard - privileged ports and disable the normal &unix; bind - restrictions.</para> - - <screen>&prompt.root; <userinput>sysctl security.mac.portacl.suser_exempt=1</userinput></screen> - - <para>The <username>root</username> user should not be crippled - by this policy, thus set the - <literal>security.mac.portacl.suser_exempt</literal> to a - non-zero value. The &man.mac.portacl.4; module - has now been set up to behave the same way &unix;-like systems - behave by default.</para> - - <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:80:tcp:80</userinput></screen> - - <para>Allow the user with <acronym>UID</acronym> 80 (normally - the <username>www</username> user) to bind to port 80. - This can be used to allow the <username>www</username> - user to run a web server without ever having - <username>root</username> privilege.</para> - - <screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995</userinput></screen> - - <para>Permit the user with the <acronym>UID</acronym> of - 1001 to bind to the <acronym>TCP</acronym> ports 110 - (<quote>pop3</quote>) and 995 (<quote>pop3s</quote>). - This will permit this user to start a server that accepts - connections on ports 110 and 995.</para> - </sect2> - </sect1> - - <sect1 id="mac-partition"> - <title>The MAC partition Module</title> - - <indexterm> - <primary>MAC Process Partition Policy</primary> - </indexterm> - <para>Module name: <filename>mac_partition.ko</filename></para> - - <para>Kernel configuration line: - <literal>options MAC_PARTITION</literal></para> - - <para>Boot option: - <literal>mac_partition_load="YES"</literal></para> - - <para>The &man.mac.partition.4; policy will drop processes into - specific <quote>partitions</quote> based on their - <acronym>MAC</acronym> label. Think of it as a special - type of &man.jail.8;, though that is hardly a worthy - comparison.</para> - - <para>This is one module that should be added to the - &man.loader.conf.5; file so that it loads - and enables the policy during the boot process.</para> - - <para>Most configuration for this policy is done using - the &man.setpmac.8; utility which will be explained below. - The following <command>sysctl</command> tunable is - available for this policy:</para> - - <itemizedlist> - <listitem> - <para><literal>security.mac.partition.enabled</literal> will - enable the enforcement of <acronym>MAC</acronym> process - partitions.</para> - </listitem> - </itemizedlist> - - <para>When this policy is enabled, users will only be permitted - to see their processes, and any others within their partition, - but will not be permitted to work with - utilities outside the scope of this partition. For instance, a user in the - <literal>insecure</literal> class above will not be permitted - to access the <command>top</command> command as well as many - other commands that must spawn a process.</para> - - <para>To set or drop utilities into a partition label, use the - <command>setpmac</command> utility:</para> - - <screen>&prompt.root; <userinput>setpmac partition/13 top</userinput></screen> - - <para>This will add the <command>top</command> command to the - label set on users in the <literal>insecure</literal> class. - Note that all processes spawned by users - in the <literal>insecure</literal> class will stay in the - <literal>partition/13</literal> label.</para> - - <sect2> - <title>Examples</title> - - <para>The following command will show you the partition label - and the process list:</para> - - <screen>&prompt.root; <userinput>ps Zax</userinput></screen> - - <para>This next command will allow the viewing of another - user's process partition label and that user's currently - running processes:</para> - - <screen>&prompt.root; <userinput>ps -ZU trhodes</userinput></screen> - - <note> - <para>Users can see processes in <username>root</username>'s - label unless the &man.mac.seeotheruids.4; policy is - loaded.</para> - </note> - - <para>A really crafty implementation could have all of the - services disabled in <filename>/etc/rc.conf</filename> and - started by a script that starts them with the proper - labeling set.</para> - - <note> - <para>The following policies support integer settings - in place of the three default labels offered. These options, - including their limitations, are further explained in - the module manual pages.</para> - </note> - </sect2> - </sect1> - - <sect1 id="mac-mls"> - <title>The MAC Multi-Level Security Module</title> - - <indexterm> - <primary>MAC Multi-Level Security Policy</primary> - </indexterm> - <para>Module name: <filename>mac_mls.ko</filename></para> - - <para>Kernel configuration line: - <literal>options MAC_MLS</literal></para> - - <para>Boot option: <literal>mac_mls_load="YES"</literal></para> - - <para>The &man.mac.mls.4; policy controls access between subjects - and objects in the system by enforcing a strict information - flow policy.</para> - - <para>In <acronym>MLS</acronym> environments, a - <quote>clearance</quote> level is set in each subject or objects - label, along with compartments. Since these clearance or - sensibility levels can reach numbers greater than six thousand; - it would be a daunting task for any system administrator to - thoroughly configure each subject or object. Thankfully, three - <quote>instant</quote> labels are already included in this - policy.</para> - - <para>These labels are <literal>mls/low</literal>, - <literal>mls/equal</literal> and <literal>mls/high</literal>. - Since these labels are described in depth in the manual page, - they will only get a brief description here:</para> - - <itemizedlist> - <listitem> - <para>The <literal>mls/low</literal> label contains a low - configuration which permits it to be dominated by all other - objects. Anything labeled with <literal>mls/low</literal> - will have a low clearance level and not be permitted to access - information of a higher level. In addition, this label will - prevent objects of a higher clearance level from writing or - passing information on to them.</para> - </listitem> - - <listitem> - <para>The <literal>mls/equal</literal> label should be - placed on objects considered to be exempt from the - policy.</para> - </listitem> - - <listitem> - <para>The <literal>mls/high</literal> label is the highest level - of clearance possible. Objects assigned this label will - hold dominance over all other objects in the system; however, - they will not permit the leaking of information to objects - of a lower class.</para> - </listitem> - </itemizedlist> - - <para><acronym>MLS</acronym> provides for:</para> - - <itemizedlist> - <listitem> - <para>A hierarchical security level with a set of non - hierarchical categories;</para> - </listitem> - - <listitem> - <para>Fixed rules: no read up, no write down (a subject can - have read access to objects on its own level or below, but - not above. Similarly, a subject can have write access to - objects on its own level or above but not beneath.);</para> - </listitem> - - <listitem> - <para>Secrecy (preventing inappropriate disclosure - of data);</para> - </listitem> - - <listitem> - <para>Basis for the design of systems that concurrently handle - data at multiple sensitivity levels (without leaking - information between secret and confidential).</para> - </listitem> - </itemizedlist> - - <para>The following <command>sysctl</command> tunables are - available for the configuration of special services and - interfaces:</para> - - <itemizedlist> - <listitem> - <para><literal>security.mac.mls.enabled</literal> is used to - enable/disable the <acronym>MLS</acronym> policy.</para> - </listitem> - - <listitem> - <para><literal>security.mac.mls.ptys_equal</literal> will label - all &man.pty.4; devices as <literal>mls/equal</literal> during - creation.</para> - </listitem> - - <listitem> - <para><literal>security.mac.mls.revocation_enabled</literal> is - used to revoke access to objects after their label changes - to a label of a lower grade.</para> - </listitem> - - <listitem> - <para><literal>security.mac.mls.max_compartments</literal> is - used to set the maximum number of compartment levels with - objects; basically the maximum compartment number allowed - on a system.</para> - </listitem> - </itemizedlist> - - <para>To manipulate the <acronym>MLS</acronym> labels, the - &man.setfmac.8; command has been provided. To assign a label - to an object, issue the following command:</para> - - <screen>&prompt.root; <userinput>setfmac mls/5 test</userinput></screen> - - <para>To get the <acronym>MLS</acronym> label for the file - <filename>test</filename> issue the following command:</para> - - <screen>&prompt.root; <userinput>getfmac test</userinput></screen> - - <para>This is a summary of the <acronym>MLS</acronym> - policy's features. Another approach is to create a master policy - file in <filename class="directory">/etc</filename> which - specifies the <acronym>MLS</acronym> policy information and to - feed that file into the <command>setfmac</command> command. This - method will be explained after all policies are covered.</para> - - <sect2> - <title>Planning Mandatory Sensitivity</title> - - <para>With the Multi-Level Security Policy Module, an - administrator plans for controlling the flow of sensitive - information. By default, with its block read up block write - down nature, the system defaults everything to a low state. - Everything is accessible and an administrator - slowly changes this during the configuration stage; augmenting - the confidentiality of the information.</para> - - <para>Beyond the three basic label options above, an administrator - may group users and groups as required to block the information - flow between them. It might be easier to look at the - information in clearance levels familiarized with words, for - instance classifications such as - <literal>Confidential</literal>, <literal>Secret</literal>, - and <literal>Top Secret</literal>. Some administrators might - just create different groups based on project levels. - Regardless of classification method, a well thought out plan - must exist before implementing such a restrictive policy.</para> - - <para>Some example situations for this security policy module - could be an e-commerce web server, a file server holding critical - company information, and financial institution environments. - The most unlikely place would be a personal workstation with - only two or three users.</para> - </sect2> - </sect1> - - <sect1 id="mac-biba"> - <title>The MAC Biba Module</title> - - <indexterm> - <primary>MAC Biba Integrity Policy</primary> - </indexterm> - <para>Module name: <filename>mac_biba.ko</filename></para> - - <para>Kernel configuration line: <literal>options MAC_BIBA</literal></para> - - <para>Boot option: <literal>mac_biba_load="YES"</literal></para> - - <para>The &man.mac.biba.4; module loads the <acronym>MAC</acronym> - Biba policy. This policy works much like that of the - <acronym>MLS</acronym> policy with the exception that the rules - for information flow - are slightly reversed. This is said to prevent the downward - flow of sensitive information whereas the <acronym>MLS</acronym> - policy prevents the upward flow of sensitive information; thus, - much of this section can apply to both policies.</para> - - <para>In Biba environments, an <quote>integrity</quote> label is - set on each subject or object. These labels are made up of - hierarchal grades, and non-hierarchal components. As an object's - or subject's grade ascends, so does its integrity.</para> - - <para>Supported labels are <literal>biba/low</literal>, - <literal>biba/equal</literal>, and <literal>biba/high</literal>; - as explained below:</para> - - <itemizedlist> - <listitem> - <para>The <literal>biba/low</literal> label is considered the - lowest integrity an object or subject may have. Setting - this on objects or subjects will block their write access - to objects or subjects marked high. They still have read - access though.</para> - </listitem> - - <listitem> - <para>The <literal>biba/equal</literal> label should only be - placed on objects considered to be exempt from the - policy.</para> - </listitem> - - <listitem> - <para>The <literal>biba/high</literal> label will permit - writing to objects set at a lower label, but not - permit reading that object. It is recommended that this - label be placed on objects that affect the integrity of - the entire system.</para> - </listitem> - </itemizedlist> - - <para>Biba provides for:</para> - - <itemizedlist> - <listitem> - <para>Hierarchical integrity level with a set of non - hierarchical integrity categories;</para> - </listitem> - - <listitem> - <para>Fixed rules: no write up, no read down (opposite of - <acronym>MLS</acronym>). A subject can have write access - to objects on its own level or below, but not above. Similarly, a - subject can have read access to objects on its own level - or above, but not below;</para> - </listitem> - - <listitem> - <para>Integrity (preventing inappropriate modification of - data);</para> - </listitem> - - <listitem> - <para>Integrity levels (instead of MLS sensitivity - levels).</para> - </listitem> - </itemizedlist> - - <para>The following <command>sysctl</command> tunables can - be used to manipulate the Biba policy.</para> - - <itemizedlist> - <listitem> - <para><literal>security.mac.biba.enabled</literal> may be used - to enable/disable enforcement of the Biba policy on the - target machine.</para> - </listitem> - - <listitem> - <para><literal>security.mac.biba.ptys_equal</literal> may be - used to disable the Biba policy on &man.pty.4; - devices.</para> - </listitem> - - <listitem> - <para><literal>security.mac.biba.revocation_enabled</literal> - will force the revocation of access to objects if the label - is changed to dominate the subject.</para> - </listitem> - </itemizedlist> - - <para>To access the Biba policy setting on system objects, use - the <command>setfmac</command> and <command>getfmac</command> - commands:</para> - - <screen>&prompt.root; <userinput>setfmac biba/low test</userinput> -&prompt.root; <userinput>getfmac test</userinput> -test: biba/low</screen> - - <sect2> - <title>Planning Mandatory Integrity</title> - - <para>Integrity, different from sensitivity, guarantees that the - information will never be manipulated by untrusted parties. - This includes information passed between subjects, objects, - and both. It ensures that users will only be able to modify - and in some cases even access information they explicitly need - to.</para> - - <para>The &man.mac.biba.4; security policy module permits an - administrator to address which files and programs a user or - users may see and invoke while assuring that the programs and - files are free from threats and trusted by the system for that - user, or group of users.</para> - - <para>During the initial planning phase, an administrator must be - prepared to partition users into grades, levels, and areas. - Users will be blocked access not only to data but programs - and utilities both before and after they start. The system will - default to a high label once this policy module is enabled, and - it is up to the administrator to configure the different grades - and levels for users. Instead of using clearance levels as - described above, a good planning method could include topics. - For instance, only allow developers modification access to the source code - repository, source code compiler, and other development - utilities. While other users would be grouped into other - categories such as testers, designers, or just ordinary - users and would only be permitted read access.</para> - - <para>With its natural security control, a lower integrity subject - is unable to write to a higher integrity subject; a higher - integrity subject cannot observe or read a lower integrity - object. Setting a label at the lowest possible grade could make - it inaccessible to subjects. Some prospective environments for - this security policy module would include a constrained web - server, development and test machine, and source code - repository. A less useful implementation would be a personal - workstation, a machine used as a router, or a network - firewall.</para> - </sect2> - </sect1> - - <sect1 id="mac-lomac"> - <title>The MAC LOMAC Module</title> - - <indexterm> - <primary>MAC LOMAC</primary> - </indexterm> - <para>Module name: <filename>mac_lomac.ko</filename></para> - - <para>Kernel configuration line: <literal>options MAC_LOMAC</literal></para> - <para>Boot option: <literal>mac_lomac_load="YES"</literal></para> - - <para>Unlike the <acronym>MAC</acronym> Biba policy, the - &man.mac.lomac.4; policy permits access to lower integrity - objects only after decreasing the integrity level to not disrupt - any integrity rules.</para> - - <para>The <acronym>MAC</acronym> version of the Low-watermark - integrity policy, not to be confused with the older &man.lomac.4; - implementation, works almost identically to Biba, but with the - exception of using floating labels to support subject - demotion via an auxiliary grade compartment. This secondary - compartment takes the form of <literal>[auxgrade]</literal>. - When assigning a lomac policy with an auxiliary grade, it - should look a little bit like: <literal>lomac/10[2]</literal> - where the number two (2) is the auxiliary grade.</para> - - <para>The <acronym>MAC</acronym> LOMAC policy relies on the - ubiquitous labeling of all system objects with integrity labels, - permitting subjects to read from low integrity objects and then - downgrading the label on the subject to prevent future writes to - high integrity objects. This is the - <literal>[auxgrade]</literal> option discussed above, thus the - policy may provide for greater compatibility and require less - initial configuration than Biba.</para> - - <sect2> - <title>Examples</title> - - <para>Like the Biba and <acronym>MLS</acronym> policies; - the <command>setfmac</command> and <command>setpmac</command> - utilities may be used to place labels on system objects:</para> - - <screen>&prompt.root; <userinput>setfmac /usr/home/trhodes lomac/high[low]</userinput> -&prompt.root; <userinput>getfmac /usr/home/trhodes</userinput> lomac/high[low]</screen> - - <para>Notice the auxiliary grade here is <literal>low</literal>, - this is a feature provided only by the <acronym>MAC</acronym> - LOMAC policy.</para> - </sect2> - </sect1> - - <sect1 id="mac-implementing"> - <title>Nagios in a MAC Jail</title> - - <indexterm> - <primary>Nagios in a MAC Jail</primary> - </indexterm> - - <para>The following demonstration will implement a secure - environment using various <acronym>MAC</acronym> modules - with properly configured policies. This is only a test and - should not be considered the complete answer to everyone's - security woes. Just implementing a policy and ignoring it - never works and could be disastrous in a production - environment.</para> - - <para>Before beginning this process, the - <literal>multilabel</literal> option must be set on each file - system as stated at the beginning of this chapter. Not doing - so will result in errors. While at it, ensure that the - <filename role="port">net-mngt/nagios-plugins</filename>, - <filename role="port">net-mngt/nagios</filename>, and - <filename role="port">www/apache13</filename> ports are all - installed, configured, and working correctly.</para> - - <sect2> - <title>Create an insecure User Class</title> - - <para>Begin the procedure by adding the following user class - to the <filename>/etc/login.conf</filename> file:</para> - - <programlisting>insecure:\ -:copyright=/etc/COPYRIGHT:\ -:welcome=/etc/motd:\ -:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ -:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin -:manpath=/usr/share/man /usr/local/man:\ -:nologin=/usr/sbin/nologin:\ -:cputime=1h30m:\ -:datasize=8M:\ -:vmemoryuse=100M:\ -:stacksize=2M:\ -:memorylocked=4M:\ -:memoryuse=8M:\ -:filesize=8M:\ -:coredumpsize=8M:\ -:openfiles=24:\ -:maxproc=32:\ -:priority=0:\ -:requirehome:\ -:passwordtime=91d:\ -:umask=022:\ -:ignoretime@:\ -:label=biba/10(10-10):</programlisting> - - <para>And adding the following line to the default user - class:</para> - - <programlisting>:label=biba/high:</programlisting> - - <para>Once this is completed, the following command must be - issued to rebuild the database:</para> - - <screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen> - </sect2> - - <sect2> - <title>Boot Configuration</title> - - <para>Do not reboot yet, just add the following lines to - <filename>/boot/loader.conf</filename> so the required - modules will load during system initialization:</para> - - <programlisting>mac_biba_load="YES" -mac_seeotheruids_load="YES"</programlisting> - </sect2> - - <sect2> - <title>Configure Users</title> - - <para>Set the <username>root</username> user to the default - class using:</para> - - <screen>&prompt.root; <userinput>pw usermod root -L default</userinput></screen> - - <para>All user accounts that are not <username>root</username> - or system users will now require a login class. The login - class is required otherwise users will be refused access - to common commands such as &man.vi.1;. - The following <command>sh</command> script should do the - trick:</para> - - <screen>&prompt.root; <userinput>for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \</userinput> - <userinput>/etc/passwd`; do pw usermod $x -L default; done;</userinput></screen> - - <para>Drop the <username>nagios</username> and - <username>www</username> users into the insecure class:</para> - - <screen>&prompt.root; <userinput>pw usermod nagios -L insecure</userinput></screen> - <screen>&prompt.root; <userinput>pw usermod www -L insecure</userinput></screen> - </sect2> - - <sect2> - <title>Create the Contexts File</title> - - <para>A contexts file should now be created; the following example - file should be placed in - <filename>/etc/policy.contexts</filename>.</para> - - <programlisting># This is the default BIBA policy for this system. - -# System: -/var/run biba/equal -/var/run/* biba/equal - -/dev biba/equal -/dev/* biba/equal - -/var biba/equal -/var/spool biba/equal -/var/spool/* biba/equal - -/var/log biba/equal -/var/log/* biba/equal - -/tmp biba/equal -/tmp/* biba/equal -/var/tmp biba/equal -/var/tmp/* biba/equal - -/var/spool/mqueue biba/equal -/var/spool/clientmqueue biba/equal - -# For Nagios: -/usr/local/etc/nagios -/usr/local/etc/nagios/* biba/10 - -/var/spool/nagios biba/10 -/var/spool/nagios/* biba/10 - -# For apache -/usr/local/etc/apache biba/10 -/usr/local/etc/apache/* biba/10</programlisting> - - <para>This policy will enforce security by setting restrictions - on the flow of information. In this specific configuration, - users, <username>root</username> and others, should never be - allowed to access <application>Nagios</application>. - Configuration files and processes that are a part of - <application>Nagios</application> will be completely self - contained or jailed.</para> - - <para>This file may now be read into our system by issuing the - following command:</para> - - <screen>&prompt.root; <userinput>setfsmac -ef /etc/policy.contexts /</userinput> -&prompt.root; <userinput>setfsmac -ef /etc/policy.contexts /</userinput></screen> - - <note> - <para>The above file system layout may be different depending - on environment; however, it must be run on every single file - system.</para> - </note> - - <para>The <filename>/etc/mac.conf</filename> file requires - the following modifications in the main section:</para> - - <programlisting>default_labels file ?biba -default_labels ifnet ?biba -default_labels process ?biba -default_labels socket ?biba</programlisting> - </sect2> - - <sect2> - <title>Enable Networking</title> - - <para>Add the following line to - <filename>/boot/loader.conf</filename>:</para> - - <programlisting>security.mac.biba.trust_all_interfaces=1</programlisting> - - <para>And the following to the network card configuration stored - in <filename>rc.conf</filename>. If the primary Internet - configuration is done via <acronym>DHCP</acronym>, this may - need to be configured manually after every system boot:</para> - - <programlisting>maclabel biba/equal</programlisting> - </sect2> - - <sect2> - <title>Testing the Configuration</title> - - <indexterm> - <primary>MAC Configuration Testing</primary> - </indexterm> - - <para>Ensure that the web server and - <application>Nagios</application> will not be started - on system initialization, and reboot. Ensure the - <username>root</username> user cannot access any of the files - in the <application>Nagios</application> configuration - directory. If <username>root</username> can issue an &man.ls.1; - command on <filename>/var/spool/nagios</filename>, then something - is wrong. Otherwise a <quote>permission denied</quote> error - should be returned.</para> - - <para>If all seems well, <application>Nagios</application>, - <application>Apache</application>, and - <application>Sendmail</application> can now be started in a way - fitting of the security policy. The following commands will - make this happen:</para> - - <screen>&prompt.root; <userinput>cd /etc/mail && make stop && \ -setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \ -setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></screen> - - <para>Double check to ensure that everything is working - properly. If not, check the log files or error messages. Use - the &man.sysctl.8; utility to disable the &man.mac.biba.4; - security policy module enforcement and try starting everything - again, like normal.</para> - - <note> - <para>The <username>root</username> user can change the security - enforcement and edit the configuration files without fear. - The following command will permit the degradation of the - security policy to a lower grade for a newly spawned - shell:</para> - - <screen>&prompt.root; <userinput>setpmac biba/10 csh</userinput></screen> - - <para>To block this from happening, force the user into a range - via &man.login.conf.5;. If &man.setpmac.8; attempts to run - a command outside of the compartment's range, an error will - be returned and the command will not be executed. In this - case, setting root to - <literal>biba/high(high-high)</literal>.</para> - </note> - </sect2> - </sect1> - - <sect1 id="mac-userlocked"> - <title>User Lock Down</title> - - <para>This example considers a relatively small, fewer than fifty - users, storage system. Users would have login capabilities, and - be permitted to not only store data but access resources as - well.</para> - - <para>For this scenario, the &man.mac.bsdextended.4; mixed with - &man.mac.seeotheruids.4; could co-exist and block access not - only to system objects but to hide user processes as well.</para> - - <para>Begin by adding the following lines to - <filename>/boot/loader.conf</filename>:</para> - - <programlisting>mac_seeotheruids_enabled="YES"</programlisting> - - <para>The &man.mac.bsdextended.4; security policy module may be - activated through the use of the following rc.conf - variable:</para> - - <programlisting>ugidfw_enable="YES"</programlisting> - - <para>Default rules stored in - <filename>/etc/rc.bsdextended</filename> will be loaded at system - initialization; however, the default entries may need - modification. Since this machine is expected only to service - users, everything may be left commented out except the last - two. These will force the loading of user owned system objects - by default.</para> - - <para>Add the required users to this machine and reboot. For - testing purposes, try logging in as a different user across two - consoles. Run the <command>ps aux</command> command to see if - processes of other users are visible. Try to run &man.ls.1; on - another users home directory, it should fail.</para> - - <para>Do not try to test with the <username>root</username> user - unless the specific <command>sysctl</command>s have been modified - to block super user access.</para> - - <note> - <para>When a new user is added, their &man.mac.bsdextended.4; - rule will not be in the ruleset list. To update the ruleset - quickly, simply unload the security policy module and reload - it again using the &man.kldunload.8; and &man.kldload.8; - utilities.</para> - </note> - </sect1> - - <sect1 id="mac-troubleshoot"> - <title>Troubleshooting the MAC Framework</title> - - <indexterm> - <primary>MAC Troubleshooting</primary> - </indexterm> - - <para>During the development stage, a few users reported problems - with normal configuration. Some of these problems - are listed below:</para> - - <sect2> - <title>The <option>multilabel</option> option cannot be enabled on - <filename>/</filename></title> - - <para>The <option>multilabel</option> flag does not stay - enabled on my root (<filename>/</filename>) partition!</para> - - - <para>It seems that one out of every fifty users has this - problem, indeed, we had this problem during our initial - configuration. Further observation of this so called - <quote>bug</quote> has lead me to believe that it is a - result of either incorrect documentation or misinterpretation - of the documentation. Regardless of why it happened, the - following steps may be taken to resolve it:</para> - - <procedure> - <step> - <para>Edit <filename>/etc/fstab</filename> and set the root - partition at <option>ro</option> for read-only.</para> - </step> - - <step> - <para>Reboot into single user mode.</para> - </step> - - <step> - <para>Run <command>tunefs</command> <option>-l enable</option> - on <filename>/</filename>.</para> - </step> - - <step> - <para>Reboot the system into normal mode.</para> - </step> - - <step> - <para>Run <command>mount</command> <option>-urw</option> - <filename>/</filename> and change the <option>ro</option> - back to <option>rw</option> in <filename>/etc/fstab</filename> - and reboot the system again.</para> - </step> - - <step> - <para>Double-check the output from the - <command>mount</command> to ensure that - <option>multilabel</option> has been properly set on the - root file system.</para> - </step> - </procedure> - </sect2> - - <sect2> - <title>Cannot start a X11 server after <acronym>MAC</acronym></title> - - <para>After establishing a secure environment with - <acronym>MAC</acronym>, I am no longer able to start - X!</para> - - <para>This could be caused by the <acronym>MAC</acronym> - <literal>partition</literal> policy or by a mislabeling in - one of the <acronym>MAC</acronym> labeling policies. To - debug, try the following:</para> - - <procedure> - <step> - <para>Check the error message; if the user is in the - <literal>insecure</literal> class, the - <literal>partition</literal> policy may be the culprit. - Try setting the user's class back to the - <literal>default</literal> class and rebuild the database - with the <command>cap_mkdb</command> command. If this - does not alleviate the problem, go to step two.</para> - </step> - - <step> - <para>Double-check the label policies. Ensure that the - policies are set correctly for the user in question, the - X11 application, and - the <filename class="directory">/dev</filename> - entries.</para> - </step> - - <step> - <para>If neither of these resolve the problem, send the - error message and a description of your environment to - the TrustedBSD discussion lists located at the - <ulink url="http://www.TrustedBSD.org">TrustedBSD</ulink> - website or to the &a.questions; - mailing list.</para> - </step> - </procedure> - </sect2> - - <sect2> - <title>Error: &man..secure.path.3; cannot stat <filename>.login_conf</filename></title> - - <para>When I attempt to switch from the <username>root</username> - to another user in the system, the error message - <errorname>_secure_path: unable to state .login_conf</errorname>.</para> - - <para>This message is usually shown when the user has a higher - label setting then that of the user whom they are attempting to - become. For instance a user on the system, - <username>joe</username>, has a default label of - <option>biba/low</option>. The <username>root</username> user, - who has a label of <option>biba/high</option>, cannot view - <username>joe</username>'s home directory. This will happen - regardless if <username>root</username> has used the - <command>su</command> command to become <username>joe</username>, - or not. In this scenario, the Biba integrity model will not - permit <username>root</username> to view objects set at a lower - integrity level.</para> - </sect2> - - <sect2> - <title>The <username>root</username> username is broken!</title> - - <para>In normal or even single user mode, the - <username>root</username> is not recognized. The - <command>whoami</command> command returns 0 (zero) and - <command>su</command> returns <errorname>who are you?</errorname>. - What could be going on?</para> - - <para>This can happen if a labeling policy has been disabled, - either by a &man.sysctl.8; or the policy module was unloaded. - If the policy is being disabled or has been temporarily - disabled, then the login capabilities database needs to be - reconfigured with the <option>label</option> option being - removed. Double check the <filename>login.conf</filename> - file to ensure that all <option>label</option> options have - been removed and rebuild the database with the - <command>cap_mkdb</command> command.</para> - - <para>This may also happen if a policy restricts access to the - <filename>master.passwd</filename> file or database. Usually - caused by an administrator altering the file under a label - which conflicts with the general policy being used by the - system. In these cases, the user information would be read - by the system and access would be blocked as the file has - inherited the new label. Disable the policy via a - &man.sysctl.8; and everything should return to normal.</para> - </sect2> - </sect1> -</chapter> |