KR20020033859A - Linux security kernel - Google Patents

Abstract

PURPOSE: A Linux security kernel is provided to intercept a system call transmitted in a kernel, to add functions needed for the system call, and to process a real time monitoring based on a recorded log-in file by implementing a security environment or a resource access control function at an OS level, not an application level. CONSTITUTION: The kernel comprises functions of a log-in control, a file or resource access control, a specific instruction or process operation control, a file variation monitor, an event generation or transmission and a logging. The log-in control function limits a log-in access in a specific time, an overlapped log-in access of the same user, the number of access users, and an access of a non-approved ID, and enables a previously registered user to get a root access right. The file or resource access control function limits a file access of a user and an access time. The specific instruction or process operation control function limits a usage of a specific instruction by some users or in a specific time, and a usage of a suid or a sgid program. The event generation or transmission function generates or transmits an event if there occurs an access against a security policy. The kernel includes a system vector table with a memory address pointer on a system call. The security kernel module(16) stores the memory address pointer of the system call in relation with a security at other location, and sets other specific memory address for performing a security operation on a kernel. So if a user process(10) performs a system call in relation with a security, the security kernel module(16) performs other specific system call, not an original system call.

Description

Linux Security Kernel

The present invention relates to a secure kernel of Linux. Since the Linux kernel has been increasing in size from time to time, all device drivers, even though Linux is a single system, are supported by the continuous development and expansion of kernel functions as well as the increase of new device drivers. The file system used with is permanently combined in the kernel. This means, first of all, that when the environment changes, the kernel needs to be recompiled, while on the other hand, it needs to have persistent space in memory even if the drivers and file systems are rarely used. Another disadvantage is that the new kernel code will make you feel directly to the developer, and even minor modifications will require you to reboot your computer as the new kernel is created and installed.

However, from the kernel's point of view, a module is usually made up of many functions and object code that is linked at runtime and removed. This object code is used to run the kernel with the same privileges as running in system mode. The single structure of the kernel does not change, and unlike the microkernel, newly added functions do not execute on their own. One advantage of running a device driver or file system as a module is that only a documented interface can be used, and for the user the module can be used with other functions added whenever a small, simple kernel is needed. Thus, it is possible to load the module automatically without the user having to worry about it. C files are organized into directories made up of various kinds of functional groups. Functional subunits are compiled into object files during compilation so that you do not usually have to access every object file individually when the kernel is loaded. This functional unit is often used as a module.

The Linux system provides three system calls for creating Linux kernel modules: create_module, init_module, and delete_module. Better system calls are used as user processes to get a copy of the kernel symbol table. In Linux, the oversight of modules is to use a list containing all loaded modules. This list also oversees the module's symbol table and references. As far as the kernel is concerned, modules are loaded in two phases related to the system calls create_module and init_module. In the user process, this process is divided into four steps.

Step 1, the process puts the contents of the object file into its address space. In a normal object file, the code and data are loaded and sorted as if they started at address 0. To put code and data into a form in a way that is actually performed, the actual load address is added from various perspectives. This process is known as relocating. References to the requested part are included in the object file. There may be an unresolved reference in the object file. The size of the object module is also obtained when the object file is analyzed.

Step 2, the system call create_module is used first to get the object module's first address and secondly to prepare memory for it. To do this, the structural module enters the module from the list of modules and memory is allocated. The return value returns the address where the module will be copied later.

The load address passed in step 3, create_module, is used to reallocate the object file. This procedure replaces the memory area depending on the object file. At this point, the object module is not at the correct address, but is relocated to the load address of the module in the kernel segment. Unresolved references can be resolved using kernel symbols by providing the system call get_kernel_syms (). When a function is called, Linux makes a distinction between the other two cases. It makes it possible to find out the size of the kernel symbol table when a null pointer is passed as a parameter. If other parameters are used, the indicated location provides a copy of the symbol table in memory. This allows the process to first determine the size of the table, request the amount of memory involved and allow the system call get_kernel_syms () to be used again. There is no type information of any kind in the table except for the address. Therefore, care must be taken to ensure that the correct header file is included during module development. To be the most flexible, the module can add symbols to the kernel symbol table by itself. This allows other modules to use the function from the module loaded first. This mechanism is called module stacking. All tables from the module are collected as separate symbol tables.

Step 4, Once the preliminary work is done, we can load the object module. This allows you to use the system call init_module, which gives a pointer to the structure mod_routines and the module's symbol table. Module supervision functions are presented in a mod_routine structure, and Linux copies object modules into the kernel address space. The supervised function init () must be called only once when code and data is installed, and the appropriate register function must also be called. The return value determines whether the installation procedure is successful. The second supervisor cleanup () is called when the module is released and the appropriate register function is initialized.

The symbol table in the kernel is defined in the file kernel / ksyms.c. Each extracted function has an entry in the symbol_ table. The names of the functions and variables in each case are converted to the symbol_table by macro X (). The symbol table of the module shows not only the extracted symbols but also references to the symbols in the kernel used by the module. This allows the interdependencies of the modules to be measured. Eventually the module being used by another module will not be released. An additional help to avoid problems when releasing a module after use is the USE_COUNT mechanism. For example, if we run the device driver as a module and load it, the usage counter will increment each time the module is opened and decrement each time it is closed. This means that when you release the module, you can see if it is still in use. It should be noted that the location where the coefficient of use is absent is sometimes difficult or impossible to find.

In particular, as a last resort in other cases, it is also possible to increase the usage factor to a dedicated operation while the init () function is running. This means that the module can never be removed. The flexibility of modules does not depend on the fact that they can be loaded dynamically. The loaded module can be removed again by using the system call delete_module. Two premises need to be mentioned here. There should be no reference to the module and the coefficient of use of the module must have a value of zero. The registered cleanup () function is called during installation before the module finishes. Dynamic resources requested during execution in this function can be freed in the init () function.

When the module starts up, the module normally does not automatically recognize the hardware resources of the ISA bus, so it is sometimes necessary to pass parameters such as I / O addresses or interrupts used by the ISA device. Thus modules can be passed as numeric or string parameters. Inside the module, variables of type int, int [], and char * are defined with parameter names. While the module is loading, the variable is initialized with the specified number of parameters. String parameters are assigned first and pointers are adjusted as shown in the following table.

static int io [MAX_IO] = {0,}; static char * name = NULL; int init_module (void) {int dev; for (dev = 0; dev <MAX_IO; ++ dev) {if (io [dev]) {/ * address was passed * /} if (name) {/ * name was passed * /}}}

The call to the insmod module io = 0x300.0x308 name = “test” initializes the io array with the string passed the name pointer at 0x300 and 0x308.

One of the advantages of the Linux kernel version 2.0 is the kernel daemon. This is the process of automatically loading and removing modules from the system user. The exchange between the Linux kernel and the kernel daemon is done through IPC. The kernel daemon opens a message queue with the flag IPC_KERNELD. This queue is automatically used by the kernel as the message queue for kernel daemons. The existing IPC implementation for this suggestion is the function int kerneld_send (int msgtype, int return_size, int msgsz, const char * text, const char * return_value); Expanded by, and transmitted in the structure shown in the following table.

struct kerneld_msg {longmtype; longid; shortversion; shortpid; chartext [1];};

The mtype element contains the message and the id indicates whether the kernel requires an answer. If id is nonzero, after completion of the requested operation, the kernel daemon sends a message with the type of id to mtype and passes the result of the command executed with the new id value. The pid element contains the PID of the process causing the kernel request. The kernel daemon is responsible for loading and unloading modules into all programs starting with KERNELD_TRIGGER in the environment variable.

int request_module (const char * name); int release_module (const char * name, int wait_flag); int delayed_release_module (const char * name); int cancel_release module (const char * name);

