Security Issues of Modern OS
This post is a criticism of the current approach to security in modern operating systems. In addition to criticism, ways to address these issues will be proposed. Linux will be considered, but I think that the situation is just as bad in BSD and other Unix, including MacOS, this also applies to Windows. This post is an expression of personal opinion, which has formed over the past few years using various distributions of Linux and Windows, Mac OS X.
What do I really dislike? And I do not like the user system. She, of course, is better than nothing, but very weak. All restrictions, rights and other security things come from the fact that we do not trust the software: we do not trust browsers for which there are exploits, PDF viewers, not to mention the new software obtained from an unreliable source. Received it in binary form or in the source does not particularly affect the situation. A compromised version of the source code of the program is also dangerous.
Take monitor setup as an example. To do this, you need to describe what you want in /etc/X11/xorg.conf accordingly. This can be done by running the xorgconfig utility or by editing xorg.conf directly in a text editor. But there it is, but: write permissions for this file belong to the superuser.
1. Run xorgconfig from the root, configure, write.
2. Run xorgconfig on our own, create a configuration file, save it to our folder, and then rewrite xorg.conf using cat or cp from the root.
3. Run a text editor from the root and go edit.
4. Using the chown or chmod utilities launched with root privileges, we allow the user to write to this file, then we write using custom tools and then close it again, so that it would be inconvenient for others.
What I don't like: in any case, one of the programs gets root rights, all root rights! As a user, I wanted the corresponding program to only write to xorg.conf, and now it can rewrite passwords and anything it wants, create a user, add a kernel module, and anything! Yes, I understand that we trust the software written by the community, but where security is needed there is no trust. Programs come through communication channels, people write them, and even when they get a good distribution, no one guarantees erroneous data processing, which can lead to the execution of arbitrary code.
Production. Actors:
Director (conditional person, interface of external interaction of the enterprise, he also has the highest authority).
Security.
Turner.
Driver.
Director Turner: "Here is the drawing, blanks and cutters in the warehouse, for a period of 3 days."
Turner at the warehouse: “Give me cutters and blanks!”
Warehouse guards: “Why is this a fright?”
Turner: “And here is the director’s instruction and permission to get 5 stocks and 3 cutters in the warehouse.”
Security: “Receive and sign!”
The driver leaves the territory of the plant with cargo, checkpoint.
Driver: “Open the gate!”
Security: “What are you taking? We are on guard, so that no one gets the floor of the plant! ”
Driver: “And here is the order, waybill, description of the cargo and its quantity, date of export and destination, here is the permission to export from the factory!”
Security checks the documents, checks the cargo and releases the driver.
Director Turner: "Here is the drawing, blanks and cutters in the warehouse, for a period of 3 days."
Turner at the warehouse: “Give me cutters and blanks!”
Warehouse guards: “Why is this a fright?”
Turner to the director: “They don’t give anything at the warehouse, no rights.”
Director Turner: “Here is a power of attorney for the full management of the plant on behalf of the director!”
Turner: "Thank you!"
The driver leaves the territory of the plant with cargo, checkpoint.
Driver: “Open the gate!”
Security: “What are you taking? We are on guard, so that no one gets the floor of the plant! ”
Driver to the director: “The security gate does not open, how can I take the order then?”
Director to the driver: “Here is the power of attorney for the full management of the plant on behalf of the director!”
Driver: “Thank you!”
In my opinion, users in the system should correspond only to people, there should not be any super user. A program that should overwrite the system configuration file should only have permission to write this file and nothing more. This should naturally continue the Unix way: “One task, one program” and allow programs to do just what they should.
Who should control it? Operating system. By definition, an operating system is a set of software for providing client programs access to equipment. So she has to control it. The program uses system functions to work with files and devices, and these functions should check if there is an appropriate tolerance. Not as it is done now, when the corresponding user is simply checked, and what he can. Even the simple text editor that the user launches to edit the file should only get rights to this file and no others! Thank you for reading so many letters. At the moment, when the user starts vim with the file name as a parameter, the console interpreter only parses the line, calls vim and feeds the parameters to it, in principle, vim can safely ignore the specified parameter and do whatever it wants with all the user's files. One solution is for the OS to control what the user wants. Command line parameters and system file selection dialogs should be processed by the OS and only these files should the program access. The same thing happens when installing programs and packages. The program is deleted by itself (it has a removal script), but it's awful! Isn’t the OS issuing the disk to the program for specific files, isn’t it the task of the OS to manage and issue devices to programs? If there are no cleaners in the restaurant, even with careful visitors it will turn into a garbage can. This is a direct function of the OS, to take from the program what it was once issued, and not politely ask her to retire and then not even control what remains. During installation, the OS should log what was installed, what got better, and when removed, return everything to its place.
A partial crutch to solve these problems is to create a bunch of users for different actions, for example, a user who can only edit xorg.conf and the like, but this is a huge number of users and just the inability to work on such a computer, you will have to remember which user is allowed to start everything from these users, but a slightly non-standard action, and again take the root and create the corresponding user for a specific action.
I propose to do something like the powers of attorney that the user issues, i.e. transferring part of the user's rights to the program, and not all. Those. for example, the browser should be able to only request information from the network, send information, write its caches to a specific place on the disk and save documents in the space allocated to the user on the disk, it should not have the right to read all user documents. And the browser was not updated via https, the user launched it and all the user's documents were sent to the hacker Pete, and no one noticed. I suggest something like a firewall, not only for the network but also for the disk and other equipment. And most importantly, it should not be a sandbox, virtualization, IL machine, or other interpreted technologies, it is quite possible to implement this in native code, just the functions of the operating system should check what the user requested and what the program does. The programs for data processing should be launched by the operating system, and it should know what data the user wants to process, and give the program the ability to process only them.
Giving programs many rights is bad; it is necessary to completely redo the security system of modern operating systems.
There are still many unresolved issues, illiterate users even more, but, I think, it is necessary to correct the existing situation. Microsoft's UAC is moving in that direction, but somehow crooked.
PS: For typos and inaccuracies, please contact Habrapost.
Based on the xenon comment How do you usually (from the shell) run the movie: mplayer filename.avi In this case, the mplayer program starts and it can do everything the user can do, but it does not erase all user files (although it could be used - thanks to her ), but only reads the specified filename.avi. This is if the program is “kind”, which we cannot count on. I suggest that when executing mplayer filename.avi, the OS prohibits mplayer from all-all-all, but gives access to filename.avi. The result is that the user did not crawl out for his rights and the program received the necessary rights, and cannot steal your documents. There are no additional gestures from the user. The user does not interfere with what he explicitly wrote, the system allows, does not limit it.
What do I really dislike? And I do not like the user system. She, of course, is better than nothing, but very weak. All restrictions, rights and other security things come from the fact that we do not trust the software: we do not trust browsers for which there are exploits, PDF viewers, not to mention the new software obtained from an unreliable source. Received it in binary form or in the source does not particularly affect the situation. A compromised version of the source code of the program is also dangerous.
So an example
Take monitor setup as an example. To do this, you need to describe what you want in /etc/X11/xorg.conf accordingly. This can be done by running the xorgconfig utility or by editing xorg.conf directly in a text editor. But there it is, but: write permissions for this file belong to the superuser.
Ways to solve:
1. Run xorgconfig from the root, configure, write.
2. Run xorgconfig on our own, create a configuration file, save it to our folder, and then rewrite xorg.conf using cat or cp from the root.
3. Run a text editor from the root and go edit.
4. Using the chown or chmod utilities launched with root privileges, we allow the user to write to this file, then we write using custom tools and then close it again, so that it would be inconvenient for others.
Conclusions:
What I don't like: in any case, one of the programs gets root rights, all root rights! As a user, I wanted the corresponding program to only write to xorg.conf, and now it can rewrite passwords and anything it wants, create a user, add a kernel module, and anything! Yes, I understand that we trust the software written by the community, but where security is needed there is no trust. Programs come through communication channels, people write them, and even when they get a good distribution, no one guarantees erroneous data processing, which can lead to the execution of arbitrary code.
Example 2
Production. Actors:
Director (conditional person, interface of external interaction of the enterprise, he also has the highest authority).
Security.
Turner.
Driver.
Ok enterprise
Act one
Director Turner: "Here is the drawing, blanks and cutters in the warehouse, for a period of 3 days."
Turner at the warehouse: “Give me cutters and blanks!”
Warehouse guards: “Why is this a fright?”
Turner: “And here is the director’s instruction and permission to get 5 stocks and 3 cutters in the warehouse.”
Security: “Receive and sign!”
Three days passed, the turner made the parts, it was time for shipment. Act Two
The driver leaves the territory of the plant with cargo, checkpoint.
Driver: “Open the gate!”
Security: “What are you taking? We are on guard, so that no one gets the floor of the plant! ”
Driver: “And here is the order, waybill, description of the cargo and its quantity, date of export and destination, here is the permission to export from the factory!”
Security checks the documents, checks the cargo and releases the driver.
Unix-style enterprise security
Act one
Director Turner: "Here is the drawing, blanks and cutters in the warehouse, for a period of 3 days."
Turner at the warehouse: “Give me cutters and blanks!”
Warehouse guards: “Why is this a fright?”
Turner to the director: “They don’t give anything at the warehouse, no rights.”
Director Turner: “Here is a power of attorney for the full management of the plant on behalf of the director!”
Turner: "Thank you!"
Three days passed, the turner made the parts, it was time for shipment. Act Two
The driver leaves the territory of the plant with cargo, checkpoint.
Driver: “Open the gate!”
Security: “What are you taking? We are on guard, so that no one gets the floor of the plant! ”
Driver to the director: “The security gate does not open, how can I take the order then?”
Director to the driver: “Here is the power of attorney for the full management of the plant on behalf of the director!”
Driver: “Thank you!”
Now about why I wrote this
In my opinion, users in the system should correspond only to people, there should not be any super user. A program that should overwrite the system configuration file should only have permission to write this file and nothing more. This should naturally continue the Unix way: “One task, one program” and allow programs to do just what they should.
Who should control it? Operating system. By definition, an operating system is a set of software for providing client programs access to equipment. So she has to control it. The program uses system functions to work with files and devices, and these functions should check if there is an appropriate tolerance. Not as it is done now, when the corresponding user is simply checked, and what he can. Even the simple text editor that the user launches to edit the file should only get rights to this file and no others! Thank you for reading so many letters. At the moment, when the user starts vim with the file name as a parameter, the console interpreter only parses the line, calls vim and feeds the parameters to it, in principle, vim can safely ignore the specified parameter and do whatever it wants with all the user's files. One solution is for the OS to control what the user wants. Command line parameters and system file selection dialogs should be processed by the OS and only these files should the program access. The same thing happens when installing programs and packages. The program is deleted by itself (it has a removal script), but it's awful! Isn’t the OS issuing the disk to the program for specific files, isn’t it the task of the OS to manage and issue devices to programs? If there are no cleaners in the restaurant, even with careful visitors it will turn into a garbage can. This is a direct function of the OS, to take from the program what it was once issued, and not politely ask her to retire and then not even control what remains. During installation, the OS should log what was installed, what got better, and when removed, return everything to its place.
Ways to Resolve Existing Unix
A partial crutch to solve these problems is to create a bunch of users for different actions, for example, a user who can only edit xorg.conf and the like, but this is a huge number of users and just the inability to work on such a computer, you will have to remember which user is allowed to start everything from these users, but a slightly non-standard action, and again take the root and create the corresponding user for a specific action.
Solutions in the new OS
I propose to do something like the powers of attorney that the user issues, i.e. transferring part of the user's rights to the program, and not all. Those. for example, the browser should be able to only request information from the network, send information, write its caches to a specific place on the disk and save documents in the space allocated to the user on the disk, it should not have the right to read all user documents. And the browser was not updated via https, the user launched it and all the user's documents were sent to the hacker Pete, and no one noticed. I suggest something like a firewall, not only for the network but also for the disk and other equipment. And most importantly, it should not be a sandbox, virtualization, IL machine, or other interpreted technologies, it is quite possible to implement this in native code, just the functions of the operating system should check what the user requested and what the program does. The programs for data processing should be launched by the operating system, and it should know what data the user wants to process, and give the program the ability to process only them.
Conclusion
Giving programs many rights is bad; it is necessary to completely redo the security system of modern operating systems.
There are still many unresolved issues, illiterate users even more, but, I think, it is necessary to correct the existing situation. Microsoft's UAC is moving in that direction, but somehow crooked.
PS: For typos and inaccuracies, please contact Habrapost.
Additional example
Based on the xenon comment How do you usually (from the shell) run the movie: mplayer filename.avi In this case, the mplayer program starts and it can do everything the user can do, but it does not erase all user files (although it could be used - thanks to her ), but only reads the specified filename.avi. This is if the program is “kind”, which we cannot count on. I suggest that when executing mplayer filename.avi, the OS prohibits mplayer from all-all-all, but gives access to filename.avi. The result is that the user did not crawl out for his rights and the program received the necessary rights, and cannot steal your documents. There are no additional gestures from the user. The user does not interfere with what he explicitly wrote, the system allows, does not limit it.