File Permissions are incorrect. Security flaw in Linux

[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/

This is not a bug. Deleting a file is in effect a modification to the directory containing the file, not to the file itself. If the file has a hard link in another directory, it will still remain there, unmodified. If you want only the owner of a file to be able to delete it, set the sticky bit on the directory containing it, like this:

chmod 1777 /the/dir

This is commonly used on /tmp. It is also the all Unix systems I've been using work.

Måns Rullgård
[email protected]

That's perfectly normal, the directory where you put your files is writable by anyone and that's what matters. To remove a file, you don't need permission on the file but on the container, which is the directory in your case.
Make the directory 1777 instead of 777 or try the same thing under /tmp.

Mathieu Chouquet-Stringer              E-Mail : [email protected]
       Never attribute to malice that which can be adequately
                    explained by stupidity.
                     -- Hanlon's Razor --

No, it's your well-earned F for Unix 101. You should focus on Unix permissions model in general and sticky bit in particular when you take the course again. Have a nice semester.

What, create a world-writable directory without sticky bit and then wonder why everyone can remove files from there?

Would you mind posting the list of systems (with versions, preferably) where that behaviour would *not* match v7, 2.xBSD, 4.xBSD and derivatives (including SunOS 4), SunOS 5.5, SunOS 5.6, SunOS 5.7, SunOS 5.8, Linux, OSF/1, etc.?

In particular, I'm most curious about the exact version of "Sun Unix" you claim to have tried that on. That, and output of ls -ld on the directory in question.

The sad thing being, that's one claim I do *not* doubt. Lusers' ability to avoid learning for years had stopped amazing me a long time ago...

Hi Lisa :)

* [email protected] <[email protected]> dixit:

Well Lisa, if you write things like those, even after a rude
answer, the most you can expect is a more-than-rude reply...

Calm down, please ;))) Lisa, you were wrong, assume it. If you
have such working experience, you should have learned a bit more about Unix permissions...

Raúl Núñez de Arenas Coronado

Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

This *is* in agreement with Unix. It works exactly the same on AIX, for example.

Jurjen Oskam

PGP Key available at http://www.stupendous.org/

Yes. File removal is subject to DIRECTORY permissions.

Script started on Wed Oct 1 10:03:26 2003

