Permission code analysis for Linux operating systems

At present, the book on the kernel rarely involves Linux kernel security. kernel security includes two parts: cryptography implementation (crypto) and access control (Security. As an important subsystem of the Linux kernel, the security system has provided many related interfaces for us. Here we will give a brief analysis and introduction to secure access control.

The principle of access control is destined to be closely related to the virtual file system and process management, because the process is the form of the user's subject, and the file is the form of the resource object, access control is how to achieve correct user access to the right resources. Linux can provide us with many credible ways to deal with such problems.

Initialization

The initialization work is defined by security_init () in start_kernel () in init/Main. C. The specific implementation is in Security/security. C:

Int _ init security_init (void)
{
Printk (kern_info "Security Framework V" security_framework_version
"Initialized/N ");
If (verify (& dummy_security_ops )){
Printk (kern_err "% s cocould not verify"
"Dummy_security_ops structure./N", _ function __);
Return-EIO;
}
Security_ops = & dummy_security_ops;
Do_security_initcballs ();
Return 0;
}

This function first uses verify to verify whether the specified access control policy (dummy_security_ops) is null. If it is null, use the "keep default" Method for configuration splitting, the "Silence" here means that any access control is handled in a way that does not matter. Then, dummy_security_ops is specified to the system's global security policy security_ops.

Access control policy interfaces

These interfaces are defined in include/Linux/security. security_operations in H includes the following operations: Permission checks are performed when the parent process traces sub-processes, and permission obtaining, setting, setting, and validity checks are performed, perform Audit checks on processes. When an operation uses a general system interface table, you need to perform permission checks. When you use the kernel message ring or change the permissions required to log on to the terminal, checks required to change the system time, checks required to allocate permissions to a new Virtual Memory Page, and assigns and checks various permissions required to execute binary programs, various access control operations required for file system operations, various access control operations required for inode index node operations, various access control operations for file operations, various access control operations required for the process operations, permission Control for inter-process communication signals, message queue control, and control of shared memory areas for inter-process communication, various controls required for processing network messages, registering and revoking access control policies, controlling network connections, various socket controls, and XF in IPSec Rm user-defined policy allocation and key management control almost cover the control of various system behaviors.

Permission management

The Virtual File System provides a unified operation interface for various types of file systems. This can also simplify the management of file permissions. How can this idea be cleverly implemented in Linux? Linux uses the column-based ACL for autonomous access control, that is, the access permission information of this file is stored in each file. Here we use the index node inode (defined in include/Linux/Fs. h) as the starting point for analysis. The inode struct contains the I _uid and I _gid elements, and an I _mode element. This I _mode is represented by a 16-bit unsigned integer. It consists of nine-bit permission-type bits, three-bit "Sticky" bits, and four-bit file-type bits, their specific definitions are in include/Linux/STAT. h:

# Define s_ifmt 00170000/* used to extract the blocking bit of the type part in the I _mode domain */
# Define s_ifsock 0140000/* socket type code */
# Define s_iflnk 0120000/* symbolic connection type code */
# Define s_ifreg 0100000/* Common file type code */
# Define s_ifblk 0060000/* block special file type code */
# Define s_ifdir 0040000/* directory file type code */
# Define s_ifchr 0020000/* Special file type code */
# Define s_ififo 0010000/* pipeline or FIFO type code */
# Define s_isuid 0004000/* User sticky position */
# Define s_isgid 0002000/* User Group sticky position */
# Define s_isvtx 0001000/* sticky position */
# Define s_irwxu 00700/* User read/write execution */
# Define s_irusr 00400/* User Read */
# Define s_iwusr 00200/* User Write */
# Define s_ixusr 00100/* User execution */
# Define s_irwxg 00070/* User Group read/write execution */
# Define s_irgrp 00040/* User Group read */
# Define s_iwgrp 00020/* User Group write */
# Define s_ixgrp 00010/* user group execution */
# Define s_irwxo 00007/* read/write execution by other users */
# Define s_iroth 00004/* read by other users */
# Define s_iwoth 00002/* Other users write */
# Define s_ixoth 00001/* executed by other users */
# Define s_irwxugo (s_irwxu | s_irwxg | s_irwxo)/* read/write all users */
# Define s_iallugo (s_isuid | s_isgid | s_isvtx | s_irwxugo)/* all user permissions */
# Define s_irugo (s_irusr | s_irgrp | s_iroth)/* read all users */
# Define s_iwugo (s_iwusr | s_iwgrp | s_iwoth)/* All users write */
# Define s_ixugo (s_ixusr | s_ixgrp | s_ixoth)/* All users execute */

At the same time, each process's task_struct also has the corresponding uid, EUID, SUID, fsuid, GID, EGID, SGID, fsgid and other elements. When a user logs on to the system, a shell process is created, it obtains the UID and gid of the corresponding user from/etc/passwd to uniquely identify this user, and all the processes will be passed on from generation to generation. When the kernel executes a user process request to access a file, it must compare the UID, GID, and file access mode of the process to determine whether the process has operation permissions on the file. A user with zero uid is a Super User and can manage any resources. Of course, this also leads to incomplete system security.

To determine whether a process has certain access to a file, the main task is to use FS/nameI. the permission function in C is determined by the specific implementation method as follows. The mask parameter is the flag of the requested access method bit:

Int permission (struct inode * inode, int mask, struct nameidata * Nd)
{
Umode_t mode = inode-> I _mode;
Int retval, submask;
If (mask & may_write ){
// If the file system to be loaded is read-only, it cannot be written, for example, a disk device.
If (is_rdonly (inode )&&
(S_isreg (mode) | s_isdir (mode) | s_islnk (mode )))
Return-erofs;
// Write is not allowed if the loaded file system is unchangeable.
If (is_immutable (inode ))
Return-eacces;
}
// Whether execution is successful
If (mask & may_exec) & s_isreg (mode )&&(! (Mode & s_ixugo) |
(Nd & Nd-> MNT & (Nd-> MNT-> mnt_flags & mnt_noexec ))))
Return-eacces;
Submask = mask &~ May_append;
// Return the appropriate permission bit
If (inode-> I _op & inode-> I _op-> permission)
// Handed over to the specific file system implementation, such as the ext3 File System
Retval = inode-> I _op-> permission (inode, submask, Nd );
Else
// If the fsuid of the current process is the same as the file uid, you must compare the permissions of the file owner. Otherwise, the user group is compared.
Retval = generic_permission (inode, submask, null );
If (retval)
Return retval;
// Return the permission bit of the adaptive access control policy, for example, SELinux.
Return security_inode_permission (inode, mask, Nd );
}