Special Permissions _suid, SGID, STICKY

Special permissions

In the system, there are some more special users or file directories, but the normal permissions can not solve our needs, so there is special authority to help us solve the problem

Special privileges are three: SUID, SGID, STICKY

First, let's talk about the security context:

The process runs as a user, and the process will complete all operations as this user.

Then, the permissions match the process:

1. The owner of the process (initiator), whether it is the owner of the file being accessed, or, if so, applies the owner's permission to manipulate the file, otherwise enter the second step

2. Determine whether the owner of the process is the genus of the file being accessed, and if so, apply the permission otherwise.

Finally, special permissions will break this matching process. Specific as follows:

SUID: Super Owner

When a user runs a program, if it discovers that it has suid permissions, then when the program runs into a process, the owner (initiator) of its process is not the actual initiator, but the owner of the SUID permission program.

When we look at the last one of the first 3-bit permissions for a file or directory is S, then when the user runs the command to execute it, the owner of the process is the owner of the file.

SUID Rights Management

chmod u+/-S FILE ... [Email protected] testdir]# ls-l-rw-r--r--1 root root 0 Jul 18:20 AAA//original permission [[email protected] testdir]# chmod u+ s AAA//plus SUID permissions [[email protected] testdir]# ls-l-rwsr--r--1 root root 0 Jul 18:20 AAA//first three-bit permission for the last digit is uppercase S [[email protected] testdir]# chmod u-s AAA//Cancel file Suid[[email protected] testdir]# ls-l-rw-r--r--1 root root 0 Ju L 18:20 AAA//restore Default

SUID Actual Combat analysis

1. Enable LII users to view magedu user's home directory

[[email protected] ~]# cp /bin/ls /testdir/ls             //copy/bin/ls  to another directory to complete the requirements of the experiment [[email protected] ~]#  chmod u+s /testdir/ls            // And then to copy the past ls  plus suid permissions, so that we can apply this right to access other users ' home directory   [[email protected] ~]# ls -l  /testdir/ls                   //view Copy the previous LS has the S permission (note: The system is using the default/bin/ls, I deleted the original LS alias)-rwsr-xr-x 1 root root  117048 jul 25 18:51 /testdir/l       [[email  protected] home]$ ls -l magedu/                   ls: cannot open directory  Magedu/: permission denied    //logging in with other users, viewing the home directory of other users in the home directory is not allowed   //permissions are insufficient, because the system's original/bin/ls   does not have SUID permissions.   [[email protected] home]$ /testdir/ls -a magedu/  .   ..   .bash_history  .bash_logout  .bash_profile.bashrc  .gnome2             //is available when we use the LS command to copy past and add suid to view the home directory of other users. Because this LS belongs to the owner is Root,root users to view any user's home directory is possible, so, this is the role of SUID.

Conclusion: Suid the file is authorized suid, any user using their authorized suid binary file access, using the owner of the binary file to access it.

Note: When adding s permission, the original file must have Execute permission (x), if not added suid after the explicit permission bit display as large s then indicates that the SUID permission is not successful, must be small s.

SGID: Super Group

When a directory belongs to a group with write permissions, and has Sgid permissions, then all users belonging to this directory belong to the group (the group that belongs to this directory is an additional group of users), and the new file or directory is created in this directory as a group, the new file or directory is not the user's group, but is a group of this directory.

Sgid Rights Management

chmod g+/-S FILE ... [Email protected]/]# Ls-ld/testdir/sgid drwxr-xr-x 2 root root 4096 Jul 19:19/testdir/sgid [email protecte D]/]# chmod g+s/testdir/sgid//Add SGID permissions to directory [[email protected]/]# ls-ld/testdir/sgiddrwxr-sr-x 2 root root 4096 Ju L 19:19/testdir/sgid[[email protected]/]# chmod g-s/testdir/sgid//directory minus SGID permissions [[email protected]/]# Ls-ld/te Stdir/sgiddrwxr-xr-x 2 root root 4096 Jul 19:19/testdir/sgid

Sgid Actual Combat analysis

1. Set the directory to Sgid, so that other users in this directory to create files or directories are the main unchanged, belong to the group directory of the genus.

[[email protected] /]# ls -ld /testdir/sgid                 //View Existing directory permissions drwx-wxr-x 2 root root  4096 jul 25 19:37 /testdir/sgid[[email protected] /]# chmod g+s / testdir/sgid      //Add s permission to the directory (note that you must have W permission before you can create the file, which is the meaning of normal permissions to the directory) [[email  protected] /]# ls -ld /testdir/sgid                //Viewing directory information drwx-wsr-x 2 root root 4096 jul 25  19:37 /testdir/sgid[[email protected] /]# su - lii                              //create a file within the directory after switching users [[email protected] ~]$ touch /testdir/ sgid/lii.txt[[email p rotected] /]# ls -l /testdir/sgid/lii.txt     -rw-r--r-- 1  lii root 0 jul 25 19:39 /testdir/sgid/lii.txt    // View the genus of the created file    owner is lii and the group is root because the Sgid directory has sgid permissions.

Conclusion: 1. When you assign a sgid to a directory, the user who creates the file in its directory must be a member of its directory's genus Group.

2. When Sgid is in a directory, the owning group of the newly created file or directory within the directory automatically inherits the owning group of that directory

3. When creating a file in a directory with Sgid permissions, the group of directories must have write (W) permission to create a file on its directory. 、

2. Add Sgid permissions to the binary executable to allow other users to manipulate the file with their Sgid permission binaries

