Demystifying "chmod" - Part 1 why viruses get so retarded on Linux

[miCRoSCoPiC^eaRthLinG 0]

Hi,

Today we are going to learn a bit about *NIX command chmod or "change mode" - which could be referred to as the *NIX counterpart of the MS-DOS/Windows attrib command. Our objective here is to understand the way File Permissions work on *NIX systems and be able to srt/change file permissions according to our needs. Recently there have been a lot of questions flyig around about viruses on *NIX systems - so along with this I'll briefly try to explain HOW the *NIX file permissions make it so hard for viruses to operate successfully in such an environment.

 

We'll start by setting the stage for our experiments. First we're going to setup three test users - two belonging to the same group and one as a separate user with a group of his own. Lets get to it then...Create the users with common group first. First login as root and execute the following commands.

=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=

shell> groupadd commongroup

shell> adduser -g commongroup testuser1

shell> adduser -g commongroup testuser2

shell> groupadd outsidegroup

shell> adduser -g outsidegroup testuser3

=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=

 

The commands above are to be typed into a *NIX console. They shouldn't be to hard to decipher. The groupadd command simply creates a group named as the following parameter. Thus on the 1st and 4th line - we create two groups namely, commongroup and outsidegroup. The 2nd and 3rd line, greates two users with the login names as testuser1 and testuser2 and adds both of them to the group named commongroup (the -g <groupname> option of adduser instructs the system to create a new user and add him to the specified group directly). The 5th line again, creates yet a third user but add's him to the group named "outsidegroup". Now you've to create passwords for each of these inidividual users. That can be done by using the passwd <username> syntax. Enter "pass1" as the password for the first user - or whatever password you feel like. As you can see below, the password "pass1" was regarded as a weak/bad password for the system and it reports back to you with a warning message. But since this is just for the heck of our understanding we'll go ahead and keep the same password.

=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=

shell> passwd testuser1

Changing password for user testuser1.

New UNIX password:

BAD PASSWORD: it is too short

Retype new UNIX password:

passwd: all authentication tokens updated successfully.

=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=

 

Now repeat the same another two times, replacing testuser1 with the other usernames (testuser2 & testuser3). Set the passwords to whatever you feel like. Right, now that we've got the stage set lets proceed to some actual chmod-ding and get a feel of what it does and what it can do...

 

First we are going to get a directory listing in both Windows/DOS and *NIX and compare them. Since by default the dir command in Windows doesn't spit out the file attributes, we'll simply use the "attrib" command on any directory to get us the required information. On a *NIX system, you can achieve this by typing "ls -l" ... Here's a table showing the comparative listing as I got on my windows machine on C:\ drive and on the "root" folder of a Linux system.

 

[root@getafix root]# ls -l                                      |  C:\>attrib

total 104                                                      |  A  SHR    C:\arcldr.exe

-rw-r--r--  1 root root  2137 Jan  1 17:56 anaconda-ks.cfg      |  A  SHR    C:\arcsetup.exe

drwxr-xr-x  4 root root  4096 Feb 12 19:57 configfiles          |  H      C:\AUTOEXEC.BAT

drwxr-xr-x  2 root root  4096 Jan  1 17:22 Desktop              |  SH      C:\boot.ini

drwx------  4 root root  4096 Feb 14 21:19 evolution            |  H      C:\CONFIG.SYS

-rw-r--r--  1 root root 55187 Jan  1 17:56 install.log          |  A  SHR    C:\IO.SYS

-rw-r--r--  1 root root  5937 Jan  1 17:56 install.log.syslog  |  A  SHR    C:\MSDOS.SYS

drwx------  2 root root  4096 Jan  1 17:31 mail                |  A  SHR    C:\NTDETECT.COM

drwxr-xr-x  2 root root  4096 Feb 15 04:28 movedscripts        |  A  SHR    C:\ntldr

-rwx------  1 root root    44 Feb  1 20:41 mylogin.sh          |  A          C:\odbcconf.log

-rwxr--r--  1 root root  600 Feb  4 02:23 PUTTY.RND            |  A  SH      C:\pagefile.sys

drwxr-xr-x  2 root root  4096 Feb 15 18:29 shellscripts        |  A          C:\PUTTY.RND

                                                                |  A          C:\setup.log

                                                                |

[root@getafix root]#                                            |  C:\>

 