# pwd
/tmp
# >foo
# chmod 744 foo
# ls -la
total 8
drwxrwxrwx   2 root     root         4096 Oct  1 10:03 .
drwxr-xr-x  25 root     root         4096 Oct  1 04:09 ..
-rwxr--r--   1 root     root            0 Oct  1 10:03 foo
-rw-r--r--   1 root     root            0 Oct  1 10:03 typescript
# su johnson
$ ls -la
total 8
drwxrwxrwx   2 root     root         4096 Oct  1 10:03 .
drwxr-xr-x  25 root     root         4096 Oct  1 04:09 ..
-rwxr--r--   1 root     root            0 Oct  1 10:03 foo
-rw-r--r--   1 root     root            0 Oct  1 10:03 typescript
$ pwd
/tmp
$ rm foo
rm: remove write-protected file `foo'? y
$ ls -la
total 8
drwxrwxrwx   2 root     root         4096 Oct  1 10:04 .
drwxr-xr-x  25 root     root         4096 Oct  1 04:09 ..
-rw-r--r--   1 root     root            0 Oct  1 10:03 typescript
$ exit
exit
# ls
typescript
# exit
exit
Script done on Wed Oct  1 10:04:17 2003

...So anything you put into "/tmp", for instance, can be deleted by anybody. This is the Unix way.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.

...Unless your /tmp is marked properly with +t (sticky bit), so that you can only delete your own files.

Andreas.

Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Quote from Jurjen Oskam <[email protected]>:

Interesting, though, POSIX doesn't define the sticky bit. What is even more interesting is that the chmod manual page answers just about everything that has come up in this thread, and yet it's still wasting LKML bandwidth.

John.

Don't know which Unix you are referring to, but on Solaris and Linux, the delete (unlink) and create file operations are subject to directory permissions. Thus, deleting a file requires write permission on the directory. The write permission on a file allows to modify its contents and has nothing to do with being able to delete it.

Thus, what you are seeing is completely normal:

1. mkdir /mydir
2. cd /mydir
3. chmod 777 .
4. touch myfile
5. chmod 444 myfile

Anyone will be able to delete "myfile" since the directory where it belongs (mydir) has full write privileges for anyone.

I recommend you using the sticky bit on shared directories, like /tmp. If a directory has the sticky bit enabled, a file can only be deleted by its owner (and root, of course):

1. mkdir /mydir
2. cd /mydir
3. chmod 1777 .
4. touch myfile

Now, "myfile" can only be deleted by its owner (or root), since the directory where it belongs is marked with the sticky bit.

HTH

Hi Lisa :)

* Lisa R. Nelson <[email protected]> dixit:

You're not right here: all Unices I have knowledge about has this
same scheme. But really it doesn't matter, because the reason behind this is that files are just links in a directory, so for deleting a file, that is, *unlinking* it, you need to have write permission on the *container*: the directory.

Just curiosity: which Unix behaves that way?

Not exactly, but you're true. You can use the sticky bit for
directories if you want them to be 'append only'. This way anybody can read your files if you want, add files and remove them, *but* they WON'T be able to delete YOUR files. This is used in /tmp, for example.

I may be wrong here, for a long time has passed since I last used
a SparcStation or similar, but AFAIK SunOS behaves like Linux in this issue. In fact, this is the common Unix behaviour.

Quote: "Permissions are divided into three types [...] Write
permission allows the user [...] For directories, write permission allows the user to create new files or delete files within that directory".

The same: "w [...] file is writeable. On a directory, write
access means you can add or delete files".

Nothing relevant. A lame tutorial on Unix permissions, BTW.

"Write [...] create a new file in the directory". Incomplete, but
will do...

As you can see, even your sources say exactly the same...

Raúl Núñez de Arenas Coronado

Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Ok, ok, I get it... It was an oversight on my part. But I'm sure surprised about some of the hostile replies I received. So much for a friendly group. People should remember that there's ALWAYS someone that knows more that YOU. In my case it was about permissions, what is it in your case? Microsoft scores points on being friendly... Yuck... Microsoft....

Lisa R. Nelson <[email protected]>

Actually, I think it to be to-the-point explanations of what the problem was. People even tried to explain it to you with some examples. I really would like all my problems were explained so well :-)

You really have seen nothing yet :-)

Bas.

(um, top-posting continued) :(

Some of the values that have been written about Linux developers are technical merit/correctness and honesty. Kindness isn't one that I recall reading about, although Linus did ask people to be a bit kinder.

I guess that "hostile" is relative. I read the replies and didn't rate anything as hostile. Depends on thick skin, maybe.

MS doesn't score points for customer support afaik. They may be friendly, but often not helpful. Maybe it's a case of one or the other but not both, but it doesn't have to be that way.

~Randy

On Wed, 01 Oct 2003 08:37:58 -0600 "Lisa R. Nelson" <[email protected]> wrote:

| Ok, ok, I get it... It was an oversight on my part.  But I'm sure
| surprised about some of the hostile replies I received.  So much for a
| friendly group.  People should remember that there's ALWAYS someone that
| knows more that YOU.  In my case it was about permissions, what is it in
| your case?  Microsoft scores points on being friendly... Yuck...
| Microsoft....
| 
| On Wed, 2003-10-01 at 15:33, Sam Baskinger wrote: 
| > The behavior you observed is in conformance with the POSIX specification
| > for the unlink() system call.  POSIX is one of the standard which Linux
| > seeks to comply with.
| > 
| > Do note that many unix implementations do not follow all standards
| > believing that they are making things "safer" or "better."  If you see a
| > different behavior on Solaris then perhaps this is one of those design
| > choices SUN made.
| > 
| > I'm sorry you had to type that long email. :-)
| > 
| > Sam
| > 
| > On Wed, 2003-10-01 at 08:40, Lisa R. Nelson wrote:
| > > [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/

Well there were no hostile replies (yet), even though some kernel developers took the time and bandwidth to explain about Unix file permissions. And you are being unfriendly. The correct response would have been; "Okay. Thanks".

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.

Hi Richard :)

* Richard B. Johnson <[email protected]> dixit:

Don't you think that viro@whatever reply was hostile?

If someone answers me something like "you are much of a dumb for
understanding the answer, so I'll just tell you that you're wrong" (and believe me, that 'joke' about a well earned F in Unix 101 falls in this category IMHO), I wouldn't bother to thank...

Most of the replies were polite, anyway, but some not ;)

Raúl Núñez de Arenas Coronado

Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

You know, it's really not a joke. Permissions model and meanings of individual permission bits *is* Unix 101 material and not knowing it (let alone claiming behaviour contrary to reality) will, indeed, earn you F.

To be completely blunt, original posting contained a lie. Given sequence of operations had not been tried on "Sun Unix". At all. Everything else would not get a reaction harsher than "you are thinking about behaviour of directories with sticky bit set; without it write permissions on directory are sufficient to remove files in it". Probably with reference to Unix FAQ (and maybe a nitpick to the above - append-only and immutable files are not removable).

9:1 says that all original poster had actually tried was rm /tmp/<something> on Solaris, which, of course, resulted in "permission denied". The rest was extrapolation. Which is not particulary endearing, to put it mildly.

The way original poster had reacted to replies ("You are all wrong, I Know(tm)") + reference to Great Experience(tm)(r) had warranted the rest, IMO.

And yes, we all screw up from time to time. Which is OK, provided that when said screwup is noticed you admit it instead of throwing a temper tantrum.

Just a helpful hint for the future: Do no jump to conclusions so easily.
You originally stated there's a bug in linux. This probably rubbed
people the wrong way, people here work hard on linux, some are grumpy, and for someone to come in here and tell them "here's a big fat bug in linux" when in fact it isn't a bug, well, many good people could become not so friendly. If you would have said "Clarification needed, is this a bug?" or something, I think you would have gotten less hostile replies.

Then again, maybe you're on to something, I've been very nice, unassuming and cordial about my filesystem cache question, maybe I need to post a message with the subject "Bug in vm/filesystem cache" so I can get a response. :(

Sincerely,

Brett

Hi Brett :)

* Brett <[email protected]> dixit:

Yes, this is true, too. Some of the answers were rude, but
claiming about a big bug (and such bug...) is not polite, neither.

Suspicion is the illness of programmers, I suppose ;))

Raúl Núñez de Arenas Coronado

Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

therefore is the sticky bit: users can still create files in the directory, but only remove files they are owning:

chmod 1777 /junk

(as your /tmp should be).

do you mean the behaviour has changed for some kernel version? did you notice another behaviour with kernel version x.y.?

Thanks,
Christian.