[[email protected] ~]# chmod g+s /bin/cat         //binary executable file/bin/cat plus Sgid permissions [[email protected] ~]# ls -l /bin/cat-rwxr-sr-x  1 root root 48568 may 11 16:59 /bin/cat[[email protected] ~]#  ls -l /etc/shadow----R----- 1 root magedu 1051 jul 25 12:28  /etc/shadow          //View Shadow file belongs to group magedu, group permissions are readable [[ email protected] ~]# su - lii                                      [[email protected] ~]$ cat /etc/ shadowcat: /etc/shadow: permission denied     // Switch to LII user to perform cat access Shadow file, prompt permission is not enough, because at this time the genus of shadow filesIs magedu, and cat's genus is root, so the cat sgid is not valid here. [[email protected] ~]# chown :root /etc/shadow          //Change Shadow file group to root, then use LII user to view shadow file to see success. [[email protected] ~]# su - lii[[email protected] ~]$ cat /etc/ Shadowroot:$6$npnljrmb$t5jd58gi9xvakeudyzlhixv8bcjd316q6mr/xvoi7gibus8bpmuxtgrppzyfoytu31wqgb9algduvjyux7b8g0 : 17007:0:99999:7:::bin:*:15980:0:99999:7:::d aemon:*:15980:0:99999:7:::

Conclusion: When setting Sgid for binary files, other users refer to the genus of the binary files, so when other users access other files using their binary files, the group of their files must be consistent with the group of binary files in order to access them.

Note: When adding s permission, the original file must have Execute permission (x), if not added Sgid after the explicit permission bit display as large s then indicates that the Sgid permission is not successful, must be small s.

STICKY: Other user rights

For a group writable or globally writable directory, the user in the group or all users on the system create or delete files in this directory, and if you set sticky permissions for such a directory, each user can create a new file, but only the files that are owned by the owner are deleted

Sticky Rights Management

chmod o+/-T FILE ...

[Email protected]/]# Ls-ld/testdir/sticky drwxr-xr-x 2 root root 4096 Jul 19:19/testdir/sticky [email prote CTED]/]# chmod o+t/testdir/sticky//Add STICKY permissions to directory [[email protected]/]# ls-ld/testdir/stickydrwxr-sr-t 2 root Roo  T 4096 Jul 19:19/testdir/sticky[[email protected]/]# chmod o-t/testdir/sticky//directory minus STICKY permissions [[email protected] /]# ls-ld/testdir/stickydrwxr-xr-x 2 root root 4096 Jul 19:19/testdir/stick

Sticky actual combat analysis

Set sticty permissions on the/testdir/sticky directory, and let all users create files in it is automatically belong to the directory of the genus Group, and finally let the directory of files all users can see, can only delete their own, can only edit the group has the W permissions of the file

[

[email protected] testdir]#  chmod o=rwx,g=rwx,u= /testdir/sticky/     [[EMAIL PROTECTED] TESTDIR]# LL -D /TESTDIR/STICKY/D---rwxrwx 2  root root 4096 jul 25 14:13 /testdir/sticky/ //to create a specified permission for a file, Groups and other users have to have execute and Read permissions, because we want to meet the group of the topic is a directory of the group and the directory of files users can only delete their own, and can only change their files belong to the genus Group of files (and also have write permission)  [[email protected]  testdir]# chmod o+t /testdir/sticky/[[email protected] testdir]# ll - D /TESTDIR/STICKY/D---rwxrwt 2 root root 4096 jul 25 14:13 / testdir/sticky/[[email protected] testdir]# chmod g+s /testdir/sticky/[[email  PROTECTED] TESTDIR]# LL -D /TESTDIR/STICKY/D---rwsrwt 2 root root 4096  jul 25 14:22 /testdir/sticky///add sgid and sticky permissions to the directory [[email protected] testdir]#  touch /testdir/sticky/root1[[email protected] ~]$ touch /testdir/sticky/lii1[[email protected] ~]$  touch /testdir/sticky/magedu1[[email protected] ~]$ ls /testdir/sticky/ - l-rw-rw-r-- 1 lii    root 0 jul 25 14:19 lii1-rw-rw-r--  1 magedu root 0 Jul 25 14:19 magedu1-rw-r--r-- 1 root    root 0 jul 25 14:18 root1   //three users to create a file, the owner of the user itself, belong to the group root , because we added the Sgid to the directory, and we automatically changed the group to the catalog, half finished. [[email protected] ~]$ vi /testdir/sticky/root2 [[email protected] ~]$  vi /testdir/sticky/lii1      //can edit the Lii1 file because the group of this file has write permission and cannot be modified if it is not. However, if you have execute permissions, you cannot delete their files because the parent directory of this file has the sticky permission set. [[email protected] ~]$ rm -f /testdir/sticky/lii1         //cannot delete other users ' files, and if the permissions of the remaining groups are available, the classes are modified and viewed, but cannot be deleted by others. Rm: cannot remove  '/TESTDIR/STICKY/LII1 ':  operation not permitted[[email protected ] ~]$ rm -f /testdir/sticky/root1        //also cannot delete RM : cannot remove  '/testdir/sticky/root1 ':  operation not permitted// Use magedu account Login First behavior edit Root2 file, and Root2 file belongs to group root but no write permission so can not modify, can only see.

Conclusion: The function of 1.sticky is that when the sticky permission is set to the directory, all users in this file can only delete files that belong to the user itself.

2. All users can create files for this directory, but if you want to modify or view other people's files depending on the permissions that other files set on the user itself.

Special Permissions _suid, SGID, STICKY