From: "Lisa R. Nelson" <lisanels@cableone.net>
To: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: File Permissions are incorrect. Security flaw in Linux
Date: 01 Oct 2003 06:40:13 -0600 [thread overview]
Message-ID: <1065012013.4078.2.camel@lisaserver> (raw)
[-- Attachment #1: Type: text/plain, Size: 3778 bytes --]
[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/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2003-10-01 12:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-01 12:40 Lisa R. Nelson [this message]
2003-10-01 13:08 ` File Permissions are incorrect. Security flaw in Linux Måns Rullgård
2003-10-01 13:08 ` Mathieu Chouquet-Stringer
2003-10-01 13:23 ` viro
[not found] ` <1065017722.2995.10.camel@localhost.localdomain>
2003-10-01 15:40 ` viro
2003-10-01 19:27 ` DervishD
2003-10-01 13:53 ` Jurjen Oskam
2003-10-01 14:09 ` Richard B. Johnson
2003-10-01 14:22 ` Andreas Schwab
2003-10-01 15:01 ` John Bradford
2003-10-01 13:58 ` Felipe Alfaro Solana
2003-10-01 14:21 ` DervishD
[not found] ` <1065044031.2158.23.camel@wynken.reefedge.com>
2003-10-01 14:37 ` Lisa R. Nelson
2003-10-01 15:11 ` Bas Mevissen
2003-10-01 15:12 ` Randy.Dunlap
2003-10-01 16:08 ` Richard B. Johnson
2003-10-01 19:21 ` DervishD
2003-10-01 20:30 ` viro
2003-10-01 17:23 ` Brett
2003-10-01 19:24 ` DervishD
2003-10-02 10:32 ` Christian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1065012013.4078.2.camel@lisaserver \
--to=lisanels@cableone.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox