Security

Security on a Linux file System


Introduction

Dealing with a networked filesystem, like we have here in the BYU CS department, brings many advantages such as the ability to share needed files, automaing passoffs, distributed system programming, and many other things. With this there is also a need to qualify data as private and public. By default, all the data on a student's account is public, and thus visable and readable by anyone else. How do you make files private? How do you make files you want open, public? The answers to these questions will be discussed in this document. The purpose of this document is educate people about permissions and how to set permissions to protect private data.


Permissions

Each file and directory in typical Linux file system has permissions, that allow or disallow reading, writing, and executing of a file for different users. Each file has then nine attributes:

  • User
    • read
    • write
    • execute
  • Group
    • read
    • write
    • execute
  • Other
    • read
    • write
    • execute

The User is the one with the password to an account. Usually all files in his jurisdiction have read, write, and possibly execute privliges for the user set. The Group here at BYU can be "ugrad" or "guest" or "faculty" for example, corresponding to which group of individuals the user belongs to. Anyone else inside the same group could then read a file in the user's account if that user had enabled the group read permissions. Finally, Others are anyone else. So if the user had other write permissions allowed for a file, ANYONE could write to that file.


Using ls -l to view file permissions

To view permission of files with Linux, an easy way is to using the ls command. At a linux shell, type in the command ls -l and the current directory's files and details will be shown.

total 24 -rw----rwx 1 bts7 ugrad 1 Mar 19 12:17 data.txt -rwx---r-x 1 bts7 ugrad 3808 Mar 17 09:21 index.html -rw----r-x 1 bts7 ugrad 967 Mar 17 10:51 process.php -rw----r-x 1 bts7 ugrad 931 Mar 17 10:11 results.php -rw----r-x 1 bts7 ugrad 939 Mar 17 10:12 style.css -rw------- 1 bts7 ugrad 1345 Mar 17 10:05 temp.html

The leftmost table of r-w-x's is what we are concerned with. The first rwx is for the user, the second three for the group and the third for other. So data.txt, for example has user read and write set, and has other read write and execute, so anyone could write, read, or execute (if it were executable).


Using chmod to change permissions

To change permissions with Linux, the user must login under a linux shell (either via SSH or direct login). To change permissions, one of the easiest ways is using chmod. The first argument of chmod is what permissions to set. The 'u', 'g', 'o' signify users, group, and other and 'r', 'w', and 'x' signify read, write and execute from before. The second argument is what file or files to change the permissions of. Here are a few examples:

chmod u+x file.txtSets the user-execute flag for file.txt
chmod u-x file.txtClears the user-execute flag for file.txt
chmod g-w file.txtClears the group-write flag for file.txt
chmod go-rx file.txtClears the group and others read and execute flags for file.txt
chmod u+r .Sets the user-read flag for the current directory.
chmod o-w *Clears the other-write flag for all files in the current directory
chmod go-rx * -RClears the group and others read and execute flags for all files in the directory and subdirectories.

Default Permissions

By default, (as of 3/23/2004) the BYU Linux filesystem allows other reading. This means that if a student hasn't changed his or her permissions, they probably allow for anyone to read their files. To change default permissions in Linux, the user must edit the .bashrc file, which is stored in the home directory ~. To that file, adding following command umask 0077 will change default permissions to have no group or other permissions. (ie. a created file or directory will not allow group or others to read, write, or execute). For more information on umask, type man umask at a linux prompt.


Updated March 19th, 2004 : by Brian Todd Sanderson