Messages in this thread | | | Subject | File Permissions are incorrect. Security flaw in Linux | From | "Lisa R. Nelson" <> | Date | 01 Oct 2003 06:40:13 -0600 |
| |
[1.] One line summary of the problem: A low level user can delete a file owned by root and belonging to group root even if the files permissions are 744. This is not in agreement with Unix, and is a major security issue.
[2.] Full description of the problem/report: Permissions on a file basis take precedence over directory permissions (for most cases), but in Linux they do not. In order to secure a file, you have to secure the directory which effects all files within it. As user 'lisa', I do all my work on my server. One task is to move pictures from my digital camera to my server picture directory that is wide open to everyone. All users can create sub-folders and put pictures in there. But every hour I have a cron job run that changes the ownership to root, and sets the permissions to 644 on all files in that directory structure. Thinking the files could no longer be altered by anyone but root (as would be the case in unix), and found anyone could delete them. That's when I discovered this major bug. I verified this on a sun station today, by simply creating a file in a wide open directory with 444 permissions and was then able to delete it after the "Ok to delete write-protected file(y/n), but could NOT delete a similar file with the same permissions owned by root... As it should be... Try this:
[lisa@localhost lisa]$ su - root Password: [root@localhost root]# cd / [root@localhost /]# mkdir junk [root@localhost /]# chmod 777 junk [root@localhost /]# ls -l total 225 ... drwxrwxrwx 2 root root 4096 Sep 29 07:30 junk ... [root@localhost /]# [root@localhost /]# cd junk [root@localhost junk]# ls .. > rootfile [root@localhost junk]# ls -l total 4 -rw-r--r-- 1 root root 95 Sep 29 07:31 rootfile [root@localhost junk]# cp rootfile rootfile2 [root@localhost junk]# cp rootfile rootfile3 [root@localhost junk]# ls -l total 12 -rw-r--r-- 1 root root 95 Sep 29 07:31 rootfile -rw-r--r-- 1 root root 95 Sep 29 07:32 rootfile2 -rw-r--r-- 1 root root 95 Sep 29 07:32 rootfile3 [root@localhost junk]# chmod 444 rootfile2 [root@localhost junk]# chmod 000 rootfile3 [root@localhost junk]# ls -l total 12 -rw-r--r-- 1 root root 95 Sep 29 07:31 rootfile -r--r--r-- 1 root root 95 Sep 29 07:32 rootfile2 -- 1 root root 95 Sep 29 07:32 rootfile3 [root@localhost junk]#exit [lisa@localhost lisa]$ cd /junk [lisa@localhost junk]$ ls -l total 12 -rw-r--r-- 1 root root 95 Sep 29 07:31 rootfile -r--r--r-- 1 root root 95 Sep 29 07:32 rootfile2 -- 1 root root 95 Sep 29 07:32 rootfile3 [lisa@localhost junk]$ [lisa@localhost junk]$ rm root* rm: remove write-protected regular file `rootfile'? y rm: remove write-protected regular file `rootfile2'? y rm: remove write-protected regular file `rootfile3'? y [lisa@localhost junk]$ ls -l total 0 [lisa@localhost junk]$ Notice that all three files that 'lisa' does not have write permissions to are gone!
[3.] Keywords (i.e., modules, networking, kernel): kernel file permissions security
[4.] Kernel version (from /proc/version): [root@localhost proc]# cat version Linux version 2.4.20-20.9 (root@rwbp4) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Wed Aug 20 17:41:55 EDT 2003 [root@localhost proc]#
[5.] Output of Oops.. message None [6.] A small shell script or example See Above
http://www.auburn.edu/oit/software/os/unix_files.html http://www.dartmouth.edu/~rc/help/faq/permissions.html http://www.december.com/unix/tutor/permissions.html http://www.itc.virginia.edu/desktop/web/permissions/
[unhandled content-type:application/pgp-signature] | |