Page 296 - DCAP103_Principle of operating system
P. 296

Unit 9: System Security



            There are many different things which may serve as capabilities. There are human-readable   Notes
            capabilities called “passwords” which people make use of. There are flat, low-level, centralized
            capabilities implemented by experimental OS kernels. There are tickets granted by Kerberos
            servers. There are UNIX-style file descriptors, which may be passed from process to process to
            provide access.

            Operating systems such as KeyKOS and EROS have used flat, low-level and highly centralized
            capabilities, leaving the implementation of human-useful capabilities to higher level layers.

            Capabilities in such schemes are flat because they can not be interrogated. You can not ask such
            a capability about, say, when it was created or how many times it has been accessed. None of
            such capabilities possess internal state which can be mutated. Typically, one can create a new
            downgraded capability from a capability one possesses, but one can not downgrade or change in
            any way the original capability itself. These capabilities are not objects but primitive data types.

            Capabilities in such schemes are low level because they do not offer high-level security
            abstractions. In KeyKOS, capabilities were exactly of two types, read and read+write, though
            KeyKOS capabilities could contain additional information to implement service levels and other
            such levels. Capabilities in such schemes do not naturally aggregate other capabilities (a very
            simple and highly useful security abstraction), one must artificially create an object in between
            whose  sole  job  is  to  aggregate  them.  Note  that  certain  security  abstractions  (like  dynamic
            permission inheritance) are practically unimplementable on the top of a low-level system.

            Capabilities in such schemes are centralized because the kernel, and only the kernel, manages all
            capabilities. Rather than every module exporting its own capabilities, the only capabilities there
            are in the kernel. This is actually a consequence of using low-level capabilities. If capabilities
            were sufficiently high-level so as to provide message-passing services, then it would be feasible to
            force every module to use secondary capabilities that all route through a single protected kernel
            capability. Instead, each module (called a Domain) in KeyKOS had access to a maximum of exactly
            16 capabilities in special slots protected by the kernel and accessible only through special calls.

            9.1.4 Mandatory Access Control

            Traditional mandatory access control or MAC is modeled on the scheme used by the U.S.
            government for handling classified information. More specifically, this is mandatory sensitivity
            control or MSEN. There are levels of security such as TOP SECRET, SECRET, CLASSIFIED, and
            UNCLASSIFIED. There are categories based on need-to-know or special program access. An
            actor with SECRET access is prohibited from reading TOP SECRET data, but might be permitted
            to write to it. (there may be an additional discretionary ACL which prevents this though) One
            may be able to read from lower security levels and write to higher security levels. There may
            be a concept of contamination, allowing an actor with SECRET access to write UNCLASSIFIED
            data as long as no CLASSIFIED or SECRET data has been read.

            Mandatory  integrity  control  (MINT)  works  the  other  way,  preventing  pristine  objects  from
            being contaminated with junk. In this case, all actors are permitted to read the most trusted
            data. An actor that tries to execute something downloaded from an untrusted source will either
            be stopped or will lose the ability to write to more trusted objects.

            More modern systems combine the functions of MSEN and MINT into a state-transition model
            with roles. As actors do things, their state may change. In a UNIX-like system with role-based
            access control, the execution of a new executable is a particularly important point at which state
            transitions happen. Role-based security is particularly useful for enforcing privacy regulations
            such as HIPPA (U.S. medical info law) and the EU privacy laws. Two popular implementations
            of this are SE Linux and RSBAC, both available for Linux.



                                             LOVELY PROFESSIONAL UNIVERSITY                                   289
   291   292   293   294   295   296   297   298   299   300   301