The development of the Internet and Internet-based technologies bring many opportunities but also encompasses numerous challenges. In the digital information exchange environment, computer code, called code, is migrated from one machine to another. This in fact has brought more risks to the participants. Many security models have been launched to solve this problem.
FOREIGN CODE AND PRIVACY POLICY
Foreign code is any code that is not generated at the workstation but in one way or another it gets to the machine and runs on it. Applets, ActiveX, email attachments, TclScript, JavaScript, PostScript, Word macros, and Excel are examples of foreign code. Figure 1 depicts the general foreign code model.
In the model, the code producer is the provider and the code consumer is the foreign code environment. For example, in web architecture: Web server is considered as producer code, web browser is seen as consumer code, and applet is foreign code.
The intrinsic nature of foreign code is that it migrates, foreign code often comes from the outside of the system, goes through many environments and usually from unsafe environments such as the Internet. They migrate to the workstation and execute similarly to a regular program. It will not matter if our world is good, but it is not! So we always have to be careful, especially as we often do not know the origin, the author of foreign code. In fact, accepting foreign code is risk-taking. Therefore, to ensure the security of computer systems when running foreign code we have to take certain security measures.
CONFIDENTIAL SOLUTIONS
To protect a computer system, we first need to control system access. The solution is to somehow restrict the access of foreign code to the data and resources of the system.
We know that every process needs a certain environment to execute. Of course, a program that never executes will never damage the system. The more restricted the system, the less risk the system will have. So our common principle is to strictly control the access of programs to the system. There are many security models, such as Bell-LaPadula, Biba, Clack-Wilson ...
To control foreign code, it is necessary first to assume that the environment enforcing security rules is trustworthy and that all foreign code is unreliable. In fact, we control foreign code in a way that is contradictory. On the one hand we want to enforce them safely, so the access of foreign code to data and system resources must be strictly limited. On the other hand, we want them to have more power, so the access of foreign code needs to be expanded. A virtual security belt is imposed on computer systems. Where local code generated at work is considered to be reliable and foreign code is considered unreliable. The best case scenario is that foreign code is treated as local code. This is probably the purpose of most solutions for foreign code. However, reliability does not mean safety. Next we will discuss four typical security models for controlling foreign code.
PRIVATE MODELS
1. Access control
Before we talk about security models, let's look at the concept of & quot; access control & quot; (access control). This is a basic technique in protecting information of most computer systems. Access control can be visualized as a situation where a subject object retrieves an object with a certain access. While a reference monitor will allow or deny access requests. The basic model of access control is given by Lampson as shown in Figure 2.
In computer systems, the subject is the user or processes. Objects are files, memory, peripherals, network nodes, and so on. Typical accesses are read, write, append, and execute. The right to perform a certain access on an object is called access right. Security policies are defined as the access controllers for the subject.
2. Sandboxing model
The term & quot; sandboxing & quot; Only the custody of a process in its management domain is intended to secure memory. To understand this model, let's take a look at the famous sandbox model developed for Java.
Java uses the term & quot; sandboxing & quot; In a broader sense, this refers to the limitation of access to any system resources, not just memory. The Java security model is based on the Discretionary Access Control model with multiple levels of access to the protected area.
Java's security model consists of three components: the byte code verifier, the class loader, and the security manager. Based on the basic model of access control, these three components work as a reference controller. The Java security model (JDK version 1.0) strictly limits the access rights of all applets in a sandbox (Figure 3). However, this will limit the ability of the applet. Thus, the JDK 1.1 release has expanded by introducing the new concept: signed applet. This is a new concept using e-signature technology, which we'll take a closer look at later.
In the JDK 1.1 model, the applet is divided into two types. The signed applet is processed as local code and the unsigned applet is put into processing in the sandbox (Figure 4).
The current Java security model (JDK version 1.2) classifies foreign code at the input into different classes. Grant privileges to each class and process each class according to granted privileges. We can see this clearly in Figure 5.
3. Model Code Signing
This model has a different approach to the model we have considered above. To ensure the security of the system, code-holders must be guaranteed that the source code is reliable and that the foreign code itself is not faked. This requirement can be met using electronic signature technology. The technique used for this model is described as follows:
In the general case, the encryption process (or code) is completed by a public / confidential signature algorithm such as RSA (Figure 6). Whenever an author wants to publish a code, they must use their own private key to sign the code. However, due to the inconvenience of dealing with long code snippets, moreover, it is important to ensure the integrity of the code, the length of the code that needs to be subdivided, and each subsection that will be signed separately. Finally, the signed code and paragraphs are published.
On the consumer code side, a comparison process is completed to ensure that the hash values computed therein and the hash value sent from the code producer are the same. The foreign code will be allowed to execute, otherwise it will be discarded. Foreign code that satisfies the test process will be processed as local code, meaning that there is no restriction on access to the system.
4. Firewalling model
Now, many organizations have been deploying firewalls to protect their local networks from outside threats. Firewalls can be deployed in the form of software or hardware. It is located between the local area network or the workstation and the rest of the Internet. The main function of the firewall is to control the flow of data into the protected system. It filters out untrusted programs and only allows trusted programs to pass (Figure 7).
This approach is known as a way of checking the security of foreign code, the security rules being formulated as properties for analysis. Foreign code units must go through an analytical program to check for safety before reaching the consumer code. This analysis program, often called a test suite, filters out programs that are considered unsafe. The code units that pass this test suite will get to the workstation and be treated as local code.
5. Model of Proof-Carrying Code
To solve the security problem for foreign code. Security laws must be unified between the code and the code producer, where the code producer creates a proof of the security of the foreign code.
In all the models considered, this new approach seems to be the least feasible because of the inconsistencies inherent in the technical requirements themselves. On the one hand we want everything to be simple so as not to affect the performance of the system. On the other hand, we want proof to be guaranteed. The truth is that there is no evidence to warrant a simple technology. Let's look at the Proof-Carrying Code Figure 8.
As illustrated in Figure 8, first of all an agreement on the security policy needs to be reached between the code consumer and the code producer. The code producer then adds the comments to the compiled code. Security laws will be applied to these annotated codes to generate a verification condition for the compatibility of the evidence. Next, the security rules are further used to encrypt the verification condition. Finally, the annotated code and proof produced will be sent to the consumer code.
A similar process will be implemented at the consumer code side. However, instead of producing proof, the process will test it. In case the evidence is compatible, the code will be integrated into the workstation system.
RELATED WORKS
In non-secure environments, virus infection (or harmful foreign code itself) is unavoidable, so we can only hope to detect them and limit infection. One of the most effective solutions today is Integrity Shell. This solution uses encryption technology to detect changes in information, thereby detecting viruses and preventing further spread.
A number of new research trends in view of minimizing the impact of foreign code on the system by building isolation environments. These are intermediate environments between the foreign code and the user system. All access requirements for foreign code to the operating system are controlled by these environments, thus ensuring system security.
CONCLUDE
The harmful types of viruses (trojan horses and internet worms) are being deployed day and night for the purpose of attacking non-stop hackers. Understanding of foreign code and security models is an essential requirement for both network administrators and users. This article provides an overview of the security models that have been deployed to deliver a safer, more secure world.
Nguyen Dinh Han - According to PCWorld Vietnam
nguyendinh.han@ait.ac.th
Faculty of Information Technology - Hung Yen Technological University
