📜 ⬆️ ⬇️

Security is a User Interface Problem

Security is a user interface problem.


They say there is a very simple way to secure a Windows computer - just turn it off. Behind this joke is a serious thought. Namely - it is very easy to create a secure system if you compromise functionality. A machine that does nothing is very safe in nature. The challenge facing software developers is how to balance convenience and security.

The Tale of Two Security Models


Many people claim that UNIX is more secure than Windows. However, when they demand evidence, they find it very difficult to point out vulnerabilities in the NT kernel. Indeed, on paper, the Windows security model is clearly excellent — every object has an associated access control list, and this list is checked by the kernel every time an access is attempted.

The UNIX model, by contrast, is much more primitive. Only files have any kind of access control (although, to be fair, most things on a UNIX system are usually files), which simply has permissions for the user, the group, and everyone.
There are only two security levels:
')
* Users can do everything that they are allowed to do root
* Root can do everything.

Experience suggests that a simpler model provides more security, but this is not always the case. For example, VMS has at the same time a detailed security model and an excellent safety record. The difference between VMS and Windows is that VMS machines are usually run by people with a lot of experience configuring and configuring VMS. If most of your work is an understanding of the details of the security model, then you will probably come to good security of this system. In contrast, a large number of Windows machines are home machines run by people with little knowledge of computers or no knowledge at all, or in small companies that do not have IT staff. If VMS users tune their security policy with care, Windows users simply disable security measures, as they are too complicated to properly configure.

Perhaps the same criticism can be transferred to UNIX. For a fair comparison, let's take a look at Mac OS X. Built on the UNIX kernel (although not particularly traditional in many ways), OS X inherits the UNIX security model. In OS X, the system does not prevent the user in 90% of the cases that he may need in daily activities. For other activities, such as installing updates, the user is prompted to enter a password. In other words, the security system is kept out of the user's path most of the time.


Build a good security system


Imagine you want to build a perfect security system.
The first thing you could do is categorizing all the things a program can do safely.
This list may include the recording of a private file created by the program.
You would allow the program to perform such actions transparently, while other tasks will require some form of user confirmation.

Once you have embedded the system, you try to run the application. Here the user receives hundreds of dialog boxes with messages like:
* This program has just tried to connect to the Internet ...
* This program just tried to access this file ...
* These programs have just been tried ...

The user clicks OK for all these messages, and the program happily runs. However, a little later, another dialog box pops up with a different type of message: "This program has just tried to change the vectors of the kernel system calls ...."

What is the user doing? He is taught by all the other dialog boxes that pressing OK makes the program work, so he clicks OK. Oh, honey, now the rootkit is installed.

A specific example of such a security system is Microsoft ActiveX. ActiveX components are the simplest controls of COM - dynamic libraries that support a clear interface. Obviously, you do not want to execute arbitrary code on your machine, so Microsoft makes sure that ActiveX controls will be loaded only if the user wants them. Every time you visit a website that contains an ActiveX control, pops up a dialog with information about the control, and asks you if you want to execute it. Result? Users are used to clicking OK whenever they want to start ActiveX, and a significant amount of malware is distributed through this mechanism.
Unfortunately, it seems that Microsoft has learned from this error. Windows Vista shows even more pop-up dialog boxes, and encouraging the user to click OK on any security issue.

SELinux and Systrace


One development that has caused a lot of complaints is SELinux, which adds role-based access control in Linux.
Since SELinux first began shipping with Fedora Core, I have seen many support calls that go something like this:

User: “Something is not working on my Fedora computer!”
Support: “Try disabling SELinux”
User: “Oh! Now everything works, thanks! ”

In this situation, the right step for the user is to consider why a particular application does not work with SELinux enabled, modifying the relevant applicable policy (or correcting code), and then turning SELinux on again. However, this step is usually ignored.

The Systrace mechanism found in OpenBSD and NetBSD works in the opposite direction. Unlike SELinux, Systrace should run on a process basis. The advantage of such a device is that if something does not work with Systrace, the user has to turn off only that for a particular application, and not the entire system. Despite this advantage, I suspect that, like SELinux, Systrace is rarely used in cases where the policy is not supplied with the application.

Systrace, along with the rest of the OpenBSD philosophy, when it comes to security, tells us one thing: People will work in secure systems if they are easily secured. By default, OpenBSD runs programs with the most possible low privileges, and even runs some programs in the chroot environment. In general, these services remain safe because the user does not need to do anything to confirm his actions.

What is the answer?


Currently, the goal of most security studies in designing systems that are difficult to hack from a technical point of view, completely ignoring the fact that in most systems the user is the weakest link.

Currently, many systems are “fairly safe” from a technical point of view, but most of these systems have user interfaces on top of them, which seriously hamper their security. I would like to see a system that represents a new approach to the user interface for security,
but everyone seems to be focused on the competition, to see who can provide the end user with the most confusing choices, and the greatest number of reasons to turn off the systems themselves, referred to as “necessary”.

Source: https://habr.com/ru/post/62351/


All Articles