All that gibberish (drwx--x-r-x) that you see in front of each of the *NIX files/folders are the file permissions - when constrasted to the Windows based file permission, we can see that Windows files can have at the most 4 file attributes agains the set of 10 attributes of *NIX. On a windows system, you can at the most make a file of the types - Hidden, System, Readonly and Archived. None of the attributes do much in the way of protecting a file except the ReadOnly attribute. You can easily overwrite a file with both the Hidden & System attributes set - without a hitch. Only if ReadOnly is combined with these two - you might face a "little" difficulty. I'm saying little, because all you need to do is to turn off the ReadOnly attrib and write over the file. There's no "secure" process guarding your filesystem and the file attributes - anybody or anything can do so. Even a really lame virus can use the attrib command to manipulate files and do what it wishes with them.

 

In constrast, the *NIX attribs are grouped into 3 sets of similar attributes - these groups are named:

a. User

b. Group

c. World

- each group containing a set of 3 attributes: Read = r, Write = w & Execute = x. From this perspective, lets take a look at a set of sample attributes - all of which are turned on.

      d    rwx    rwx    rwx

      Dir  User  Group  World

The 10th attribute, which appears right at the beginning of the attrib list is d which specifies that the file is a directory/folder instead. All single files will have the "d" attribute turned off whereas, all directories will have the "d" turned on. The "d" attrib is usually tuned on ONLY when you create a directory with the md OR mkdir command. The Read/Write attributes can be compared with the presence and absence of the ReadOnly attrib on the Windows system. What's extra here is the execute attribute - which explicitly determines if a file (even if it is an executable binary comparable with the Windows .com and .exe files) can be RUN or NOT.

 

As to WHO gets to Read/Write/Execute these files or files in certain folders, is determined by the 3groups of rwx attributes. That's where they come into play. A little explanation here..

 

The User set of attributes specify the activities that the user/creator of the file can perform on it - whether he can read/write/execute that file.. Any missing attribute is shown with a "-" sign in its place. Hence, if a file were to have, -r-------- it would mean that the owner/creator of the file can ONLY READ the file and not be able to write on it or execute it.

Similarly, for both READ & WRITE permissions, the attrib list would take this form: -rw-------. Note that this limits the user to only Reading & Writing to the file.

However, to be able to execute the file the third executable attrib has to be turned on: -rwx------.

 

Note that we've left the file permissions for Group & World blank - which means any other user belonging to your group (recall how we created testuser1 & 2 and added them to commongroup) - won't have ANY ACCESS whatsoever to your file and you maintain strict read/write/execute permissions on the file all by yourself...

 

Similarly, you can set any of the three permissions on for your Group in order to give a certain set of access to this file. Say if you want your group members to be able to ONLY READ the file but not be able to MODIFY or EXECUTE it, the permission set would look like: -rwxr-----. If on the other hand you want all members of your group as well as the rest of the world to do the same then it would be: -rwxr--r--. Do you begin to get the general picture how it works on *NIX ? Note, to *NIX, directories are just a special kind of file. In order to allow someone to 'traverse' the directory tree, the user has to have eXecute permissions on the directory even if they have read/write privileges set.

 

Lets do some actual chmod-ding now.. Login as any of the users with the commongroup and create a couple of blank files with the touch command. Example:

=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=

shell> touch file1 file2

=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=

 

This creates two 0 byte files with names, file1 & file2 with the default permissions set to -rw-rw-r-- .

As you can see that in none of the three groups the EXECUTABLE permission is set by default. YOU as the owner/creator can read/write the file and so can members of your own group. The rest of the world can just read it. NONE of you can execute it though... Hence, if you were to receive a virus as an attachment with your email and you saved it to your home folder, as a file newly created - it would have just those two read & write permissions. Without the execution rights, the virus can hardly do anything but to lie idle in your folder. Only if you are negligent enough to give it execution rights and then execute it - it'll be able to do some damage to your home folder only... Other users of your group aren't affected by it coz this file doesn't have the necessary permissions to do/run anything in their home folders or as a matter of fact for anybody in the World group - which would mean all of US... Good news aay ??

 

Here's how you change your attributes. In Windows you'd have simply done attrib +/-arsh filename. Here we do a chmod +xxx filename instead. The x-s each represent a permission for YOU, YOUR GROUP & the WORLD respectively. Each x can take up a number from 0 to 7. So how do you figure which number to use to get a desired group of permissions ?? Take a look at the following table.

The numbers can be:

0 = Nothing

1 = Execute

2 = Write

3 = Execute & Write (2 + 1)

4 = Read

5 = Execute & Read (4 + 1)

6 = Read & Write (4 + 2)

7 = Execute & Read & Write (4 + 2 + 1)

