File Permissions are incorrect. Security flaw in Linux

File Permissions are incorrect. Security flaw in Linux

[Lisa R. Nelson]

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

Re: File Permissions are incorrect. Security flaw in Linux

[Måns Rullgård]

"Lisa R. Nelson" <lisanels@cableone.net> writes:

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

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
mru@users.sf.net

Re: File Permissions are incorrect. Security flaw in Linux

[Mathieu Chouquet-Stringer]

lisanels@cableone.net ("Lisa R. Nelson") writes:
> [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.

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 : mathieu@newview.com
       Never attribute to malice that which can be adequately
                    explained by stupidity.
                     -- Hanlon's Razor --

Re: File Permissions are incorrect. Security flaw in Linux

[viro]

On Wed, Oct 01, 2003 at 06:40:13AM -0600, 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.

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.

Re: File Permissions are incorrect. Security flaw in Linux

[Jurjen Oskam]

On Wed, Oct 01, 2003 at 06:40:13AM -0600, 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.

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/

Re: File Permissions are incorrect. Security flaw in Linux

[Felipe Alfaro Solana]

On Wed, 2003-10-01 at 14: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.

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

Re: File Permissions are incorrect. Security flaw in Linux

[Richard B. Johnson]

On Wed, 1 Oct 2003, Jurjen Oskam wrote:

> On Wed, Oct 01, 2003 at 06:40:13AM -0600, 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.
>
> This *is* in agreement with Unix. It works exactly the same on AIX, for
> example.
>
> --
> Jurjen Oskam
>

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.

Re: File Permissions are incorrect. Security flaw in Linux

[DervishD]

    Hi Lisa :)

 * Lisa R. Nelson <lisanels@cableone.net> dixit:
> [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.

    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.

>     Permissions on a file basis take precedence over directory
> permissions (for most cases), but in Linux they do not.

    Just curiosity: which Unix behaves that way?

> In order to secure a file, you have to secure the directory which
> effects all files within it.

    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 verified this on a sun station today

    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.

> http://www.auburn.edu/oit/software/os/unix_files.html

    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".

> http://www.dartmouth.edu/~rc/help/faq/permissions.html

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

> http://www.december.com/unix/tutor/permissions.html

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

> http://www.itc.virginia.edu/desktop/web/permissions/

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

Re: File Permissions are incorrect. Security flaw in Linux

[Andreas Schwab]

"Richard B. Johnson" <root@chaos.analogic.com> writes:

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

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

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
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."

Re: File Permissions are incorrect. Security flaw in Linux

[Lisa R. Nelson]

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

-- 

Lisa R. Nelson <lisanels@cableone.net>

Re: File Permissions are incorrect. Security flaw in Linux

[John Bradford]

Quote from Jurjen Oskam <jurjen@stupendous.org>:
> On Wed, Oct 01, 2003 at 06:40:13AM -0600, 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.
> 
> This *is* in agreement with Unix. It works exactly the same on AIX, for
> example.

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.

Re: File Permissions are incorrect. Security flaw in Linux

[Bas Mevissen]

Lisa R. Nelson 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. 

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 :-)

 > So much for a friendly group.

You really have seen nothing yet :-)

Bas.

Re: File Permissions are incorrect. Security flaw in Linux

[Randy.Dunlap]

(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" <lisanels@cableone.net> 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/

Re: File Permissions are incorrect. Security flaw in Linux

[viro]

On Wed, Oct 01, 2003 at 08:15:23AM -0600, Lisa R. Nelson wrote:
> Excuse me? Have you even read about permissions on Unix?  I tried this
> on a Sun Unix system, and the Sun functions correctly.  What you are
> saying is stupid; If all directories are wide open, NO files are
> protected in any way, even if they are read only and owned by root?  Get
> real.  

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.

> I've worked on more OS's than you can imagine, and for many years.  This

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...

Re: File Permissions are incorrect. Security flaw in Linux

[Richard B. Johnson]

On Wed, 1 Oct 2003, Lisa R. Nelson 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.

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.

Re: File Permissions are incorrect. Security flaw in Linux

[Brett]

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


Lisa R. Nelson 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....
> 

Re: File Permissions are incorrect. Security flaw in Linux

[DervishD]

    Hi Richard :)

 * Richard B. Johnson <root@chaos.analogic.com> dixit:
> > 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.
> Well there were no hostile replies (yet)

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

> And you are being unfriendly. The correct response
> would have been; "Okay. Thanks".

    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/

Re: File Permissions are incorrect. Security flaw in Linux

[DervishD]

    Hi Brett :)

 * Brett <brettspamacct@fastclick.com> dixit:

> Just a helpful hint for the future: Do no jump to conclusions so easily. 

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

> If you would have said "Clarification needed, is this a bug?" or
> something, I think you would have gotten less hostile replies.

    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/

Re: File Permissions are incorrect. Security flaw in Linux

[DervishD]

    Hi Lisa :)

 * viro@parcelfarce.linux.theplanet.co.uk <viro@parcelfarce.linux.theplanet.co.uk> dixit:
> > What you are saying is stupid; If all directories are wide open,
> > NO files are protected in any way, even if they are read only and
> > owned by root?  Get real.

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

> > I've worked on more OS's than you can imagine, and for many years.
> 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...

    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/

Re: File Permissions are incorrect. Security flaw in Linux

[viro]

On Wed, Oct 01, 2003 at 09:21:26PM +0200, DervishD wrote:
 
>     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...

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.

Re: File Permissions are incorrect. Security flaw in Linux

[Christian]

Lisa R. Nelson wrote:

> [root@localhost root]# cd /
> [root@localhost /]# mkdir junk
> [root@localhost /]# chmod 777 junk

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.