The kernel requests a module load with request_module () and waits for the operation to be performed. The release_module () function releases the module with wait_flag which specifies whether the end of the operation should wait. The delayed_release_module () function causes the module to be removed after being delayed as specified. This function instructs the module to be automatically removed after 60 seconds if the operation was not removed by cancel_release_module (). For example, if the file system type cannot be found when a data resource is loaded, the kernel executes the following code:

for (fs = file_system; fs && strcmp (fs-> name, name); fs = fs-> next); #ifdefCONFIG_KERNELDif (! fs && (request_module (name) == 0)) {for (fs = file_system; fs && strcmp (fx-> name, name); fs = fs->. next);} # endif

File systems that are not known in this way are always loaded when the module name resolves to the file system name. For device managers, a general request is made with the following char-major-major or block-major-major pattern: The kernel daemon translates requests to load and unload modules into calls to modprobe-k. This system program can assign a module name to be loaded in a normal request. It has all the kernel names used in the Linux kernel. So only new modules are registered as entries in the file /etc/modules.conf or /etc/conf.modules.

Accordingly, the present invention aims to implement a Linux security kernel module.

The design goal of the Linux security kernel is to minimize administrative difficulties, performance degradation, and maximize security. The actual Linux security kernel is implemented at the operating system level and runs as a virtual part of the operating system. In addition, it was developed under the precondition that new operating system kernel code or new operating system kernel is not created for this purpose.

The Linux security kernel features are shown in the following table.

function Detailed function Login Control Function Restricting login access by time zone Restricting duplicate login access for same user Restricting maximum number of concurrent login access Unused Restriction on checking and deleting login ID Restricting use of root ID Only pre-registered users gain root privileges through su File and resource access control Restricting File Access Users Restricting File Access Time Specific command and process execution control Restrict the use of specific commands by user Restrict the use of specific commands by time zone Restrict suid and sgid programs File corruption check function Check for file corruption Event generation and delivery function Raise and forward events when there is a violation of security policy Logging function Log all execution history after gaining root authority Log process kill history Log specific command execution history

Figure 2 illustrates the location correlation of the Linux security kernel in the system of the present invention.

As shown in FIG. 1, the operating system kernel has a system vector table having a memory address pointer for a system call. The memory address pointer points to the location in memory where the actual kernel code of the system call resides. The Linux security kernel module 16 stores the memory address pointer of the security related system call elsewhere, and then replaces the memory address of the separate system call to perform security related work on the kernel.

Therefore, when the user process 11 performs a system call related to security, the Linux security kernel module 16 performs a separate system call instead of an original corresponding system call, and the separate system call is secured. Read the policy database to check whether it violates security settings. If there is no violation, the execution flow is returned to the original system call, and if there is a violation, an error is immediately returned to the user.

1 is a Linux secure kernel conceptual diagram

2 is a flow diagram of a security kernel and security management system

3 is a kernel module execution process

4 is a process of performing a login control function

5 is a process of performing a file and resource access control function

6 is a process of performing a specific command and process execution control function

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

3 is a process of executing a security kernel module. It decides whether to limit access to the same users as the maximum number of users through parameters input at the driver initialization and change the system call table with the modified system call. It reads the contents of each configuration file and stores it in a buffer. Each inode number is read to see if the contents of the configuration file have changed.

The policy configuration file consists of / etc / nsl / chklogin, / etc / nsl / chkopen, / etc / nsl / chkexec, and the log files are /var/log/nsl/login.log, var / log / nsl / open. It consists of log, var / log / nsl / exec.log and var / log / nsl / root.log.

Module execution method creates each policy configuration file and inputs the contents. Load module with insmod command (insmod call.o umax = maximum number of users identity = [y | n]) Unload module with rmmod command (rmmod call)

