11:50 "Distributed information management» / «distributed information flow control» | |
| Recently, at the request of his supervisor was doing a compilation and review for your group some of the current topics of security and operating systems in general: automated trust negotiation (auto "discussion" of access rights - I do not know how to translate) and information flow control (flow control information). I post it this compilation, but to his surprise found, in my view, unnecessarily little information on the DIFC (distributed information flow control / distributed control infromatsionnymi threads) in. RU and therefore decided to write this short article on the DIFC. Motivation Almost the only way to ensure the security and privacy of data in the system is considered to be autenifikatsiyu (answers the question: "Who said that?") and authorization ("What does he have the right to do with this data"). Ie If the program requires access to some data, we actually have 2 options: to deny or believe. If we do not trust this program, we lose the opportunity to work with her and possibly lose the important functionality. If we decide that we trust the program (and / or its developers) the program actually is "uncontested master" of that information (or copy). Such a principle in the literature are called All-Or-Nothing - «All or nothing." Naturally, this principle is not sufficiently flexible, and moreover is main cause of many security vulnerabilities in systems, such as buffer overruns. In general, this principle does not allow to create more interesting applications, where access rights are not limited to the traditional: «no access», «read only» and «read / write». It turns out that that there are systems that allow much more flexible allocation of access rights to the data - a system that supports information management. The most important feature of these systems is that they follow the data throughout their life cycle in the system. Recall that the traditional system is responsible only for initial access to data, such as checking whether a program has access to the file, and after that the program does with the data system is no longer interested. A classic example. Suppose that the system has 2 users, Alice and Bob. They want to make an appointment, but so as not to disclose too much information about his schedule of the week. Can a multi-system Linux / Unix / Windows to write the program so that it has simultaneous access to calendars and Alice and Bob, and guarantee the confidentiality of both users system The easiest way - ask for "root" to write such a program or even the right to appoint a right already are existing solution. But this way of creating at least 2 problems: 1. There is no guarantee that the program does not contain logical errors, for example, does not copy the data Alice somewhere else (or incorrectly assign admin rights). 2. It is necessary to rely on 100% of "root" and in addition, such a process neinteraktiven, ie, wait until the admin write such a program or set right. solve the first problem by using the systems to support information management. In general system with support for information management are divided into two categories: centralized and distributed (decentralized) . to include all known centralized SELinux and AppArmor. In the same article, I'll try to talk about decentralized systems, for example, research (and therefore totally unsuitable for real use, unfortunately) OS Flume, as had some experience with "contact" with her . Decentralized systems allow you to get rid of the second problem - the dependence on the root. (Distributed) Information Flow Control In short, the idea of ??controlling the flow of information is trivial and zaklyuchetsya to keep track of the data "flow" in system from the sender to the recipient. The main objective of the system to prevent unauthorized data leakage from it. In general, no program (except for "privileged") can not have simultaneous (in the context of the life of the program) to access private data, and any "run-off information" ( sink), such as monitor, printer, socket (AF_INET). That is, if the program once read my personal files, then after that system will not allow this program to have access to the network. To make the data private must be clearly indicated, for example, using special flags / tags. That's where the main difference between centralized and distributed systems. In the first case there is a particular user - a "security manager" who is responsible for the proper "tagging" the data and definition of access rights of various programs to such data. For example, you can assign the tag "special secret" at the files with your passwords or information about personal income and allow access to it only for Vim / Emacs without a license (1) the data export to whatever and (2 ) to remove these tags. Thus, even if compromise your text editor, then (assuming that the system is safe and works without error) will not allow these files anywhere in the system (/ tmp) with other more permissive tags and send them in any way on the Internet. I have not worked with SELinux, so I refer you to the official guidelines for further information. In the same distributed system, any program / entity can create their own tags to assign rights and provide access to their data for other programs. In OS Flume, you can create a tag for access to certain personal information. And you have a choice. You can give open access rights to the appointment of the tag and / or its removal. Suppose that we have created a tag tag1 and gave a public access right {tag1 +}, then any program can put this tag in your own set of tags. If we create the file F, and associate it with the tag tag1, then any process p1 can include a set of tags that tag tag1 and then be able to read all data marked tag1. However, since {tag1-} is not in the public domain, this process can not remove tag1 with its own set of tags, and now can only communicate with processes with a set of tags which are a superset of the same recruitment process p1. In principle, the system must ensure that the process can send a message to another only when the recipient has at least the same set of labels (or even more), that both the sender and that no process with non-empty set has no access to "drain" of information (on the mat induction, we prove that a system with such conditions to be safe). Disclaimer: in the original paper a more formal statement and in addition to the security tag still has the notion of the integrity of the tag, but in this article, I did not consider. Flume - this is one of the developed systems, which provides a "correct" information flow. At the system level Flume - a Linux system with a modified LSM, which captures the basic system calls that stores information about the tags, labels, and checks for correctness data stream from one process to another. Now back to the example of Alice and Bob's calendar. In OS Flume appoint Alice A tag for your calendar, and Bob for your - the tag B. Alice gives open access {A +}, and Bob {B-}. Bob runs the program with the label {A, B}, ie, with access to both calendars. This program finds several convenient time intervals, where neither Alice nor Bob is not busy, does not bear a tag B ({B-} in the public domain), and writes the results to a file F, which gets an automatic tag A ({A-} is not in the public domain). Alice opens a file F, as it is the owner of the A tag, and selects a specific date from the list of "suggested Bob." In any case, recall that {B +} is not in the public domain, so Alice can not read the calendar Bob. Conclusions Unfortunately, I can not cover all areas of applicability of the ideas DIFC (even those that are used as a motivation problem) There are many excellent articles on this topic, beginning with the most classic (Jiff) until enough fresh HiStar / DStar, or Resin. If you are interested in this subject can more / formally describe, For example, the framework Resin from MIT. At the time, was lucky to have a talk with Barbara Liskov (which is probably one of the main authorities in this area) on the control flow of information, the applicability of these principles to other problems and just got sick of this topic. There are several interesting "visions" of this idea: W5 (world wide web without walls), or Fabric. But this is a completely different story | |
|
| |
| Total comments: 0 | |