MIT course "Computer Systems Security". Lecture 4: "Separation of privileges", part 3

Massachusetts Institute of Technology. Lecture course # 6.858. "Security of computer systems". Nikolai Zeldovich, James Mykens. year 2014

Computer Systems Security is a course on the development and implementation of secure computer systems. Lectures cover threat models, attacks that compromise security, and security methods based on the latest scientific work. Topics include operating system (OS) security, capabilities, information flow control, language security, network protocols, hardware protection and security in web applications.

Lecture 1: "Introduction: threat models" Part 1 / Part 2 / Part 3
Lecture 2: "Control of hacker attacks" Part 1 / Part 2 / Part 3
Lecture 3: "Buffer overflow: exploits and protection" Part 1 / Part 2 / Part 3
Lecture 4: "Separation of privileges" Part 1 / Part 2 / Part 3

So, our picture shows a “work of art”, which its creators tried to protect from threats. In their case, I think they were very worried, because when creating the okcupid.com dating site , they really wanted to make sure that the reputation of the users of the site would not suffer from the disclosure of personal data. From a conversation with one of the developers of the site who wrote this article, it is known that they were not really compromised. At the very least, no data leakage due to the use of the OKWS architecture and partly due to monitoring of malicious activity did not occur.
')
The reason why people do not break their applications into smaller components is that this process requires some effort. It is necessary to isolate all parts of the code, define clear interfaces between them, decide what data each component should have access to. If you decide to implement a new function, you will have to change the data to which each component of the program has access to give it new privileges or select some, and so on. So this is quite a time consuming process.



Let's try to understand how a web server is designed, and perhaps one way to do this is to track how an http request is processed by an OKWS server. So, in the same way as shown in the previous figure, we have a web browser that wants to go to okcupid.com . The developers of the site project imagined that they would have a lot of machines, but we consider only the interface of the site where OKWS will work, and one more machine in the background that will store the database. This second machine uses MySQL , because it is good software for solving many problems. They want to really protect this data because it’s really hard to get to a raw disk or a database with raw raw datagrams.

So, how does the request work, how is the request handled by the OKWS server? First it arrives and is processed by a process called okd for the OKWS dispatcher. He checks that he is asking for this request, and then does a couple of things. Since you may first need to register this request, it redirects it to a component called oklogd , after which you will need to create some templates, and it is possible that you will have to create them even before the request has arrived. And it performs another component called pubd .



And finally, there is a certain service to which this request is sent, so in okd there is a table of the set of services that it supports. Presumably, this request goes to one of these services, so after review, okd will redirect this request to a specific svc service process. This service will perform exactly what the request requires, for example, will sign the user to the newsletter, or will give the opportunity to view the directory of users okupid using the database, etc.

And for this, you will probably need the service to leave information about the request in the log of the oklogd component. And at the end of the day, he should "talk" with the database. The creators of the site implemented this process of “communication” a bit differently, as it usually happens in Apache , where you simply communicate with the database and issue arbitrary SQL queries. They came up with the concept of a database proxy, dbproxy , which is in front of the MySQL database and accepts requests from the svc service to execute them. I think this illustration basically shows how OKWS works.



There is another component that initiates all this, it is called okld , and it is responsible for starting all the processes in the interface of this web server. I hope some of these things look familiar to you, because this is exactly the architecture that was covered in the lab. It looks like it's a good design. You did not have pubd , logd and dbproxy in LR , but you had okd and svc . Have questions about OKWS ?

Audience: did we understand correctly that dbproxy does not accept SQL queries, but a different kind of queries?

Professor: yes, that's right! What does this interface look like? They do not describe this in very detail, but one thing you could do with this dbproxy is to create a supply of multiple arguments for SQL query templates. For example, it can be a search template for a friend’s search that chooses them by ID .



Suppose there is a template like “choose ^ ID from the list of friends, where ^ ID =“% S ” . Suppose you want to find Alice among your friends and send the query S , where the argument is equal to “alice” . Let our application, available in the interface, know that dbproxy is ready to execute three types of requests on its behalf. If you want to execute query # 1, and its argument is “Alice” , then it gives you access to the database.

Audience: can an external user at the web browser level send such a request to the database or does this all apply only to internal network users?

Professor: yes, it can. So how does it work? In fact, it is strange that this database is on a separate machine, because you could just connect to the OKWS database or to the MySQL server? So what's stopping this?

Audience: firewall?

Professor: yes, probably, at some level. The developers do not describe this in too much detail, but there is probably some internal network on the second machine, and there is a switch between the interface and the database that cannot be reached from the outside world. In fact, both machines are on the same network, but there is a firewall Fw , which has some rules. Perhaps they are that you can only connect to this interface computer through port 80, but not directly to the internal server. This is one of the protection options.



