Section 8.4. Other Impacts of MLS


8.4. Other Impacts of MLS

This chapter describes the basic mechanisms that enable you to define an MLS policy in SELinux; however, it does not describe a full policy for MLS. Unlike type enforcement, which is flexible and adaptable, MLS is intended to strictly and inflexibly enforce a single security invariant ("no write down, no read up"). This singular, inflexible focus is important for the protection of strictly hierarchically related sensitive data (such as national secrets). However, it presents many challenges that you must address as a secure system designer that are beyond the scope of this book.[2]

[2] For additional information on the challenges of building MLS trusted systems, see Building a Secure Computer System by Morrie Gasser and Van Nostran Reinhold, New York, 1988, which is out of print but freely available at http://nucia.ist.unomaha.edu/library/gasserbook.pdf.

Because in SELinux the MLS feature extends the security context, everywhere you specify a security context you must now include security level information. One statement this impacts is the user statement described in Chapter 6. For MLS systems, all users must have a defined clearance security level, which represents the highest-level process users may run on their behalf. For MLS, the syntax of the user statement changes to this:

user username roles role_set  level default_level range allowed_range ;


The username and role_set arguments are the same as before. However, we add two new keywords that define the user's default login security level (level) and the range of security levels that a user is allowed to run processes or log in (range). The default level is a single valid security level, and the allowed range is a range of security levels from low to high. For example:

user joe roles user_r level s0 range s0 - s3:c0.c4;


This statement assigns the user joe with the default login level of s0 (the lowest sensitivity we defined earlier, with no categories) and allows the user to log in at any level ranging from s0 with no categories to s3 with all the categories we defined earlier (c0.c4). For example, the user is allowed to log in with a security level of s1:c1.c2 but would not be allowed to log in with a security level s4:c0 because this latter level is not in the user's allowed range.

The other major area of impact of MLS is everywhere you label an object with a security context. In Chapter 10, "Object Labeling," we discuss object labeling in more detail for non-MLS systems. Just remember that in an MLS system you must extend the object security context to include low and high security levels according to the syntax listed on page 105. You will find that the real challenge with MLS systems is determining the appropriate security level to assign to each object.




SELinux by Example(c) Using Security Enhanced Linux
SELinux by Example: Using Security Enhanced Linux
ISBN: 0131963694
EAN: 2147483647
Year: 2007
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net