4 is a process of performing a login control function. Modifies the source of the existing login (A11) program and passes the information to the security kernel module (A13) through ioctl (). The first ioctl () call passes the username to the secure kernel module (A13). The second ioctl () checks whether the user A10 is allowed to access. Compares the user field in the configuration file (etc / chklogin) read at module A13 initialization with the ID of the user A10 to which access is currently being made. If it belongs to the time limit, it blocks the user's login (A11). We also use the utmp (A15) file to limit the maximum number of concurrent users. This file maintains the information of the currently connected user when provided by the system. If the maximum number of users is exceeded, the subsequent connection is blocked. When restricting the access of the same user, utmp (A15) compares the user name field with the ID of the user currently connected to restrict access of the same user. Connection settings of users equal to the maximum number of simultaneous users are transmitted as parameters at module A13 load. That is, the maximum number of users is set as umax = xxx and whether the same user is connected is set as identity = y (eg ismod call.o umax = 300 identity = y). The maximum number of users is limited to 300 and the same user is restricted. Also, the configuration file of login control function is composed of / etc / nsl / chkopen and the file format is as the following table.

#Username; Access restriction start time; Access restriction end time; # Comment ..................... user1; 0070; 2400; user2; 1400; 2400;

In the above configuration file format, Username is the user's ID, each field is separated by ";", and the time limit is composed of hours and minutes (24 hours). (E.g. user1; 0070; 2400; restrict user1 access from 7 am to midnight)

FIG. 5 shows a process of performing a file and resource access control function, modifying an open system call (B12), and specifying a UID and a time limit for restricting file access in a configuration file (etc / nsl / chkopen). The configuration file consists of / etc / nsl / chkopen and the file format is shown in the following table.

# / Pathname / filenameUser-ID; limit start time; limit end time; # Comment ..................... / usr / local / apache / conf / httpd. conf510; 0070; 2400; / etc / hosts1011; 1400; 2400;

In the file format of the above table, the first field is the path name of the file to be restricted, the file name and the next field are separated by Tab, and the remaining fields are separated by ";". uid is the user's uid, and the limit start time and end time consist of hours and minutes. (E.g. /var/log/my.log 510; 0000; 2359; restrict access to the file /var/log/my.log for users with UID 510)

6 shows a process of executing a specific command and process execution control function, modifies the execve system call (C11), and specifies a program name, UID, and time limit to limit execution in a configuration file (etc / nsl / chkexec). Programs given suid or sgid can be restricted by writing them to the configuration file in the same way. In other words, sui and sgid programs are recorded in the log file.) The configuration file is / etc / nsl / chexec and the file format is shown in the following table.

# / Pathname / filenameUser-ID; limit start time; limit end time; # Comment ..................... / bin / su510; 0070; 2400; / bin / ps1011; 1400; 2400;

When describing the file format of the above table, it is the path name of the program to be restricted. The path name and the next field are separated by Tab, and the other fields are separated by ";". The timeout and end time consist of hours and minutes (for example, / bin / su 520; 0700; 1800; su command is restricted from 7:00 am to 6:00 pm for users with a UID of 520).

The log file of the logging function includes login.log, which records the access attempt of the restricted user, exec.log file, which records the execution of a specific process or command, open.log file, which records details of access of a specific file, and root privileges. It consists of a file that records the history of execution. It also records whether the command or process was performed, along with the UID.

The configuration file update function modifies the write system call so that the changes can be applied immediately. That is, when the module load loads the inode number of each configuration file and the inode number of the changed file matches the inode number of the configuration file, the contents of the buffer that read the configuration file are updated.

The Linux security kernel data structure of the present invention is shown in the following table.

// buffer to read the configuration file static char * login_conf_buf, * exec_conf_buf, * open_conf_buf; // save the inode number of the configuration file int login_conf_inode_num, exec_conf_inode_num, open_conf_inode_num; static int cur_pos_login = 0, cur_pos_posc = 0, cur; / buffer that stores the contents to be written to the log file char message [256]; // structure to store each field in the configuration file struct check_file_permit {char filename [64]; // file name or pathname of the program char uid [8]; / / User's UIDchar s_time [5]; // start time to limit char e_time [5]; // end time to limit}; // structure to read UTMP file #define UT_LINESIZE32 #define UT_NAMESIZE32 #define UT_HOSTSIZE256struct mod_exit_status {short int e_termination; short int e_exit;}; struct mod_utmp {short int ut_type; pid_t ut_pid; char ut_line [UT_LINESIZE]; char ut_id [4]; char ut_user [UT_NAMESIZE]; char ut_host [UT_HOSTSIZE]; struct mod_exit_status int_utit ; struct timeval ut_tv; int32 _t ut_addr_v6 [4]; char unused [20];};