Another probably is that when you connect to this dbproxy database proxy server, you need to provide a 20-byte cryptographic token or key, and if you don’t provide it, dbproxy will reject your connection. So the rule is that you open a TCP connection, send your 20 bytes, and if they are wrong, the connection is closed. This, I think, is the meaning of such a system project.

So let's try to figure out how to isolate these different processes here. How can you make sure that all these components do not overwhelm each other?

Audience: different root-rights and different user IDs?

Professor: yes, almost each of these components works as a different uid , so here, in the description of the system there is a whole table that describes for each component where it works and with which uid . So we can write that okd has its own uid , pubd has its own uid and oklogd also has its own uid .

Okld works as root , which is pretty unfortunate, but perhaps there is nothing to worry about. Then there is a whole bunch of dynamically assigned user IDs for each service, for example, ID 51001, etc.



Thus, this ensures that each service cannot interfere with the processes of other services. Here, chroot is also widely used, so some of these components have chroot rights in separate directories. For example, okd and svc are endowed with general chroot rights in some directories. Why do you think these two components have a separate, rather than shared with the other components of the chroot ?

Audience: because okd does not have root rights.

Professor: yes, but why don't they put pubd , oklogd and all the others in the same chroot ?

Audience: Is it possible if services need to share more data, do they need to be isolated from each other?

Professor: maybe. I think that they should share some data, but this data is not in the files, they are transmitted via sockets from okd to services. But in fact, none of these components store anything interesting in the file system.

Therefore, there is nothing interesting in the chroot directory, and I think that the guys from OKWS just decided to reduce the unproductive expenses on chroot , such as the need to create a copy of the directory. It is also possible that they wanted to get rid of some of the management costs for each chroot command. But since there are no real files here, everything is in order.

The reason why these guys assigned different chroot for the environment components is due to the presence of some interesting things here. There may be templates, and there may be a log file, so they would not want a random read of the log file, and so on.

Audience: do these services have files, for example, aspx ?

Professor: as they describe in the article, the service is a single compiled C ++ binary file, so there are actually no additional files.

There are templates, but they are actually transmitted through this strange mechanism: pubd has templates in its directory, it displays them in some kind of pre-computer, home form in okd , and okd already provides templates to all services via RPC calls. Thus, they sit in memory, but are actually inaccessible directly through the file system. This is a somewhat paranoid design when I can't even read the templates.
So, what's the point of separating all these components? Why do we need a separate oklogd ?

Audience: To exclude the possibility of overwriting or cutting the magazine?

Professor: yes, so we really want to make sure that if something goes wrong, the journal will at least not be damaged. Thus, there is a separate log file that is only available for writing by this uid , and all log messages are sent as RPC for this log service. And even if everything else is spoiled, well, except for okld , the magazine will remain intact.

Audience: What if you accidentally found a way to read a magazine and don’t see what others have already done with it?

Professor: no, I think that if you “hacked” some service, pubd, or something else, you can write anything in the magazine. Therefore, creating a separate oklogd entry makes sense. In fact, it’s good that oklogd is a separate process and not just updated by appending files like append-only file . Thus, oklogd cannot add some additional information to each log entry, because if the OS maintains an append-only file, you will not know that someone has written to the file when this happens. While oklogd puts a time stamp on each message and lets you find out which service made the recording or it came from okd . Therefore, you actually get additional information in this log file, because it is a separate service.

And what is the point of the okld branch and why should it work with root-rights? I think there are several reasons for this.

Audience: if you want no one else to act with root-rights, you need to delegate okld the user identification function.



Professor: yes. Someone has to set up this whole uid chroot , and you need root for this Unix , so okld provides this. This is one of the reasons. Anything else?

Audience: 80 port definition?

Professor: yes, of course! Do you have to tie the audition to port 80, which is okld and provides anything else?

Audience: it finishes opening the oklogd log file , because we do not want to leave oklogd open to prevent access to the log file.

Professor: maybe. But I don’t know if the developers really did it, because I didn’t view their source code. Do you think okld opens the log file and sends it to oklogd ? Maybe.

Audience: because otherwise, an attacker who compromised oklogd can erase the entire log.

Professor: yes, that's right. Maybe you want to open it in append mode, and then pass it to oklogd , then you have more security guarantees for the log. This is something that you can not do without root-rights.

So, we had a homework question, what would happen if this 20-byte token was “leaked” to access the database. What damage can it do? Should we worry about it?

Audience: while an attacker can take control of a particular service.

