+------------------------------------------------------------------+ | Linux Security: Tips, Tricks, and Hackery | | Published by Onsight, Inc. | | | | 24-April-2003 | | http://www.hackinglinuxexposed.com/articles/20030424.html | +------------------------------------------------------------------+ This issue sponsored by Linuxfest Northwest 2003, Bellingham, WA, April 26 LFNW is a showcase for what Northwest Linux users are doing with Linux and open source software. It's a place for Linux enthusiasts to get together to share their passion for what good software can do. This year's fest will include boatloads of demonstrations, tutorials, and lectures by gurus such as John "Mad Dog" Hall, Crispin Cowan, Brian "Krow" Aker, and your very own Linux Security geek, Brian Hatch. Admission is free. For more information, see www.linuxnorthwest.com. Come join the fun! -------------------------------------------------------------------- Linux File Permission Confusion By Brian Hatch Summary: File permissions, the most basic form of security control that exists on Unix-like systems, is still misunderstood by many. Before I start, I really suggest anyone interested in Linux who is near the US Pacific Northwest, check out and attend Linuxfest Northwest this Saturday. We've got gurus, raffles, and swag galore, and the whole event is free. I'll be giving a Linux Security presentation that promises to cover all Linux Security hooks in one hour or less, so it'll be a wild ride. See http://linuxnorthwest.com/ for more information. Last week I gave a much-needed refresher on how file permissions actually work, as opposed to how many people think they work. Just to be complete, this week I'll discuss how file permissions on directories work, which operate slightly differently. Read (r) The ability to read the names of files stored in this directory. Write (w) The ability to rename files in the directory, create new files, or delete existing files, if you also have Execute permissions. If you don't have execute perms, then write perms are meaningless. Execute (x) The ability to cd into this directory, and access the files in this directory. How a directory functions is one of the most frequently misunderstood file permission issues. Here are a few examples that should make it easier to understand. # "Full Access". Reegen can list, create, delete, rename, delete, # and stat any files in dir. # Access to file contents is subject to the permissions # of the file itself. # New files can be created, any file can be deleted, regardless of # file permissions. drwx------ 1 reegen reegen 4096 Jan 01 2003 dir # Reegen can do everything in the "Full Access" list except create, # delete, or rename files in this directory. dr-x------ 1 reegen reegen 4096 Jan 01 2003 dir # Reegen can do everything in the "Full Access" list except list the # filenames in this directory. If she suspects there is a file # named "program" she can list it, but cannot do an 'ls' # of the directory itself. She can access any file (file # permissions permitting) if she knows it's name. She can # create new files, or rename/delete existing ones. d-wx------ 1 reegen reegen 4096 Jan 01 2003 dir # Reegen cannot create or delete any files in this directory. # She can access any file (permissions permitting) if she # knows it's name already. d--x------ 1 reegen reegen 4096 Jan 01 2003 dir Over the years I have explained the meaning of r, w, and x on directories countless times. Many people don't realize that write access means the ability to create or delete files, and that the permissions of the file itself is totally irrelevant. This does make sense if you think about it. When you add files, what are you doing? You're putting a new entry into the directory listing - it is the directory that is changing, so that's why you need write permission to the directory. It's the same situation with deleting - the directory (list of files) is being changed, so if you have write access, you can do so regardless of the permissions of the file itself.[1] So what do you do when you need to allow write permissions on a directory for a group of people, but don't want to let them delete each other's files? That's the purpose of the "sticky" bit, "t" which you can apply to a directory[2]. When this bit is set, a user can only delete files if they are the owner. This is most common in directories like /tmp: $ cd /tmp $ ls -ld /tmp drwxrwxrwt 4 root root 4096 Jan 22 16:43 /tmp $ whoami anurup $ ls -l -rw-rw-rw- 1 reegen reegen 164864 Dec 6 13:53 a.gif -rw-rw-rw- 1 anurup anurup 98302 Oct 13 14:06 a.pdf -rw-rw-rw- 1 reegen reegen 5857 Jan 21 13:57 a.txt $ rm a.pdf; ls -l -rw-rw-rw- 1 reegen reegen 164864 Dec 6 13:53 a.gif -rw-rw-rw- 1 reegen reegen 5857 Jan 21 13:57 a.txt $ rm a.txt; ls -l rm: cannot unlink `a.txt': Operation not permitted -rw-rw-rw- 1 reegen reegen 164864 Dec 6 13:53 a.gif -rw-rw-rw- 1 reegen reegen 5857 Jan 21 13:57 a.txt Note that even though he has write permissions to /tmp anurup can't delete any files but his own - he's prevented by the sticky bit. There's one last strange bit you can apply to a directory, the set group id bit. If you set the sgid bit on a directory, any files created in that directory will have their group ownership set to the directory's group owner: $ cd /tmp $ id uid=1000(anurup) gid=1000(anurup) groups=1000(anurup) $ touch normalfile; ls -lda . normalfile drwxrwxrwt 2 root root 4096 Dec 6 18:27 . -rw------- 1 anurup anurup 5857 Jan 21 13:57 normalfile $ cd /path/to/some/sgid_directory; ls -ld . drwxrwsrwt 2 root fuzzies 4096 Oct 13 9:52 . # Note the 's' in group's execute field above. $ touch normalfile; ls -l normalfile -rw------- 1 anurup fuzzies 5857 Jan 21 13:57 normalfile As you can see, when a file was created in the sgid_directory the group was set to 'fuzzies' automatically. The user doesn't even need to be a member of this group at all. This feature is frequently used to ease administration. If you have a directory where the files must be readable by a specific group, users would normally need to be part of this group and run the chgrp command, or leave the files world readable. If the directory forces new files to be part of this group, you need only set your umask correctly (for example umask 027 or umask u=rwx,g=rx,o=) and don't need to manually fix permissions ever. In response to my column last week, Antonomasia took issue with the section where we created files that were accessible to everyone except for those in the specific group: -rwx---r-x 1 root jerks 74088 Sep 23 15:13 /usr/bin/gcc I said that creating this set of permissions would allow you to create a group called 'jerks' and put troublesome users in it, thus denying them access to gcc. This works on Linux just fine, because in Linux normal users cannot change the groups to which they are a member[3]. However in many other Unix-like operating systems, a user can drop groups from the supplemental groups list at will. On these systems, a savvy miscreant could drop his 'jerks' group and again have access to gcc[4]. This has been a public service announcement to correct common file permission misconceptions. Next week we return you to your regularly scheduled security column. NOTES: [1] Some versions of rm will complain if you try to remove an unwritable file - this is a handy feature of rm, not the Linux kernel. Try deleting your file with the actual kernel unlink() system call (e.g. perl -e 'unlink "filename"') and you'll see the kernel is not so demanding. [2] Ten brownie points to the first person who can tell me why it was originally named the sticky bit. [3] Specifically, in Linux only root can use the setgroups(2) system call. Or, to be most accurate, any user with the CAP_SETGID capability. [4] Of course, in the case of programs, there's no reason someone couldn't upload a copy of their software from home using scp/sftp/ftp or other hacks. You can, at best, restrict them to writing only to directories that are mounted without exec permissions. However if you're trying to protect access to files in "allow-everyone-but-this-group" directories, then this method works superbly on Linux -- but it can be circumvented on many other Unix-like OSs. ------------- Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. Several years ago he ran chown -------------------------------------------------------------------- This newsletter is distributed by Onsight, Inc. The list is managed with MailMan (http://www.list.org). You can subscribe, unsubscribe, or change your password by visiting http://lists.onsight.com/ or by sending email to linux_security-requestat_private Archives of this and previous newsletters are available at http://www.hackinglinuxexposed.com/articles/ -------------------------------------------------------------------- Copyright 2003, Brian Hatch. - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Fri Apr 25 2003 - 01:35:02 PDT