Functions of the present invention are shown in the following table.

int init_module ()-Initial function of driver-Change system call-Read configuration file contents and inode number void cleanup_module ()-driver unload function-restores system calls and frees allocated memory int our_open (const char * pathname, int flags, mode_t mode)-Replace open system call-Perform file access restriction. int our_ioctl (unsigned int fd, unsigned int cmd, unsigned long arg)-Replace ioctl system call-Perform login restriction function. size_t our_write (unsigned int fd, const char * buf, size_t count)-Replace write system call-If the contents of the configuration file change, update the contents of the buffer containing the contents of the file. int our_execve (struct pt_regs regs)-replaces execve system call-executes or restricts process execution int get_file_size (char * filename)-input : filename-> filename-Returns the size of the file. char * getline (char * buf, int file_chk)-input : buf-> the buffer containing the contents of the configuration file. file_chk-> an identifier to identify the configuration file-returns a line from the configuration file. int max_user (char * username)-input : username-> user ID- compares the maximum number of users passed as parameters with the number of currently connected users-restricts access to the same user when restricting access to the same user-current user Returns a number-if it returns -1 it means that the same user is already connected. void get_permit_data (char * line, struct check_file_permit * t_permit)-input : line-> structure to store the contents of a linet_permit-> line in the configuration file-read the input string and save it as each field of the structure. int valid_check (char * filename, int size, int file_check)-input : filename-> open or filename to run.size-> size of the configuration file. file_chk Identifier to distinguish the configuration file. Determines whether the current user can use the command or the name of the file to open-Execution restriction if 0 is returned-Execution is allowed if 1 is returned. void read_config_file (char * filename, int file_check)-input : filename-> the name of the configuration file. file_check-> the identifier to identify the configuration file. int print_log (char * filename, char * msg)-input : filename-> name of the log file to save.msg- > buffer that stores the contents to be written to the log file. char * get_time (void)-returns the current time (hh: mm)

Therefore, the development of Linux security kernel and security management software can reduce the economic and time cost of system recovery due to the original blockade of network security incidents. In addition, the technology of the safe operating system is led by advanced countries such as the United States, it is urgent to secure our own technology in this field. In addition, the security technology through the kernel developed in this project can be applied to all fields where the network is used. That is, it can be applied to Ftp service, web server, Finger service, POP server, NFS (Network File System).

Secure operating system design and implementation, which has traditionally been applied to protect military objectives and important documents of government agencies, applies the requirements of the Trusted Computer System Evaluation Criteria (TCSEC). TCSEC has six classes, C1 (lowest class), C2, B1, B2, B3, and A1 (top level) and defines security requirements for each class. Implemented to meet the requirements of the TCSEC, the system protected sensitive information, but also contributed to the degradation of the system's performance. Given the recent exploding network usage trend, the need for a safe operating system has rapidly increased. Therefore, the development of Linux security kernel and security management software is based on the requirements of these users.

Developed countries are conducting competitive research to secure core technologies through such technology development. Securing this technology means securing the advanced technology by providing security functions inside the kernel. Korea cannot be competitive in the information society of the 21st century without efforts to accumulate and improve core technologies in the development of the Linux security kernel and security software.

Claims (1)

In order to prevent and solve the security problem of Linux system, it is implemented at the kernel part of Linux operating system, not at the application level. It intercepts system calls coming into the kernel, adds the functions required for the system calls, and records recorded log files. Real-time monitoring and auditing is handled by the application to prevent damage caused by misuse of internal and external users through user authentication, and to provide protection for files and corruption by internal and external users.