I've been writing these Linux tutorials in an attempt to fill the void in the education of some aspiring hackers into the Linux operating system. Without good Linux skills, the world of hacking is largely closed door to you. There is a lot to know, and in this tutorial, we'll look at Linux file permissions.
Linux has system to manage who can read, write and execute any file. In this way, the owner of the file can decide who can read, write or execute their file. These file and directory permissions can also be used to manage group permissions as well.
Step 1: Checking Permissions
When we want to find the permissions on a file, we can simply use the ls command with the -l or long switch. Let's use that command in the /usr/share/hashcat directory and see what it tells us about the files there.
Hashcat is one of my favorite password cracking tools. You can read about it here.
First, let navigate to its directory;
kali > cd /usr/share/hashcat
Then, do a long listing on its directory.
kali > ls -l
If we look at each line, we can see quite a bit of information on the entries in this directory, including respectively;
(1) whether it's a file or directory,
(2) the permissions on the file,
(3) the number of links,
(4) the owner of the file,
(5) the group owner of the file,
(6) the size of the file,
(7) when it was created or modified, and finally,
(8) the name of the file.
Let's examine each of these.
Identifying a File or Directory
The very first character of the line tells us whether it's a file or directory. If the line begins with a "d", it's a directory. If it begins with a "-", it's a file.
Identifying the Permissions
The next section of characters defines the permissions on the file. There are three sets of rwx that stands for read, write and execute. This determines whether there is the permission to read the file, write to the file, or execute the file. Each set of rwx represents the permissions of the owner, group, and then, all others, respectively.
So, lets look at the hashcat rules directory (hashcat rules transforms your wordlist in such a way that it may better fit the target password, including the combinator.rule which will change capitalization such as occupytheweb --> OccupyTheWeb).
Let's navigate to the rules directory and then do a long listing.
kali > cd rules
kali > ls -l
We can see that each begins with:
-rw-r--r--
This means that it's a file (-) where the owner has read (r) and write (w) permissions, but not execute permission (-). Note, here the dash "-" represents nothing or no permission.
The next set of permissions represents those of the group. Here we can see that the group has read permissions (r), but not write (-) or execute permission (-).
Finally, the last set of permissions are for all others. We can see that all others have only the read (r) permission on these files
Step 2: Changing Permissions
Let's imagine a case where we wanted the group to be able to write to the hashcat combinator.rule file. Someone in the group has developed an improvement to this rule and wants to write the changes and share it with everyone in the group.
Linux has a command called chmod (change mode ) that allows us to change the permissions on a file as long as we're root or the owner of the file. These permissions are represented by their binary equivalents in the operating system.
Permissions by the Numbers
Remember, everything is simply zeros and ones in the underlying operating system, and these permissions are represented by on and off switches in the system. So, if we could imagine the permissions as three on/off switches and these switches are in the base-two number system, the far right switch represents 1 when it's on, the middle switch represents 2 when it's on, and finally, the far left switch represents 4 when on.
So, the three permissions look like this when they are all on:
r w x
4 2 1 = 7
If you sum these three, you get seven, right? In Linux, when all the permission switches are on, we can represent it with the decimal numerical equivalent of 7. So, if we wanted to represent that the owner (7) and the group (7) and all users (7) had all permissions, we could represent it as:
777
Now, lets go back to our hashcat combinator.rule file. Remember its permissions? They were rw-r--r--, so we could represent that numerically like:
r w - | r - - | r - -
4 2 0 | 4 0 0 | 4 0 0
This can be represented by 644.
Changing the Actual Permissions of combinator.rule
Now, if we wanted to give the group write (2) privileges, we can use the chmod command to do it. We need to add the write (2) privilege to the combinator.rule file. We do that by:
kali > chmod 6 6 4 combinator.rule
This statements says give the owner read and write permissions (4+2=6), the group the same (4+2=6). and give everyone else simply read permission (4+0+0=4).
When we now do a ls -l, we can see that the permissions for combinator.rule are now:
r w - r w - r - -
Simple, right?
Step 3: Changing Permissions with UGO
Although the numeric method is probably the most common method for changing permissions in Linux (every self-respecting Linux guru can use it), there's another method that some people find easier to work with. It's often referred to as the UGO syntax. UGO stands for U=user or owner,G=group and O=others. UGO has three operators:
+ for add a permission
- for subtract a permission
= to set a permission
So, if I wanted to subtract the write permission to the group that combinator.rule belongs to, I could write:
kali > chmod g-w combinator.rule
This command says "for the group (g) subtract (-) the write (w) permission to combinator.rule."
You can see that when I now check file permissions by typing ls -l, that the combinator.rule file no longer has write permission for the group.
If I wanted to give back the group write permission, I could type:
kali > chmod g+w combinator.rule
This command says "for the group add the write permission to the file combinator.rule."
Step 4: Giving Ourselves Execute Permission on a New Hacking Tool
Very often--as a hacker--we'll need to download or create new hacking tools. After we download, extract, unzip, make, and install them, we'll very often need to give ourselves permission to execute them. This doesn't happen automatically. If we don't, we will usually get a message that we don't have adequate permission to execute.
We can see in the screenshot above that our newhackertool does not have execute permission for anyone.
When we do a long listing on our newhackertool, we can see that the permissions are onlt read and write (6) for the owner.
kali > ls -l
We can give ourselves (root user) permission to execute on a newhackertool by writing:
kali > chmod 766 newhackertool
As you now know, this would give us--the owner--all permissions including execute, and the group and everyone else just read and write permissions (4+2=6). You can see in the screenshot above that after running the chmod command, that's exactly what we get!
-rwx rw- rw-
In my next Linux tutorial, we will look at managing running processes, so make sure to come back.