Security - UI Issue

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 simple to create a secure system if you compromise on functionality. A machine that does nothing is very safe in nature. The challenge facing software developers is how to balance usability and security.

The Tale of Two Security Models

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

The UNIX model, by contrast, is much more primitive. Only files have any kind of access control (although, in fairness, most of the things on a UNIX system are usually files), which simply has permissions for the user, group, and everyone.
There are only two levels of security:

* Users can do everything that root is allowed to do
* Root can do everything.

Experience suggests that a simpler model provides more security, but this is not always the case. For example, VMS has both a detailed security model and an excellent security reputation. The difference between VMS and Windows is that VMS machines are usually started by people with a lot of experience setting up 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 for this system. In contrast, a large number of Windows machines are home machines that are run by people with little knowledge in computers, or without knowledge at all, or in small companies without IT staff. If VMS users configure their security policy carefully, then Windows users simply turn off security measures,

Perhaps the same criticism can be carried over to UNIX. For a fair comparison, let's take a look at Mac OS X. Built on the UNIX kernel (though not particularly traditional in many ways), OS X inherits the UNIX security model. In OS X, the system does not interfere with the user in 90% of cases of what he might need in daily activities. For other activities, such as installing updates, the user is prompted for a password. In other words, the security system is kept away from the user's path most of the time.

Building a good security system

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

Once you have integrated the system, you are trying to run the application. The user immediately receives hundreds of dialog boxes with messages like:
* This program just tried to connect to the Internet ...
* This program just tried to access this file ...
* These programs just tried ...

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

What does the user do? He is taught by all other dialog boxes that clicking OK makes the program work, so he clicks OK. Oh dear, now rootkit is installed.

A specific example of such a security system is Microsoft ActiveX. ActiveX components are the simplest COM controls - 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 are loaded only if the user wanted them. Each time you visit a website that contains an ActiveX control, a dialog box pops up with information about the control, and asks you if you want to execute it. Result? Users are used to clicking OK whenever ActiveX wants to start, and a significant amount of malware spreads through this mechanism.
Unfortunately, it seems that Microsoft has learned from this error. Windows Vista displays even more pop-up dialog boxes, and encourages the user to click OK on any security-related issue.

SELinux and Systrace

One development that has caused a lot of criticism is SELinux, which adds role-based access control to Linux.
Since the first time SELinux started shipping with Fedora Core, I have seen many support calls that went something like this:

User: “Something does not work on my computer with Fedora!”
Support: “Try turning SELinux off”
User: “ ABOUT! Now everything works, thanks! ”

In this situation, the right step for the user will be to investigate why a particular application does not work with SELinux enabled, modify the applicable policy (or fix the code), and then enable SELinux again. However, this step is usually ignored.

The Systrace mechanism available in OpenBSD and NetBSD works in the opposite direction. Unlike SELinux, Systrace must be run on a per-process basis. The advantage of such a device is that if something does not work with Systrace, the user should disable only this for a specific 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 bundled with the application.

Systrace, along with the rest of the OpenBSD philosophy when it comes to security, tells us one thing: People will work on secure systems if they are easily secured. By default, OpenBSD runs programs with the lowest possible 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 their actions.

What is the answer?

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

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