Understanding Linux File Permissions and Security Practices
Explore how Linux file permissions work, including the concepts of read, write, and execute permissions for files and directories. Learn about changing permissions using the `chmod` command and how umask affects default permissions when creating files. Enhance your understanding of securing software on the Linux platform.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Engineering Secure Software LINUX PERMISSIONS LINUX PERMISSIONS
Linux File Permissions Each file and directory has bits for.. Read, Write, Execute: rwx Files: works as it sounds Directories: r can list files in a directory (but not read a given file) w can create, change, delete files in directory x can cd (change directory) to that directory Thus, you may only read a file IFF you: Have read permissions to the file AND Have execute permissions to that file s directory Files & Directories have 3 levels: Owner, Group, and Everyone Else aka. User, Group, Other: ugo
List permissions of a file: ls l with some info removed from below in [...] drwxr-x--- [ ] pkm faculty [ ] . drwx------ [ ] pkm faculty [ ] .. -rwxrwxrwx [ ] pkm faculty [ ] allopen drwx------ [ ] pkm faculty [ ] mydir -rw------- [ ] pkm faculty [ ] myfile -rwx------ [ ] pkm faculty [ ] myprog drwxrwx--- [ ] pkm faculty [ ] ourdir -rwxrwx--- [ ] andy faculty [ ] ourprog Can andy execute myprog? No, because of file permissions. Can both pkm and andy execute ourprog? Yes. Everyone in faculty can read and execute ourprog Can andy read ourprog? Yes. Directory has group x, file has group r Can andy change directory (cd) to mydir? No. The directory s execute permission is off.
chmod Command to change permissions Set (=), Add (+), Remove (-) Set user to rw, not x: Set user, groups to only rw: Set ug to only rx, recursively: Add groups can rw : Add others can rw : Add everyone can read : Remove write from group: chmod u=rw . chmod R ug=rx . chmod g+rw . chmod o+rw . chmod a+r . chmod g-w . chmod ug=rw . Octal notation e.g. chmod 755 file.txt Good for setting, not adding/removing rwx --- --x -w- -wx r-- r-x rw- rwx Binary 000 001 010 011 100 101 110 111 Decimal 0 1 2 3 4 5 6 7
umask When a file is created User mask (umask) is consulted for permissions Owner = user who created the file The resulting default permission C = (P & ~Q), where Q is the mask, and P is 666 for files and 777 for directories e.g., if mask is 077, a file s permission, C = 666 & ~(077) = 600 = rw------- Or, subtract octally, digit by digit (tricky when the mask has a 7 in it) from 666 for files or 777 for directories e.g. , if mask is 022, a directory s permission, C = 777-022=755, or rwxr-xr-x nitron.se.rit.edu default: rw------- (or 077) Common default: rw-r--r (or 022) Common umask shared group stuff: rw-rw-- (or 007) Programs can change their own umask Blessing for good developers but curse for system administrators
Executing as users When executing, ordinarily OS ignores the owner of the program file Runs the program as you (assuming you have permissions, of course) e.g. prog.sh owned by root gets run as you This allows for root to have files that cannot be modified, but executed e.g. passwd (change the password) should not be tampered with sudo: execute this program as root user ( superuser do ) e.g. sudo /etc/init.d/apache2 start su: change the current user to someone else
setuid, setgid setuid and setgid bits on files chmod ug+s ./prog.sh Execute as the owner s rights, not as the executing user s rights (assuming you have permissions to execute it) Files owned by root with setuid are highly risky Arbitrary code execution vulnerability? Executing as root. App developers should almost never use this OS commands have a lot of these (e.g. passwd is owned root with setuid) Repudiation becomes a major threat with setuid and setgid setuid and setgid bits on directories setuid on directories is ignored in Linux setgid means new files inherit the group ID Sticky bit Only a file s owner, the owner of the file s directory, or root can delete the file
For Example larry$ umask 077 larry$ mkdir dir larry$ ls l dir/ drwx------ larry stooges dir larry$ touch dir/file.sh larry$ ls la dir/ -rwx------ larry stooges . ./dir -rwx------ larry stooges .. ./dir/.. -rw------- larry stooges file.sh larry$ ./dir/file.sh bash: ./dir/file.sh: Permission denied larry$ chmod R ug+x . curly$ ./dir/file.sh [Success!] curly$ ls l ./dir bash: ./dir/: Permission denied
Beware of sudo He sees you when you're sleeping, he knows when you're awake, he's copied on /var/spool/mail/root, so be good for goodness' sake. Source: http://xkcd.com/838
