Linux Basics for Hackers is an indispensable guide to help you learn the basics of Linux and use them in the field of cyber security.
1836 
Linux has a powerful system for managing file and directory access permissions, giving users complete control over who has access to their data. This important function guarantees the security and confidentiality of information. In our complete guide, we’ll show you how to effectively manage file and directory permissions in Linux. First of all, you will understand the three main access rights: read, write and execute. Each file and directory has its own permissions that specify who can perform these actions. Understanding these rights and how they affect file access is a key step in managing permissions. The “chmod” command is used to change access permissions in Linux. This command allows you to change permissions for the file’s owner, group, and other users.
In Linux, you have complete control over file and directory access permissions, and you can easily grant or revoke read, write, and execute permissions as needed. The chmod command allows you to quickly set permissions using access modes, providing convenience and efficiency. You can also use advanced access control lists (ACLs), which provide finer-grained settings for individual users or groups. With the setfacl command, you can change the ACL, which provides more flexibility and fine-grained control. Managing access permissions is an important aspect of security and privacy in Linux. Our comprehensive guide will help you understand permissions, use the chmod command, and implement ACLs to precisely control access to files and directories to suit your needs.
As you know, in Linux, the root user is all-powerful. The root user can do almost everything in the system. Other system users have more limited capabilities and permissions and almost never have the access that the root user has.
These other users are often organized into groups that often perform similar functions. In a sales organization, these groups can be financial, technical, sales, etc. In an IT environment, these groups may include developers, network administrators, and database administrators. The idea is to bring together people with similar needs into a suitable authorized group; Then each member of the group inherits the group’s permissions. This is mainly to facilitate permission management and therefore security. By default, the root user is part of the root group. Every new system user must be added to a group to inherit that group’s permissions.
Each file and folder must have a certain level of permissions for the various accounts that use them. There are three permission levels: r Read permission. This only grants permission to open and view the file. w Write authorization. This allows the user to view and edit the file.
x Permission to execute. This allows the user to run the file (but not necessarily to view or edit the file). In this way, the root user can grant the user a certain level of permissions, depending on the purpose for which he needs the file. When a file is created, the user who created it is usually the owner of the file, and the owner group is the current user group.
The owner of the file can grant it different access privileges. See how to change permissions to give ownership to individual users and groups.
To transfer ownership of a file to another user so that they can manage permissions, we can use the chown command (or change the owner):
kali >chown ➊bob ➋/tmp/bobsfile
Here we give the command, the name of the user we are giving ownership to, and then the location and name of the corresponding file. This command gives the user account for Bob ➊ ownership of bobsfile ➋.
To transfer ownership of a file from one group to another, we can use the chgrp command (or change group). Hackers are more likely to work alone than in teams, but it is not uncommon for several hackers or pentesters to work on a project, in which case teams are necessary.
For example, you might have a group of testers and a group of security team members working on the same project. The pentesters in this example are the root group, meaning they have full permissions and access. The root group needs access to hacking tools, while the defense group only needs access to security tools such as an intrusion detection system (IDS). Let’s say the root command downloads and installs a program called newIDS; The root group must be re-owned by the security group so that the security group can use it at will.
To do this, the root group will simply enter the following command:
kali >chgrp ➊security ➋newIDS
This command gives the security group ➊ ownership of newIDS ➋.
Now you need to know how to check if these allocations worked. You do this by checking the file permissions.
If you want to know which permissions are granted to which users for a file or directory, use the ls command with the -l (long) switch to display the contents of the directory in long format – this list will contain the permissions. In Listing 51, I use the ls –l command on /usr/share/hashcat (one of my favorite password cracking tools) to see what we can learn about the files there.
kali >ls–l/usr/share/hashcat total 32952 ➊ ➋ ➌ ➍ ➎ ➏ ➐ drwxrxrx 5 root root 4096 Dec 5 10:47 charsets rwrr 1 root root 33685504 June 28 2018 hashcat.hcstat rwrr 1 root root 33685504 June 28 2018 hashcat.hctune drwxr xrx 2 root root 4096 Dec 5 10:47 masks drwxr xrx 2 root root 4096 Dec 5 10:47 OpenCL drwxr xrx 3 root root 4096 Dec 5 10:47 rules Listing 51: Checking a file’s permissions with the long listing command
For each line, we get information about:
➊ File type
➋ File permissions for owner, groups and users respectively
➌ Number of references (This topic is beyond the scope of the book.)
➍ Owner of the file
➎ File size in bytes
➏ When the file was created or last modified
➐ File name
For now, let’s focus on the seemingly confusing rows of letters and dashes along the left edge of each line. They tell us whether the item is a file or a folder. The first character indicates the file type, where d means directory and dash (–) means file.
These are the two most common file types. The next section defines file access rights. There are three character sets consisting of combinations of read (r), write (w) and execute (x) in that order. The first set represents the owner’s rights; second, who belongs to the group; and finally, all other users.
No matter what group of three letters you’re looking at, if you see the first r, that user or group of users has permission to open and read that file or directory. The W in the middle means they can write to (modify) the file or directory, and the x at the end means they can execute (or execute) the file or directory. If r, w, or x is replaced with a hyphen (-), the corresponding permission will not be granted. Note that users can only have permission to run binaries or scripts.
Let’s take the third line of output in Listing 51 as an example:
Root root rwrr 1 33685504 Jun 28, 2018 hashcat.hcstat
The file is called, as we know from the right end of the line, hashcat.hcstat. Initial – (indicating that this is a file), permissions rw – tells us that the owner has read and write permissions, but not execute permissions.
The next set of permissions (r–) represents the group’s permissions and indicates that the group has read permissions, but not write or execute permissions. And finally, we see that the rest of the users also have read-only (r–) permission.
These permissions are not set in stone. As root or file owner, you can change them. Next, we will do just that.
We can use the Linux chmod (or change mode) command to change permissions. Only the root user or file owner can change permissions.
In this section, we use chmod to change the permissions on hashcat.hcstat in two different ways. First we use the numeric representation of the permissions, then we use the symbolic representation.
We can use abbreviations to denote permissions, using a number to denote the rwx permission set. Like everything underlying the operating system, permissions are expressed in binary, so ON and OFF switches are represented by 1 and 0 respectively. You can think of rwx permissions as three ON/OFF switches, so when all permissions are granted, it equals 111 in binary.
A binary set like this is then easily represented as a single digit by converting it to octal, an eight-digit number system that starts with 0 and ends with 7. An octal digit represents a set of three binary digits, which means we can represent the set rwx as a single digit. Table 51 lists all possible permission combinations and their octal and binary representation.
Table 51: Octal and binary representation of permissions
Using this information, let’s look at some examples. First, if we want to set read-only permission, we can refer to Table 51 and find the read value:
r w x 4
Next, if we want to set the permission to wx, we could use the same methodology and look up what w sets and what x sets:
r w x 2 1
Notice in Table 51 that the octal representation of -wx is 3, which not so coincidentally happens to be the same value we get when we add the two values for setting w and x separately: 2 + 1 = 3. Finally, when all are on three permissions, it looks like this:
r w x 4 2 1
And 4 + 2 + 1 = 7. Here we see that in Linux, when all the permission switches are on, they are represented by the octal equivalent of 7.
So, if we wanted to represent all permissions for owner, group, and all users, we could write it like this:
7 7 7
This is where a shortcut comes in handy. By passing chmod three octal numbers (one for each set of rwx) followed by the file name, we can change the permissions on that file for each type of user. Enter the following in the command line:
kali >chmod 774 hashcat.hcstat
Looking at Table 51, we see that this statement gives owner all permissions, group all permissions, and everyone else(s) only read permission.
We can now see if these permissions have changed by running ls -l on the directory and looking at the hashcat.hcstat line. Change to the directory and run this command now:
kali >ls-l total 32952 drwxrxrx 5 root root 4096 Dec 5 10:47 charsets ➊ rwxrwxr 1 root root 33685504 June 28 2018 hashcat.hcstat rwrr 1 root root 33685504 June 28 2018 hashcat.hctune drwxr xrx 2 root root 4096 Dec 5 10:47 masks drwxr xrx 2 root root 4096 Dec 5 10:47 OpenCL drwxr xrx 3 root root 4096 Dec 5 10:47 rule
You should see -rwxrwxr– on the left side of the hashcat.hcstat line ➊. This confirms that the chmod call successfully changed the permissions on the file to allow both the owner and the group to execute the file.
While the numeric method is probably the most common way to change permissions in Linux, some people find the symbolic chmod method more intuitive – both methods work equally well, so find the one that works for you. The symbolic method is often referred to as UGO syntax, which stands for user (or owner), group, and others.
The syntax of UGO is very simple. Type chmod followed by the name of the user you want to change permissions for, u for users, g for groups, or o for others, followed by one of three statements:
– Remove permission
+ Adding permission
= Set permission
After the statement, specify the permission you want to add or remove (rwx) and finally the name of the file to apply it to.
So, if you want to remove write permission from the user who owns the hashcat.hcstat file, you can type the following:
kali >chmod u-w hashcat.hcstat
This command says to remove (-) write permission (w) from hashcat.hcstat for user (u).
Now, when you check the permissions again with ls -l, you should see that the hashcat.hcstat file no longer has write permission for the user:
kali >ls-l total 32952 drwxrxrx 5 root root 4096 Dec 5 10:47 charsets rxrxr 1 root root 33685504 June 28 2018 hashcat.hcstat rwrr 1 root root 33685504 June 28 2018 hashcat.hctune drwxr xrx 2 root root 4096 Dec 5 10:47 masks drwxr xrx 2 root root 4096 Dec 5 10:47 OpenCL drwxr xrx 3 root root 4096 Dec 5 10:47 rules
You can also change multiple permissions with just one command. If you want to grant execution permission to both a user and other users (not including a group), you can enter the following data:
chmod u+x, o+x hashcat.hcstat
This command prompts Linux to add execute permission for the user as well as execute permission for others to the hashcat.hcstat file.
As a hacker, you often have to download new hacking tools, but Linux automatically assigns all files and directories default permissions of 666 and 777 respectively. This means that by default you will not be able to run the file immediately after downloading it. If you try, you will usually get a message like “Permission Denied”. In these cases, you will need to grant yourself root and execute permissions with chmod to execute the file.
For example, we download a new hacker tool called newhackertool and place it in the user’s root directory (/).
kali >ls-l total 80 drwxrxrx 7 root root 4096 Dec 5 11.17 Desktop drwxrxrx 7 root root 4096 Dec 5 11.17 Documents drwxrxrx 7 root root 4096 Dec 5 11.17 Downloads drwxrxrx 7 root root 4096 Dec 5 11.17 Music rwrr 1 root root 1072 Dec 5 11.17 newhackertool➊ drwxrxrx 7 root root 4096 Dec 5 11.17 Pictures drwxrxrx 7 root root 4096 Dec 5 11.17 Public drwxrxrx 7 root root 4096 Dec 5 11.17 Templates drwxrxrx 7 root root 4096 Dec 5 11.17 Videos
We see newhackertool at ➊, along with the rest of the contents of the root directory. We can see that our newhackertool has no execute permission for anyone. This makes it impossible to use. It may seem strange that by default Linux will not allow you to execute a downloaded file, but overall this option makes your system more secure.
We can give ourselves permission to execute newhackertool by typing the following:
kali >chmod 766 newhackertool
kali >chmod766newhackertool kali >ls-l total 80 snip drwxrxrx 7 root root 4096 Dec 5 11.17 Music rwxrwrw 1 root root 1072 Dec 5 11.17 newhackertool drwxrxrx 7 root root 4096 Dec 5 11.17 Pictures snip
As you now understand, this gives us (as the owner) all permissions, including execute, and gives the group and everyone else only read and write permissions (4 + 2 = 6).
As you have seen, Linux automatically assigns basic permissions: usually 666 for files and 777 for directories. You can change the default permissions assigned to files and folders created by each user using the umask (or unmask) method. The umask method represents the permissions you want to remove from the base permissions of a file or directory to make it more secure.
The cell is a three-digit decimal that corresponds to a three-digit authorization, but the cell number is subtracted from the authorization number to give the new authorization status. This means that when a new file or folder is created, its permissions are set to the default value minus the value in the field, as shown in Figure 51.
For example, if a cell is set to 022, a new file with the default initial permission of 666 will have permissions of 644, meaning the owner has read and write permissions, while the group and all other users have read-only permissions.
Kali, like most Debian systems, has the tile set to 022 by default, so Kali defaults to 644 for files and 755 for directories. The value of a cell is not shared by all users of the system.
Each user can default to personal tiles for files and folders in their personal .profile file. To see the current value when logged in as a user, just type the umask command and note what is returned. To change the value of a user cell, edit the /home/username/.profile file and add a cell, such as cell 007, to set permissions only for the user and members of the user group.
In addition to the three general-purpose permissions, rwx, Linux has three special permissions that are a bit more complicated. These special permissions are set user ID (or SUID), set group ID (or SGID), and the sticky bit. I will discuss each in turn in the next three sections.
As you know, a user can only run a file if they have execute permission for that particular file. If the user has read and/or write permissions only, they cannot execute. It sounds simple, but there are exceptions to this rule. You may have encountered a case where a file requires root privileges when running for all users, including non-root users.
For example, a file that allows a user to change their password would need access to the /etc/shadow file – the file that contains the user’s password in Linux – which would require root privileges to run. In this case, you can temporarily grant execute permission to the owner of the file by setting the SUID bit in the program.
Essentially, the SUID bit indicates that any user can execute the file with the owner’s permissions, but those permissions do not extend beyond the file’s usage. To set the SUID bit, type 4 before the normal permissions so that a file with the new permissions of 644 will appear as 4644 when the SUID bit is set. Setting a file’s SUID isn’t something the average user would do, but if you want to do it, you’ll use the chmod command, as in chmod 4644 filename.
SGID also provides temporary elevated permissions, but it grants permissions to the file owner’s group, not the file’s owner. This means that for a set of SGID bits, someone without execute permission can execute the file if the owner belongs to a group that has execute permission on the file.
The SGID bit behaves slightly differently when applied to a directory: when the bit is set for a directory, ownership of new files created in that directory goes to the directory’s creator group instead of the file’s creator group. This is useful when a folder is shared by multiple users.
All users in this group can run the file, not just one user. The SGID bit is represented by 2 before the normal permissions. So a new file with 644 permissions will be represented as 2644 when the SGID bit is set. Again, this should be done with the chmod command, for example chmod 2644 filename.
A sticky bit is a permission bit that can be set on a directory to allow a user to delete or rename files in that directory. However, the sticky bit is a legacy of older Unix systems, and modern systems (such as Linux) ignore it. As such, I won’t discuss it further here, but you should be familiar with the term because you may hear it in the Linux world.
As a hacker, these special permissions can be used to exploit Linux systems by escalating the privileges that normal users have over root or system administrator and their associated permissions. With root rights, you can do everything in the system.
One way is to use the SUID bit. A system administrator or software developer can set an application’s SUID bit to allow that application to access files with administrative privileges. For example, scenarios that require changing passwords often have the SUID bit set.
You, the hacker, can use this to gain temporary root privileges and do something malicious, such as accessing the password in /etc/shadow. Look for files with the SUID bit set in our Kali system to try this out. In Chapter 1, I introduced you to the find command. We’ll use its power to find files with the SUID bit set.
As you may recall, the find command is powerful, but the syntax is a bit more complex than some of the other locate commands, such as locate and which. If necessary, review the search syntax in Section 1. In this case, we want to search for a file anywhere on the file system, for root or another system administrator with 4000 permissions.
To do this, we can use the following find command:
kali >find / -user root -perm -4000
With this command we ask Kali to start looking at the top of the file system with the / syntax. It then looks everywhere below / for files owned by root, specified with the root user, and having the SUID permission bit set (-perm -4000).
When we run this command, we get the output shown in Listing 52.
/usr/bin/chsh /usr/bin/gpasswd /usr/bin/pkexec /usr/bin/sudo /usr/bin/passwd /usr/bin/kismet_capture snip Listing 52: Finding files with the SUIDbit set
The output shows numerous files that have the SUID bit set. Let’s go to the /usr/bin directory, where many of these files are located, and then run a long list in that directory and scroll down to the sudo file, as shown in Listing 53.
kali >cd/usr/bin kali >ls-l snip rwxrxrx 1 root root 176272 Jul 18 2018 stunnel4 rwxrxrx 1 root root 26696 Mar 17 2018 sucrack ➊ rwsrxrx 1 root root 140944 Jul 5 2018 sudo snip Listing 53: Identifying files with the SUIDbit se
Note that for ➊ the first group of permissions (for owner) has s instead of x. This is how Linux represents the set of SUID bits. This means that anyone who runs sudo has root privileges, which can be a security concern for system administrators and a potential attack tool for hackers. For example, some programs need access to the /etc/shadow file to perform their tasks. If an attacker is able to gain control of this program, they can exploit this program’s access to passwords on a Linux system.
Linux has a well-developed security system to protect files and folders from unauthorized access. A novice hacker should have a basic understanding of this system, not only to protect their files, but also to launch new tools and files. In some cases, hackers can use SUID and SGID permissions to elevate the privileges of a regular user to root.
Using Linux permissions to protect a user’s or group’s files and folders from other users of the system can be used for both offensive and defensive purposes. Now you know how to manage these permissions and how to exploit the weaknesses of this security system, especially the SUID and SGID bits.
We used materials from the book “LINUX BASICS FOR HACKERS” written by William Pollock
1836 
1139 
1144 
1095 
1011 
910 
983 
781 
868