Thus, doing a chmod +777 file1 would render file1 with the attribute set -rwxrwxrwx: Read/Write/Execute by You, Group and World or,

chmod +744 file1 would change it to -rwxr--r--: Read/Write/Execute by YOU and Only Read by Group & World

To make a file readable and writable by you, and only read for your group, and no access from the world, change it to chmod 640 file1.

Try experimenting with the different values and do a directory listing every time to see how the attribute sets were modified.

 

Also keep in mind that chmod -R +xxx directoryname would recursively set the same permissions to all files/sub-directories under the primary "directoryname". If you do a simple, chmod +xxx directoryname it would just set those permissions for the directory itself - but not for any of the files/folders contained therein.

 

I shall put a stop here and carry on in the next part about how to further demystify chmod by using a set of letters (ugoa) instead of the numbers we've used here - to achieve the same thing. Also we'll log into the different user accounts we created and see how the file permissions affect the usability of the file from each users perspective. Feel free to fool around as much as you want.. it's fun in a geeky way to try various combinations of these numbers to get your desired permission set. Also next we'll deal with some of the common problems faced with file permissions when one file (say, script) tries to read from another file in the same directory or a file in another dir owned by someone else...

 

Till then, HAPPY CHMOD-ding..All the best

 

P.S. I chalked this one up pretty quick - please let me know if any part sounds confusing and I'll try to clarify it. Thanks...

[WaCo 0]

the only one thing that is missing in this tut is Suid/Sudo bits.saying shortly: man sudo, info chmod and all is clear

[iGuest 3]

I just read your tutorial titled chmod - part 1.
Is there a part 2? Having some trouble finding it here on the forum.

I understand how to set permissions on the files and directories via cpanel and / or ftp and all that, but I'm looking for some info about securing a file, yet allowing access to 'some' users. Ie: letting certain group members access the file via a web site. Can chmod allow only certain individuals access to a page on a site? And how to go about doing that?

reference: http://forums.xisto.com/topic/82014-topic/?findpost=

Thanks.

[qwijibow 0]

Can chmod allow only certain individuals access to a page on a site?

No.

Chmod is enforced by the kernel, allowing or dis-allowing access depending on the user that executed the user-space application requesting access.

when you access a web server, you are only a client, and never actually logged on at kernel level.

short answer... chmod is not the correct method for restricting access / granting access to differant users browsing the server.

[derouge 0]

Jlhaslip, unless I'm confused this is a Linux command relating mostly to granting permissions to other users of the computer. You can set restrictive access to groups and individual users, allowing them to edit, view, execute files.I'm not exactly sure it's related to Xisto and allowing certain users to view a page. I think the easiest way to do that is to put the users in a table, add a value concerning the "type" of user they are. Make a login page ... if they match up as whatever type of user, the page displays. If not, it doesn't. You could also probably just set up one little login page (enter pass to continue) and give the password to whoever needs it. Regardless, that question is (I think) better suited for a different section of the forum.

[iGuest 3]

Sorry derouge. I thought this section and topic would be a good place to ask about the use of a Linux CHMOD feature. It is a tutorial about Linux CHMOD afterall. I thank you for your time to point out this error on my part. I will try to behave better in future.

 Computers & Tech > How-To's and Tutorials > OS > Linux

[qwijibow 0]

sorry to keep a dieing thread alive, but Xisto is running on a *nix OS.and therefore, chmod will effect which html files and cgi scripts that the server (Apache) will serve / execute.If you have shell access, you can use chmod to restrict page viewing, however not in the way which you are trying.

[evought 0]

I just read your tutorial titled chmod - part 1. Is there a part 2? Having some trouble finding it here on the forum.

I understand how to set permissions on the files and directories via cpanel and / or ftp and all that, but I'm looking for some info about securing a file, yet allowing access to 'some' users. Ie: letting certain group members access the file via a web site. Can chmod allow only certain individuals access to a page on a site? And how to go about doing that?

reference: http://forums.xisto.com/topic/82014-topic/?findpost=

Thanks.

Yes and no. What you can do is set up your web or ftp server so that it runs its processes as a particular user after the user logs in. With some work you can do this in Apache. Many (most?) FTP servers have this ability. I do not know about other web servers. What happens is a user logs in to the site and gets a process which runs as their user account. You can then set their group membership and the file ownership to get whatever level of protection you desire. This is safer anyway, since it isolates the damage which can be done by a malicious program or user. In many default setups, all incoming web request run as a particular user (say "apache") that has permission to read the site and little else.