Professor: yes, right, because now you are able to connect and get all the query templates. It actually seems pretty simple. You will probably need to compromise one of these components in order to be able to connect to the server database first. So I think if you have this token and you manage to compromise one of these components shown in the figure, then you could use all these queries.

Now let's see how to improve this OKWS design? For example, it would be possible to allocate a separate uid unit for each user, except for allocating a separate uid for each service. Here, each service, such as news, friend search, or account creation, has a separate userid , but each OKWS user is not represented as a Unix uid . In reality, there is no userid , only service IDs are present here. Do you think you need a different uid for each OKWS client?

Audience: in this case, it turns out that if one user “hacks” the service, he can get access to all the data of other users of this server.

Professor: yes, that's right!

Audience: but if you had, in fact, a separate service and a separate dbproxy for each user, then it would be impossible to access other people's data.

Professor: yes, but can this be a stronger model? I think that the OKWS developers are not taking this step for two reasons. The first is performance. If you have a couple of millions of okcupid users , several million running processes and a couple of millions of dbproxie , then performance is possible. And it will not allow to achieve the same performance that the existing OKWS architecture provides .

Audience: OKWS description says that the performance of this system is better than that of other systems. How was this achieved?

Professor: I think this is partly because they fine-tuned their design to a specific workload, and they also wrote it all in C ++ . The alternative is to write some things in PHP , then you will probably achieve advantages on this front.

In addition, they do not have many of the functions that Apache has. It has a general purpose design, so there are a lot of working processes in it, and it reloads them from time to time. There are many TTP connections here that ensure the duration of the process of compounds and maintain their activity. It also increases the number of processes running on the system. Apache is made more universal and can do everything that you would like to receive from the Internet server, while the guys from OKWS are more focused on solving specific tasks.

But I think that in our time there are other web servers that can probably correspond to OKWS performance. For example, Nginx is a very optimized web server that you can run these days. If server-side application performance is required, you probably want a long process to be very similar to OKWS . And so that it would have a CGI fast common gateway interface mechanism for connecting an external program to a web server, or some sort of protocol that could be used on the server side to implement this even in Apache or Nginx . Therefore, I think that many of these ideas are not exclusive to OKWS , they can be implemented in other web servers. They simply show that improving security does not preclude the use of these “tricks”. I think they started with a scheme similar to Apache , but felt that it would not be safe enough.

So I think that one of the reasons why the creators of OKWS did not want to introduce separate privileges for users was the possible performance degradation.



Another reason is that their complete application model “rotates” around a service that tries to access each user's data, such as finding friends on an okcupid or someone you can invite on a date. As a result, this user isolation model does not make much sense, because, ultimately, there must be a service to which you send a request, and it will look at all the other data to find a match with your request. So even if you have user IDs or some kind of isolation mechanism for them, you still have to open access to the service for each user.

For other services, such as Gmail or Dropbox , which are much more user-specific and do not provide for the open possibility of sharing their files, isolating users may provide more benefits. For example, on the Dropbox server there is a userid for each Dropbox client. And if there is a process running for you and a process running for someone else, then even using a malicious exploit, you will not be able to get hold of someone else's information.
Now let's see if OKWS really managed to improve security in this model of server. To evaluate security, you need to consider each component of the system and determine what kind of attacks could harm it.

Let's start with okd . It can be attacked by requests through the browser, for example, to cause a buffer overflow. c++, , - , okd . ?



: ?

: , , . What is bad?

: , .

: , . , , , http , , , . , .

: ?

: , . , , , , , match.com . , , OkCupid . , - ? ?

: , , okd . , ?

: . , okd .

: , ?

: ! , , , , , . , , , , . , , . «» okd , , , .

: DOS-?

: , , , «» «» , DOS- - .

: okd , , …

: , . , , okd , okd , . okd , . , okd , , , , .

: .

: , . , okd . , oklogd ? ?

: .

: , , , ? pubd , , , - .

: , , «» oklogd .

: , . , , append-only , .

: , …

: , , . .

svc ? , , . , , okd oklogd . , , .

svc - -, , , . , , , .

okld ? , root. ? , . dbproxy . okld ? «»? ?

: , - ?

: , . , , . , , - , , , - . - . root- .

: -, , - dbproxy .

: !

: , , , RPC , , , , , ! .



: , . dbproxy ? , . , «» , dbproxy - .

: , svc …

: , svc , !

: , , !

: , , «» , …

: dbproxy .

: . , dbproxy , .

I hope you understand what gives us the separation of application privileges. And as we can see, this is not ideal. There are many more things that can go wrong. But it seems that this solution is in any case better than designing individual applications without access privileges, where we started.


Full version of the course is available here .

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

Dell R730xd 2 times cheaper? Only we have 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249 in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?