LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: R: Linux kernel source archive vulnerable
       [not found] ` <D432C2F98B6D1B4BAE47F2770FEFD6B612B8B7@to1mbxs02.replynet.prv>
@ 2006-09-11 18:29   ` Jon Lewis
  2006-09-12  5:06     ` Kyle Moffett
  0 siblings, 1 reply; 23+ messages in thread
From: Jon Lewis @ 2006-09-11 18:29 UTC (permalink / raw)
  To: Perego Paolo Franco, linux-kernel; +Cc: Hadmut Danisch, bugtraq

On Fri, 8 Sep 2006, Perego Paolo Franco wrote:

> Anyway just few considerations:
> 2) a good sysadmin is aware that /usr/src is NOT supposed to be world 
> writable

Ownership/permissions on /usr/src are irrelevant.  For some reason (bug in 
how they're being checked out of git, I assume), the latest kernel source 
tar files have all files and directories world writable.  This is not how 
it's been in the past and is not how it should be.

The change happened between 2.6.13.3 and 2.6.13.4.

$ tar -tvjf /var/ftp/pub/Linux/ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.3.tar.bz2 | less
tar: Record size = 8 blocks
drwxr-xr-x git/git           0 2005-10-03 19:27:35 linux-2.6.13.3/
-rw-r--r-- git/git       18691 2005-10-03 19:27:35 linux-2.6.13.3/COPYING
-rw-r--r-- git/git       89317 2005-10-03 19:27:35 linux-2.6.13.3/CREDITS
drwxr-xr-x git/git           0 2005-10-03 19:27:35 linux-2.6.13.3/Documentation/
-rw-r--r-- git/git       10244 2005-10-03 19:27:35 linux-2.6.13.3/Documentation/00-INDEX
-rw-r--r-- git/git        3699 2005-10-03 19:27:35 linux-2.6.13.3/Documentation/BUG-HUNTING
-rw-r--r-- git/git       13072 2005-10-03 19:27:35 linux-2.6.13.3/Documentation/Changes
-rw-r--r-- git/git       15351 2005-10-03 19:27:35 linux-2.6.13.3/Documentation/CodingStyle
-rw-r--r-- git/git       20407 2005-10-03 19:27:35 linux-2.6.13.3/Documentation/DMA-API.txt
-rw-r--r-- git/git       31996 2005-10-03 19:27:35 linux-2.6.13.3/Documentation/DMA-mapping.txt
drwxr-xr-x git/git           0 2005-10-03 19:27:35 linux-2.6.13.3/Documentation/DocBook/

$ tar -tvjf /var/ftp/pub/Linux/ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.4.tar.bz2 | less
tar: Record size = 8 blocks
drwxr-xr-x git/git           0 2005-10-10 14:54:29 linux-2.6.13.4/
-rw-rw-rw- git/git       18691 2005-10-10 14:54:29 linux-2.6.13.4/COPYING
-rw-rw-rw- git/git       89317 2005-10-10 14:54:29 linux-2.6.13.4/CREDITS
drwxrwxrwx git/git           0 2005-10-10 14:54:29 linux-2.6.13.4/Documentation/
-rw-rw-rw- git/git       10244 2005-10-10 14:54:29 linux-2.6.13.4/Documentation/00-INDEX
-rw-rw-rw- git/git        3699 2005-10-10 14:54:29 linux-2.6.13.4/Documentation/BUG-HUNTING
-rw-rw-rw- git/git       13072 2005-10-10 14:54:29 linux-2.6.13.4/Documentation/Changes
-rw-rw-rw- git/git       15351 2005-10-10 14:54:29 linux-2.6.13.4/Documentation/CodingStyle
-rw-rw-rw- git/git       20407 2005-10-10 14:54:29 linux-2.6.13.4/Documentation/DMA-API.txt
-rw-rw-rw- git/git       31996 2005-10-10 14:54:29 linux-2.6.13.4/Documentation/DMA-mapping.txt
drwxrwxrwx git/git           0 2005-10-10 14:54:29 linux-2.6.13.4/Documentation/DocBook/

In the very latest, even the source tree's root is 777.

$ tar -tvjf /var/ftp/pub/Linux/ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.13.tar.bz2 | less
tar: Record size = 8 blocks
drwxrwxrwx git/git           0 2006-09-08 23:23:25 linux-2.6.17.13/
-rw-rw-rw- git/git         462 2006-09-08 23:23:25 linux-2.6.17.13/.gitignore
-rw-rw-rw- git/git       18693 2006-09-08 23:23:25 linux-2.6.17.13/COPYING
-rw-rw-rw- git/git       89536 2006-09-08 23:23:25 linux-2.6.17.13/CREDITS
drwxrwxrwx git/git           0 2006-09-08 23:23:25 linux-2.6.17.13/Documentation/
-rw-rw-rw- git/git       10581 2006-09-08 23:23:25 linux-2.6.17.13/Documentation/00-INDEX
-rw-rw-rw- git/git        7249 2006-09-08 23:23:25 linux-2.6.17.13/Documentation/BUG-HUNTING
-rw-rw-rw- git/git       11655 2006-09-08 23:23:25 linux-2.6.17.13/Documentation/Changes

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-11 18:29   ` R: Linux kernel source archive vulnerable Jon Lewis
@ 2006-09-12  5:06     ` Kyle Moffett
  2006-09-12  5:27       ` Willy Tarreau
  2006-09-12 19:42       ` R: " David Wagner
  0 siblings, 2 replies; 23+ messages in thread
From: Kyle Moffett @ 2006-09-12  5:06 UTC (permalink / raw)
  To: Jon Lewis; +Cc: Perego Paolo Franco, linux-kernel, Hadmut Danisch, bugtraq

On Sep 11, 2006, at 14:29:58, Jon Lewis wrote:
> On Fri, 8 Sep 2006, Perego Paolo Franco wrote:
>
>> Anyway just few considerations:
>> 2) a good sysadmin is aware that /usr/src is NOT supposed to be  
>> world writable
>
> For some reason (bug in how they're being checked out of git, I  
> assume), the latest kernel source tar files have all files and  
> directories world writable.  This is not how it's been in the past  
> and is not how it should be.

-ENOBUG

Please see these threads and quit bringing up this topic like crazy:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113304241100330&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=114635639325551&w=2

To quote:
> Going over old ground again, any administrator a) compiling the  
> kernel as root or b) relying on GNU tar to make  
> _security_policy_decisions_ is completely insane.
>
> The only "trick" here is tar's decision not to apply umask, or root  
> uid/gid, to files in a tar when extracted as root.  This might make  
> sense for tars that you created and want to extract again (say  
> restoring a backup), but it certainly NEVER makes sense for files  
> downloaded off the Internet.

So if you must cause a senseless hubbub on securityfocus.com, please  
don't spill it over onto LKML.  This sort of thing is at _worst_ a  
bug in GNU tar that it's behavior is different when root.  I run a  
linux system with SELinux where user 0 is no different than any other  
user and has no special permissions at all, and this kind of  
stupidity bites me a lot.  My user 0 is "kyle" when I want to chown  
files I switch to the "sysadm" role, or if I absolutely need to  
override security policy for some reason I jump through hoops to get  
to the "root" role.  In neither of those cases do I care what UID I am.

So either deal insecure permissions when you can't be bothered to use  
GNU tar securely (easy), don't compile your kernel as root (easier)  
or fix GNU tar not to assume UID 0 is God in the first place.

Cheers,
Kyle Moffett

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Linux kernel source archive vulnerable
  2006-09-12  5:06     ` Kyle Moffett
@ 2006-09-12  5:27       ` Willy Tarreau
  2006-09-12 19:42       ` R: " David Wagner
  1 sibling, 0 replies; 23+ messages in thread
From: Willy Tarreau @ 2006-09-12  5:27 UTC (permalink / raw)
  To: Kyle Moffett
  Cc: Jon Lewis, Perego Paolo Franco, linux-kernel, Hadmut Danisch, torvalds

On Tue, Sep 12, 2006 at 01:06:37AM -0400, Kyle Moffett wrote:
> On Sep 11, 2006, at 14:29:58, Jon Lewis wrote:
> >On Fri, 8 Sep 2006, Perego Paolo Franco wrote:
> >
> >>Anyway just few considerations:
> >>2) a good sysadmin is aware that /usr/src is NOT supposed to be  
> >>world writable
> >
> >For some reason (bug in how they're being checked out of git, I  
> >assume), the latest kernel source tar files have all files and  
> >directories world writable.  This is not how it's been in the past  
> >and is not how it should be.
> 
> -ENOBUG
> 
> Please see these threads and quit bringing up this topic like crazy:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113304241100330&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114635639325551&w=2

BTW, since git 1.4.2, it's possible to specify "umask=022" in the [tar]
section of the repo config to bring back the old behaviour. Maybe it
would be a good idea to use it on Linus' side to make everyone happy ?

Regards,
Willy


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-12  5:06     ` Kyle Moffett
  2006-09-12  5:27       ` Willy Tarreau
@ 2006-09-12 19:42       ` David Wagner
  2006-09-12 20:35         ` linux-os (Dick Johnson)
  1 sibling, 1 reply; 23+ messages in thread
From: David Wagner @ 2006-09-12 19:42 UTC (permalink / raw)
  To: linux-kernel

Kyle Moffett  wrote:
>Please see these threads and quit bringing up this topic like crazy:
>http://marc.theaimsgroup.com/?l=linux-kernel&m=113304241100330&w=2
>http://marc.theaimsgroup.com/?l=linux-kernel&m=114635639325551&w=2

I've read those threads in detail.  Those threads give no justification
whatsoever about why the files are stored in tar with world-writeable
permissions.  The posts to those threads just blame the victim, blame
the maintainers of tar, and point fingers at everyone else.  I cannot
see any good reason why the files in tar need to have world-writeable
permissions.  It seems to me like a simple and reasonable request to make
them non-world-writeable.  It can't hurt, and it might help a few users.
I cannot fathom why there is such resistance to such a simple request.

Just because it is a bug in tar doesn't mean that Linux developers have
to create their tarfile in a way that tickles the bug.  Two wrongs don't
make a right.

Just because it doesn't affect you doesn't mean that it isn't an issue.
You're not the only person in the world.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-12 19:42       ` R: " David Wagner
@ 2006-09-12 20:35         ` linux-os (Dick Johnson)
  2006-09-12 21:35           ` David Wagner
  0 siblings, 1 reply; 23+ messages in thread
From: linux-os (Dick Johnson) @ 2006-09-12 20:35 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel


On Tue, 12 Sep 2006, David Wagner wrote:

> Kyle Moffett  wrote:
>> Please see these threads and quit bringing up this topic like crazy:
>> http://marc.theaimsgroup.com/?l=linux-kernel&m=113304241100330&w=2
>> http://marc.theaimsgroup.com/?l=linux-kernel&m=114635639325551&w=2
>
> I've read those threads in detail.  Those threads give no justification
> whatsoever about why the files are stored in tar with world-writeable
> permissions.  The posts to those threads just blame the victim, blame
> the maintainers of tar, and point fingers at everyone else.  I cannot
> see any good reason why the files in tar need to have world-writeable
> permissions.  It seems to me like a simple and reasonable request to make
> them non-world-writeable.  It can't hurt, and it might help a few users.
> I cannot fathom why there is such resistance to such a simple request.
>
> Just because it is a bug in tar doesn't mean that Linux developers have
> to create their tarfile in a way that tickles the bug.  Two wrongs don't
> make a right.
>
> Just because it doesn't affect you doesn't mean that it isn't an issue.
> You're not the only person in the world.
> -

Try `info umask`. That will tell you how, tar created files in the
achieve that are world writable. The automatic daemon that executed
tar was root, using this mask for world-write permission. It's not
a tar bug, it is how it __must__ create files so that when a non-
root user executes tar, tar can change the owner to the person un-
tarring the achieve, AND, incidentally, set the permissions to the
new owners file creation mask set with `unmask`. If the files were not
world-writable in the archieve, you'd be up the creek trying to extract
files into your directories, with your ownership, and with your
permissions. Tar would have to execute as SUID root, and I don't
think even you would like that! Tar could then overwrite anything,
anywhere, NotGood(tm).

If you persist in un-tarring files as root, you get what you've got
and it is not a bug.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.66 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-12 20:35         ` linux-os (Dick Johnson)
@ 2006-09-12 21:35           ` David Wagner
  2006-09-12 22:56             ` Rene Scharfe
  0 siblings, 1 reply; 23+ messages in thread
From: David Wagner @ 2006-09-12 21:35 UTC (permalink / raw)
  To: linux-kernel

linux-os \(Dick Johnson\) wrote:
>On Tue, 12 Sep 2006, David Wagner wrote:
>> Just because it is a bug in tar doesn't mean that Linux developers have
>> to create their tarfile in a way that tickles the bug.  Two wrongs don't
>> make a right.
>
>It's not a tar bug, [...]

You misunderstand my point.  I don't care whether it is a tar bug or not.
I'm not claiming it is a tar bug.  I'm saying that people on those threads
claimed that this is a tar bug and used that as an excuse to do nothing
about the problem of world-writeable files in the Linux tar archive.
I'm saying that's a lousy excuse.  What I'm saying is that, even if we
accept that it is a tar bug, that's not a good excuse for doing nothing
about the problem.  Of course, if it is not a tar bug, then that makes
it an even weaker excuse.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-12 21:35           ` David Wagner
@ 2006-09-12 22:56             ` Rene Scharfe
  2006-09-13  1:17               ` David Wagner
  0 siblings, 1 reply; 23+ messages in thread
From: Rene Scharfe @ 2006-09-12 22:56 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel mailing list

David Wagner schrieb:
> You misunderstand my point.  I don't care whether it is a tar bug or 
> not. I'm not claiming it is a tar bug.  I'm saying that people on 
> those threads claimed that this is a tar bug and used that as an 
> excuse to do nothing about the problem of world-writeable files in 
> the Linux tar archive. I'm saying that's a lousy excuse.  What I'm 
> saying is that, even if we accept that it is a tar bug, that's not a 
> good excuse for doing nothing about the problem.  Of course, if it is
> not a tar bug, then that makes it an even weaker excuse.

GNU tar offers two options on how to interpret the security mode bits in
a tar archive when you extract files from it: it either applies your
umask or it doesn't.

If you let it apply your umask and the mode in the archive is 0777 then
the extracted files will get exactly the permission you want them to
have.  E.g. you could grant group write rights, all without running chmod.

It may be unfortunate that GNU tar defaults to not apply the umask when
run as root, thereby trusting the permissions in the archive.  However,
this is not a bug but rather a feature which made sense back when tar
files were primarily used as backup files and not as transport containers.

So, don't run tar in local backup restore mode if you deal with archives
created by someone else, unless you want to set the permissions exactly
as they are stored in the archive.  If you are root then you should know
that GNU tar defaults to the permission preserving mode and how to
switch to umask applying mode.

René

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-12 22:56             ` Rene Scharfe
@ 2006-09-13  1:17               ` David Wagner
  2006-09-13  4:33                 ` Willy Tarreau
                                   ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: David Wagner @ 2006-09-13  1:17 UTC (permalink / raw)
  To: linux-kernel

Rene Scharfe  wrote:
>[details on how GNU tar works, snipped]

Again, you miss my point.  I already know how tar works, but that's not
my point.  Why is it that people are so unwilling to address the real
issue here?  Let's try a few facts:

    (a) The Linux kernel tar archive contains files with world-writeable
    permissions.

    (b) There is no need for those files to have world-writeable
    permissions.  It doesn't serve any particular purpose.  If the
    permissions in the tar archive were changed to be not world-writeable,
    no harm would be done.

    (c) Some users may get screwed over by virtue of the fact that those
    files are listed in the tar archive with world-writeable permissions.
    (Sure, if every user was an expert on "tar" and on security, then
    maybe no one would get screwed over.  But in the real world, that's
    not the case.)

    (d) Consequently, the format of the Linux kernel tar archive is
    exposing some users to unnecessary riskis.

    (e) The Linux kernel folks could take a quick and easy step that
    would eliminate this risk.  That step would involve storing the
    files in the tar archive with permissions that were more reasonable
    (not world-writeable would be a good start!).  This step wouldn't
    hurt anyone.  There's no downside.

    (f) Yet the Linux kernel folks refuse to take this step, and any
    time someone mentions that there is something the Linux kernel folks
    could do about the problem, someone tries to change the topic to
    something else (e.g., complaints about bugs in GNU tar, suggestions
    that the user should invoke tar with some other option, claims that
    this question has been addressed before, you name it).

So why is it that the tar archive is structured this way?  Why are
the Linux kernel folks unnecessarily exposing their users to risk?
What purpose, exactly, does it serve to have these files stored with
world-writeable permissions?

Folks on the Linux kernel mailing list seem to be reluctant to admit these
facts forthrightly.  The posts I've seen mostly seem to have little or
no sympathy for users who get screwed over.  The attitude seems to be:
if you get screwed over, it's your fault and your problem.  Why is that?
If there is a simple step that Linux developers can take to eliminate
this risk, why is there such reluctance to take it, and why is there
such eagerness to point the finger at someone else?

The way I see it, storing files in a tar archive with world-writeable
permissions is senseless.  Why do such a strange thing on purpose?

It all seems thoroughly mysterious to me.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  1:17               ` David Wagner
@ 2006-09-13  4:33                 ` Willy Tarreau
  2006-09-13  5:34                   ` David Wagner
  2006-09-13  8:51                 ` Stefan Richter
  2006-09-14 23:04                 ` Bill Davidsen
  2 siblings, 1 reply; 23+ messages in thread
From: Willy Tarreau @ 2006-09-13  4:33 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel

On Wed, Sep 13, 2006 at 01:17:48AM +0000, David Wagner wrote:
> Rene Scharfe  wrote:
> >[details on how GNU tar works, snipped]
> 
> Again, you miss my point.  I already know how tar works, but that's not
> my point.  Why is it that people are so unwilling to address the real
> issue here?  Let's try a few facts:
> 
>     (a) The Linux kernel tar archive contains files with world-writeable
>     permissions.
> 
>     (b) There is no need for those files to have world-writeable
>     permissions.  It doesn't serve any particular purpose.  If the
>     permissions in the tar archive were changed to be not world-writeable,
>     no harm would be done.
> 
>     (c) Some users may get screwed over by virtue of the fact that those
>     files are listed in the tar archive with world-writeable permissions.
>     (Sure, if every user was an expert on "tar" and on security, then
>     maybe no one would get screwed over.  But in the real world, that's
>     not the case.)
> 
>     (d) Consequently, the format of the Linux kernel tar archive is
>     exposing some users to unnecessary riskis.
> 
>     (e) The Linux kernel folks could take a quick and easy step that
>     would eliminate this risk.  That step would involve storing the
>     files in the tar archive with permissions that were more reasonable
>     (not world-writeable would be a good start!).  This step wouldn't
>     hurt anyone.  There's no downside.
> 
>     (f) Yet the Linux kernel folks refuse to take this step, and any
>     time someone mentions that there is something the Linux kernel folks
>     could do about the problem, someone tries to change the topic to
>     something else (e.g., complaints about bugs in GNU tar, suggestions
>     that the user should invoke tar with some other option, claims that
>     this question has been addressed before, you name it).
> 
> So why is it that the tar archive is structured this way?  Why are
> the Linux kernel folks unnecessarily exposing their users to risk?
> What purpose, exactly, does it serve to have these files stored with
> world-writeable permissions?
> 
> Folks on the Linux kernel mailing list seem to be reluctant to admit these
> facts forthrightly.  The posts I've seen mostly seem to have little or
> no sympathy for users who get screwed over.  The attitude seems to be:
> if you get screwed over, it's your fault and your problem.  Why is that?
> If there is a simple step that Linux developers can take to eliminate
> this risk, why is there such reluctance to take it, and why is there
> such eagerness to point the finger at someone else?
> 
> The way I see it, storing files in a tar archive with world-writeable
> permissions is senseless.  Why do such a strange thing on purpose?
> 
> It all seems thoroughly mysterious to me.

The initial reason is that Linus now uses the "git-tar-tree" command
which creates the full tar archive from the tree. It does not use tar,
it know how to produce the tar format itself. The command has to set
permissions on the files, and by default, it sets full permissions to
the files. This began in early git history. Recently, I've been using
git for another project. There, it has annoyed me to put such
permissions in tar files which mostly contained scripts. So I proposed
a patch to add the umask option to the repository config file which
solved my problem. Junio merged it into git 1.4.2 (so it's very recent).
It would be perfectly usable for linux too (in fact, I do use it on the
2.4 tree).

Maybe you should ask Linus if he considers using this ? When he initially
refused doing anything, it was when every single change would have needed
to change git. Now that git has changed, maybe Linus would consider going
back to the old behaviour ?

Regards,
Willy


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  4:33                 ` Willy Tarreau
@ 2006-09-13  5:34                   ` David Wagner
  2006-09-13  6:17                     ` Kyle Moffett
  0 siblings, 1 reply; 23+ messages in thread
From: David Wagner @ 2006-09-13  5:34 UTC (permalink / raw)
  To: linux-kernel

Willy Tarreau  wrote:
>The initial reason is that Linus now uses the "git-tar-tree" command
>which creates the full tar archive from the tree. It does not use tar,
>it know how to produce the tar format itself. The command has to set
>permissions on the files, and by default, it sets full permissions to
>the files.

Ahh, thanks for the explanation.  That's helpful.

So it sounds like git-tar-tree has a bug; its default isn't setting
meaningful permissions on the files that it puts into the tar archive.
I hope the maintainers of git-tar-tree will consider fixing this bug.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  5:34                   ` David Wagner
@ 2006-09-13  6:17                     ` Kyle Moffett
  2006-09-13  6:26                       ` David Wagner
  2006-09-13  6:26                       ` Jan Engelhardt
  0 siblings, 2 replies; 23+ messages in thread
From: Kyle Moffett @ 2006-09-13  6:17 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel

On Sep 13, 2006, at 01:34:01, David Wagner wrote:
> Willy Tarreau  wrote:
>> The initial reason is that Linus now uses the "git-tar-tree" command
>> which creates the full tar archive from the tree. It does not use  
>> tar,
>> it know how to produce the tar format itself. The command has to set
>> permissions on the files, and by default, it sets full permissions to
>> the files.
>
> Ahh, thanks for the explanation.  That's helpful.
>
> So it sounds like git-tar-tree has a bug; its default isn't setting
> meaningful permissions on the files that it puts into the tar archive.
> I hope the maintainers of git-tar-tree will consider fixing this bug.

Let me reiterate:  This is not a bug!

Here are a few facts:

1)  When I run "touch foo", the "touch" command uses permissions  
0666, which are modified by my umask before hitting the FS.  (same  
behavior for all UIDs)

2)  When I run "gcc -c foo.c -o foo.o", the "gcc" command uses  
permissions 0666, which are modified by my umask before hitting the  
FS.  (same behavior for all UIDs)

3)  When I run "vim foo.c", the "vim" command uses permissions 0666  
for new files, which are modified by my umask before hitting the FS.   
(same behavior for all UIDs)

4)  When I run "tar -xvf foo.tar" as a normal user, the "tar" command  
uses permissions from the archive for new files, which are modified  
by my umask before hitting the FS.

5)  Do you see the pattern here?


Now when I run that tar command as root, for some reason they assume  
that just because my UID is 0 I want to try to ignore my umask while  
extracting my j_random.tar file.  How does this follow from the  
behavior of any other programs mentioned above?

The program "git-tar-tree" has no bug.  It creates the tar archive  
such that when extracted as a normal user the users' umask is applied  
exactly as for every other standard program.  If anything the "bug"  
is in tar assuming that every archive file extracted as UID 0 is a  
backup, or in the admin assuming that tar doesn't behave differently  
when run as UID 0.

Cheers,
Kyle Moffett


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  6:17                     ` Kyle Moffett
@ 2006-09-13  6:26                       ` David Wagner
  2006-09-13  6:49                         ` Kyle Moffett
  2006-09-13 10:45                         ` Martin Mares
  2006-09-13  6:26                       ` Jan Engelhardt
  1 sibling, 2 replies; 23+ messages in thread
From: David Wagner @ 2006-09-13  6:26 UTC (permalink / raw)
  To: linux-kernel

Kyle Moffett  wrote:
>On Sep 13, 2006, at 01:34:01, David Wagner wrote:
>> So it sounds like git-tar-tree has a bug; its default isn't setting
>> meaningful permissions on the files that it puts into the tar archive.
>> I hope the maintainers of git-tar-tree will consider fixing this bug.
>
>Let me reiterate:  This is not a bug!

I think it is a bug.  It sounds like git-tar-tree is storing the wrong
set of permissions in the tar archive.  When I run "tar cf foo.tar
bar", and bar has permissions 0644, then tar inserts an entry into the
archive for "bar" with its permissions listed as 0644 (*not* 0666).
If "tar cf foo.tar bar" just ignored the permissions on bar and always
used a default of 0666 out of laziness, that would be a bug in "tar cf".
The same goes for git-tar-tree.  It seems to me that git-tar-tree ought
to behave the same as "tar cf".

In any case, regardless of whether this is by design or not, it is not
courteous to your users to distribute tar files where all the files have
permissions 0666.  That's not a user-friendly to do.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  6:17                     ` Kyle Moffett
  2006-09-13  6:26                       ` David Wagner
@ 2006-09-13  6:26                       ` Jan Engelhardt
  2006-09-13 19:49                         ` Willy Tarreau
  1 sibling, 1 reply; 23+ messages in thread
From: Jan Engelhardt @ 2006-09-13  6:26 UTC (permalink / raw)
  To: Kyle Moffett; +Cc: David Wagner, linux-kernel

>> 
>> Ahh, thanks for the explanation.  That's helpful.
>> 
>> So it sounds like git-tar-tree has a bug; its default isn't setting
>> meaningful permissions on the files that it puts into the tar archive.
>> I hope the maintainers of git-tar-tree will consider fixing this bug.
>
> Let me reiterate:  This is not a bug!
>
> Here are a few facts:
>
> 4)  When I run "tar -xvf foo.tar" as a normal user, the "tar" command uses
> permissions from the archive for new files, which are modified by my umask
> before hitting the FS.
>
> 5)  Do you see the pattern here?
>
> Now when I run that tar command as root, for some reason they assume that just
> because my UID is 0 I want to try to ignore my umask while extracting my
> j_random.tar file.  How does this follow from the behavior of any other
> programs mentioned above?

> The program "git-tar-tree" has no bug.  It creates the tar archive such that
> when extracted as a normal user the users' umask is applied exactly as for
> every other standard program.  If anything the "bug" is in tar assuming that
> every archive file extracted as UID 0 is a backup, or in the admin assuming
> that tar doesn't behave differently when run as UID 0.

The 'complaint' made is that while the tar archive is created, 0666 gets
written into it. However, most software projects out there always make sure
that files are 0644 before tar -cvf'ing their tree.


Jan Engelhardt
-- 

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  6:26                       ` David Wagner
@ 2006-09-13  6:49                         ` Kyle Moffett
  2006-09-13  6:59                           ` David Wagner
  2006-09-13 10:45                         ` Martin Mares
  1 sibling, 1 reply; 23+ messages in thread
From: Kyle Moffett @ 2006-09-13  6:49 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel

On Sep 13, 2006, at 02:26:23, David Wagner wrote:
> Kyle Moffett  wrote:
>> On Sep 13, 2006, at 01:34:01, David Wagner wrote:
>>> So it sounds like git-tar-tree has a bug; its default isn't setting
>>> meaningful permissions on the files that it puts into the tar  
>>> archive.
>>> I hope the maintainers of git-tar-tree will consider fixing this  
>>> bug.
>>
>> Let me reiterate:  This is not a bug!
>
> I think it is a bug.  It sounds like git-tar-tree is storing the  
> wrong set of permissions in the tar archive.

No, git-tar-tree is storing the desired permissions (0666 and 0777)  
in the tar archive.  This is not a bug, those are actually the  
permissions we want in the tar archive.

> When I run "tar cf foo.tar bar", and bar has permissions 0644, then  
> tar inserts an entry into the archive for "bar" with its  
> permissions listed as 0644 (*not* 0666).

This is irrelevant because the actual permissions copied from GIT to  
the tar archive are 0666 (as desired).

> If "tar cf foo.tar bar" just ignored the permissions on bar and  
> always used a default of 0666 out of laziness, that would be a bug  
> in "tar cf". The same goes for git-tar-tree.  It seems to me that  
> git-tar-tree ought to behave the same as "tar cf".

It does; except the permissions in git are 0666 for files and 0777  
for directories so that your umask takes effect when you check out  
from GIT or extract a tar archive exported from GIT.

> In any case, regardless of whether this is by design or not, it is  
> not courteous to your users to distribute tar files where all the  
> files have permissions 0666.  That's not a user-friendly to do.

No, it is user-friendly.  This is like distributing programs who use  
open(..., 0666) when opening globally-readable files.  Programs that  
use open(..., 0644) are considered uncourteous because they  
intentionally ignore your umask.  The only cases where that is  
acceptable is user SSH private key files.  Likewise we store files  
with permissions 0666 in the tar archive so that the user's umask is  
applied to them properly.

o   Do *not* extract kernel trees as root
o   Do *not* build kernel trees as root
o   Do *not* package kernel trees as root
o   Do install kernel packages as root

It's that simple.  Please drop this discussion as it was brought up  
repeatedly on this list and the fairly general consensus is that this  
is not a bug in either the kernel source trees or GIT.

Cheers,
Kyle Moffett


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  6:49                         ` Kyle Moffett
@ 2006-09-13  6:59                           ` David Wagner
  2006-09-13  8:12                             ` Kyle Moffett
  0 siblings, 1 reply; 23+ messages in thread
From: David Wagner @ 2006-09-13  6:59 UTC (permalink / raw)
  To: linux-kernel

Kyle Moffett  wrote:
>No, git-tar-tree is storing the desired permissions (0666 and 0777)  
>in the tar archive.  This is not a bug, those are actually the  
>permissions we want in the tar archive.

Those may be the permissions *you* want, but they're not the permissions
I suspect many users would prefer.  Take a look at any open-source
project that ships tar archives of their source code.  Do they ship
tarballs of their source code where all the files have 0666 permissions?
Not in my experience.  That should tell you something.

Telling me that this is "by design" is not a very persuasive response
when my claim is that the design is poorly chosen.

>No, it is user-friendly.  This is like distributing programs who use  
>open(..., 0666) when opening globally-readable files.

It's not the same.  There's a reason that most other open-source
projects are careful not to distribute 0666 files in their tar archives.

>o   Do *not* extract kernel trees as root

I don't see anything unreasonable about extracting tarballs from a
trusted source as root (unless, of course, the folks who put together
the tarballs are malicious or careless or can't be trusted).

I don't see any good justification for this other than that the
maintainers of git-tar-tree can't be bothered to store more reasonable
permissions in the tar archive.  It smells like a workaround that is
designed to make the lives of the git-tar-tree programmers easier --
but at the cost of making users lives a little harder.  That's what I
mean when I said that this decision doesn't seem very user-friendly.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  6:59                           ` David Wagner
@ 2006-09-13  8:12                             ` Kyle Moffett
  2006-09-14 22:38                               ` David Wagner
  0 siblings, 1 reply; 23+ messages in thread
From: Kyle Moffett @ 2006-09-13  8:12 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel

On Sep 13, 2006, at 02:59:31, David Wagner wrote:
> Kyle Moffett  wrote:
>> No, git-tar-tree is storing the desired permissions (0666 and  
>> 0777)   in the tar archive.  This is not a bug, those are actually  
>> the permissions we want in the tar archive.
>
> Those may be the permissions *you* want, but they're not the  
> permissions I suspect many users would prefer.

How do you decide what users would prefer?  I seem to recall the UNIX  
way to do that is umask which works perfectly with tar as a normal  
user and kernel tarballs.  I fail to see how you get world-writable  
files from a kernel tree unless your umask is 0000 or you're using  
tar in backup-mode; which is senseless on a tar file not built to  
restore as a backup.  For that matter, how do you determine which  
user it should extract as?  UID 0?  Linus' UID?  My UID?  What  
happens when I extract files on my SELinux system under the sysadm  
role as UID 500?  Should they get UID 0 because I have chown  
permissions and the author of the tar archive was tarring as root?

Relying on GNU tar and/or the permissions embedded in a tar file you  
downloaded from the internet to enforce your security policy is going  
to lead to a world of pain.

Besides, even Linus said:
> I would suggest that people who compile new kernels should:
> [...]
> - compile the kernel in their own home directory, as their very own  
> selves.  No need to be root to compile the kernel.  You need to be  
> root to _install_ the kernel, but that's different.


> Take a look at any open-source project that ships tar archives of  
> their source code.  Do they ship tarballs of their source code  
> where all the files have 0666 permissions?

Actually, if you start browsing random software tarballs you'll find  
that 1 in 5 or so has world-write permissions on at _minimum_ the  
root directory, more often the whole source tree.

I ran:

> for i in *.tar.gz; do tar -tvzf $i | head -n 1; done | less

on my directory of source tarballs and just going alphabetically down  
the list here's a list I found with drwxrwxrwx for the root directory  
of the archive:

OpenSP-1.5.1.tar.gz
bison-2.1.tar.gz
cyrus-sasl-2.1.21.tar.gz
findutils-4.2.20.tar.gz
gawk-3.1.4.tar.gz
gd-2.0.33.tar.gz
glib-1.2.10.tar.gz
gmp-4.2.1.tar.gz
guile-1.4.tar.gz
gzip-1.2.4a.tar.gz
libtool-1.5.22.tar.gz
links-0.99.tar.gz
mpfr-2.2.0.tar.gz
openMotif-2.2.3.tar.gz

If this is really a "security issue" as you claim and not an admin- 
caused PEBKAC problem then a lot more software than the kernel is at  
risk.  At least with the kernel we can expect people to have some  
idea what they're doing, with some of the software above there are  
README files that say "BEGINNER TUTORIAL" and go over the basics of  
configure scripts.

So is this really about security or about _you_ being too lazy to  
pass the appropriate option to tar when unpacking a software tarball  
as root?

Cheers,
Kyle Moffett

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  1:17               ` David Wagner
  2006-09-13  4:33                 ` Willy Tarreau
@ 2006-09-13  8:51                 ` Stefan Richter
  2006-09-14 23:04                 ` Bill Davidsen
  2 siblings, 0 replies; 23+ messages in thread
From: Stefan Richter @ 2006-09-13  8:51 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel

David Wagner wrote:
>     (a) The Linux kernel tar archive contains files with world-writeable
>     permissions.

The group's and others' permissions in the tar archive don't matter.
They have no meaning on the local system. These archives are
distributions of sources and a few scripts --- they are not local archives.

>     (b) There is no need for those files to have world-writeable
>     permissions.  It doesn't serve any particular purpose.

Correction: The group's and others' permissions, regardless how they are
set in the tar archive, don't serve any particular purpose. You should
consequently demand that an archive format is used which does not
transfer group's and others' permissions at all.

>     (c) Some users may get screwed over by virtue of the fact that those
>     files are listed in the tar archive with world-writeable permissions.

Correction: Some users who set a wrong umask when creating files by
extraction from these archives and then attempt to build an own kernel
from that may screw themselves over.

The danger here as that users who handle umask in a wrong way actually
run self-made kernels. _This_ is what you should campaign against first.
-- 
Stefan Richter
-=====-=-==- =--= -==-=
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  6:26                       ` David Wagner
  2006-09-13  6:49                         ` Kyle Moffett
@ 2006-09-13 10:45                         ` Martin Mares
  2006-09-13 11:13                           ` Jan Engelhardt
  1 sibling, 1 reply; 23+ messages in thread
From: Martin Mares @ 2006-09-13 10:45 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel

Hello!

> In any case, regardless of whether this is by design or not, it is not
> courteous to your users to distribute tar files where all the files have
> permissions 0666.  That's not a user-friendly to do.

I disagree.

(1) Some systems use per-user groups and create all files group-writeable
by default, i.e., they set the umask to 002. If you want to be user-friendly,
you should respect this setting, so the permissions in the tar archives you
distribute should be 666.

(2) People extracting random archives as root with preserving permissions
(and owners) are relying on *ALL* archive creators using what they suppose
are the right permissions, which is at least simple-minded, if not completely
silly. If you want to help such users, you should do so by helping them
understand they do a wrong thing and not by hiding the problem in a single
specific case.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
First law of socio-genetics: Celibacy is not hereditary.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13 10:45                         ` Martin Mares
@ 2006-09-13 11:13                           ` Jan Engelhardt
  0 siblings, 0 replies; 23+ messages in thread
From: Jan Engelhardt @ 2006-09-13 11:13 UTC (permalink / raw)
  To: Martin Mares; +Cc: David Wagner, linux-kernel


>> In any case, regardless of whether this is by design or not, it is not
>> courteous to your users to distribute tar files where all the files have
>> permissions 0666.  That's not a user-friendly to do.
>
>I disagree.
>
>(1) Some systems use per-user groups and create all files group-writeable
>by default, i.e., they set the umask to 002. If you want to be user-friendly,
>you should respect this setting, so the permissions in the tar archives you
>distribute should be 666.
>
>(2) People extracting random archives as root with preserving permissions
>(and owners) are relying on *ALL* archive creators using what they suppose
>are the right permissions, which is at least simple-minded, if not completely
>silly. If you want to help such users, you should do so by helping them
>understand they do a wrong thing and not by hiding the problem in a single
>specific case.

And for those who -- for whatever reason -- extract kernelballs as root, 
should go use --no-same-permission.


Jan Engelhardt
-- 

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  6:26                       ` Jan Engelhardt
@ 2006-09-13 19:49                         ` Willy Tarreau
  0 siblings, 0 replies; 23+ messages in thread
From: Willy Tarreau @ 2006-09-13 19:49 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Kyle Moffett, David Wagner, linux-kernel

On Wed, Sep 13, 2006 at 08:26:57AM +0200, Jan Engelhardt wrote:
> >> 
> >> Ahh, thanks for the explanation.  That's helpful.
> >> 
> >> So it sounds like git-tar-tree has a bug; its default isn't setting
> >> meaningful permissions on the files that it puts into the tar archive.
> >> I hope the maintainers of git-tar-tree will consider fixing this bug.
> >
> > Let me reiterate:  This is not a bug!
> >
> > Here are a few facts:
> >
> > 4)  When I run "tar -xvf foo.tar" as a normal user, the "tar" command uses
> > permissions from the archive for new files, which are modified by my umask
> > before hitting the FS.
> >
> > 5)  Do you see the pattern here?
> >
> > Now when I run that tar command as root, for some reason they assume that just
> > because my UID is 0 I want to try to ignore my umask while extracting my
> > j_random.tar file.  How does this follow from the behavior of any other
> > programs mentioned above?
> 
> > The program "git-tar-tree" has no bug.  It creates the tar archive such that
> > when extracted as a normal user the users' umask is applied exactly as for
> > every other standard program.  If anything the "bug" is in tar assuming that
> > every archive file extracted as UID 0 is a backup, or in the admin assuming
> > that tar doesn't behave differently when run as UID 0.
> 
> The 'complaint' made is that while the tar archive is created, 0666 gets
> written into it.

Let me repeat it : git-tar-tree can use a umask to set something different.

> However, most software projects out there always make sure
> that files are 0644 before tar -cvf'ing their tree.

The real problem IMHO is that many people got used for 10 years to receive
kernels packaged by user 'linus' with perms 0644, and suddenly their
(discutable) habits are considerably upset because of what initially was
a limitation in the tool, which was argumented as a feature and might not
change anytime now.

Moral of the story : do not ever try to convince Linus he's wrong
when you disagree with him, because the argument he will give you
will quickly become desired features :-)

> Jan Engelhardt

Regards,
Willy


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  8:12                             ` Kyle Moffett
@ 2006-09-14 22:38                               ` David Wagner
  2006-09-15  7:28                                 ` Stefan Richter
  0 siblings, 1 reply; 23+ messages in thread
From: David Wagner @ 2006-09-14 22:38 UTC (permalink / raw)
  To: linux-kernel

I get the impression that people are tired of hearing about this,
so I thought I'd collect my responses to the most recent set of posts
into a single message.  I'll try to make this my last message on this
subject.

Kyle Moffett wrote:
> I fail to see how you get world-writable  
> files from a kernel tree unless your umask is 0000 or you're using  
> tar in backup-mode [...]

Think about this from the point of view of the user, who may well
say something like: "Huh?  I don't know what you're talking about.
What do you mean, backup-mode?  I didn't tell tar to use some special
mode.  I used it with its default options."  It seems to me that it
would be reasonable to ask that extracting the Linux tarball using the
default options should lead to some fairly sane state on the filesystem.

Kyle Moffett wrote:
> For that matter, how do you determine which  
> user it should extract as?  UID 0?

Yes, that is the obvious choice.  It's a good default that will be
right for 99.99% of users.

Kyle Moffett wrote:
> Actually, if you start browsing random software tarballs you'll find  
> that 1 in 5 or so has world-write permissions on at _minimum_ the  
> root directory, more often the whole source tree.

I didn't realize that.  Thanks for checking.  Well, I consider that
unfortunate and poorly chosen.  I guess I'm out of date.

Martin Mares wrote:
> People extracting random archives as root with preserving permissions
> (and owners) are relying on *ALL* archive creators using what they suppose
> are the right permissions, which is at least simple-minded, if not completely
> silly.

I'm not suggesting extracting random archives as root.  But I don't
see a problem with extracting Linux kernel archives as root.  I'm prepared
-- or I was prepared -- to trust the Linux kernel developers not to
deliberately do anything that would harm my system.  After all, if the
Linux kernel developers are malicious, I'm totally screwed; the act of
running their code requires a great deal of trust, and extracting a tarball
as root seems very minor compared to that.

Martin Mares wrote:
> If you want to help such users, you should do so by helping them
> understand they do a wrong thing and not by hiding the problem in a single
> specific case.

You can do both.  You can educate users, *and* provide sensible defaults
in the meantime for those users who don't already know about the risks.

Stefan Richter wrote:
> Correction: Some users who set a wrong umask when creating files by
> extraction from these archives and then attempt to build an own kernel
> from that may screw themselves over.

No, this is not correct.  For non-root users who set their umask to
something silly, I agree that this is their problem, not Linux's problem.
But that's not what I'm talking about.  I'm talking about the case of a
root user who extracts the tar archive with 'tar xzvf'.  That's a very
natural thing to do, and what I'm saying is that unsuspecting users
are likely to get bitten by the presence of 0666 files in the Linux
kernel tarball.  That seems unfortunate.

Keep in mind that there are good reasons to extract the Linux tarball
as root.  There is a long-standing tradition of storing the kernel
source under /usr/src, and usually /usr/src is writeable only by root.
Moreover, I bet that many users are not intimately familiar with tar
and all its obscure options, and consequently are unaware of the need
for --no-same-permissions.  Those users are likely to get bitten by
this pitfall.  I still think it would be a kindness to users to not set
up this trap for them to fall into; to distribute the Linux tarball with
files that are not group- or world-writeable.

It feels to me like there is this attitude towards users that says "if you
don't know all of the esoteric tar options, you deserve what you get".
I don't believe in punishing users for their ignorance.

It's not like it would be a terrible hardship to change all the
0666 permissions to 0644.  There's basically no downside to doing so.
The Linux tarballs used to have 0644-style permissions for years, and I'm
not aware of any users complaining that they wished you would change all
the 0644 permissions to 0666.  Instead, it sounds like that the change to
0666 happened perhaps by accident, maybe without much discussion about
the consequences for users, and now there is inertia and resistance to
changing it back.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-13  1:17               ` David Wagner
  2006-09-13  4:33                 ` Willy Tarreau
  2006-09-13  8:51                 ` Stefan Richter
@ 2006-09-14 23:04                 ` Bill Davidsen
  2 siblings, 0 replies; 23+ messages in thread
From: Bill Davidsen @ 2006-09-14 23:04 UTC (permalink / raw)
  To: David Wagner; +Cc: Kernel Mailing List


 > Chris
David Wagner wrote:
> Rene Scharfe  wrote:
>> [details on how GNU tar works, snipped]
> 
> Again, you miss my point.  I already know how tar works, but that's not
> my point.  Why is it that people are so unwilling to address the real
> issue here?  Let's try a few facts:

Okay:
- you have been told told read the old posts on this topic
- you read but didn't understand
- the problem is YOU ARE DOING IT WRONG and untarring as root

The time to discuss where to put the umask was "back when," and I might 
have agreed then, but now I can't see any justification to change, 
because someone else would then have a problem. You want it to do 
something else on your system, so do it. You shouldn't untar as root anyway.

You have not only beaten a dead horse, but dragged the carcass through 
the streets.
> 
>     (a) The Linux kernel tar archive contains files with world-writeable
>     permissions.
> 
>     (b) There is no need for those files to have world-writeable
>     permissions.  It doesn't serve any particular purpose.  If the
>     permissions in the tar archive were changed to be not world-writeable,
>     no harm would be done.
> 
>     (c) Some users may get screwed over by virtue of the fact that those
>     files are listed in the tar archive with world-writeable permissions.
>     (Sure, if every user was an expert on "tar" and on security, then
>     maybe no one would get screwed over.  But in the real world, that's
>     not the case.)
> 
>     (d) Consequently, the format of the Linux kernel tar archive is
>     exposing some users to unnecessary riskis.
> 
>     (e) The Linux kernel folks could take a quick and easy step that
>     would eliminate this risk.  That step would involve storing the
>     files in the tar archive with permissions that were more reasonable
>     (not world-writeable would be a good start!).  This step wouldn't
>     hurt anyone.  There's no downside.
> 
>     (f) Yet the Linux kernel folks refuse to take this step, and any
>     time someone mentions that there is something the Linux kernel folks
>     could do about the problem, someone tries to change the topic to
>     something else (e.g., complaints about bugs in GNU tar, suggestions
>     that the user should invoke tar with some other option, claims that
>     this question has been addressed before, you name it).
> 
> So why is it that the tar archive is structured this way?  Why are
> the Linux kernel folks unnecessarily exposing their users to risk?
> What purpose, exactly, does it serve to have these files stored with
> world-writeable permissions?
> 
> Folks on the Linux kernel mailing list seem to be reluctant to admit these
> facts forthrightly.  The posts I've seen mostly seem to have little or
> no sympathy for users who get screwed over.  The attitude seems to be:
> if you get screwed over, it's your fault and your problem.  Why is that?
> If there is a simple step that Linux developers can take to eliminate
> this risk, why is there such reluctance to take it, and why is there
> such eagerness to point the finger at someone else?
> 
> The way I see it, storing files in a tar archive with world-writeable
> permissions is senseless.  Why do such a strange thing on purpose?
> 
> It all seems thoroughly mysterious to me.


-- 
Bill Davidsen <davidsen@tmr.com>
   Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: R: Linux kernel source archive vulnerable
  2006-09-14 22:38                               ` David Wagner
@ 2006-09-15  7:28                                 ` Stefan Richter
  0 siblings, 0 replies; 23+ messages in thread
From: Stefan Richter @ 2006-09-15  7:28 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel

David Wagner wrote:
> Keep in mind that there are good reasons to extract the Linux tarball
> as root.  There is a long-standing tradition of storing the kernel
> source under /usr/src, and usually /usr/src is writeable only by root.

This no "good reason" to extract the tarball as root.

(Anyway, the discussion about running tar as root is besides the point.)
-- 
Stefan Richter
-=====-=-==- =--= -====
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2006-09-15  7:30 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20060907182304.GA10686@danisch.de>
     [not found] ` <D432C2F98B6D1B4BAE47F2770FEFD6B612B8B7@to1mbxs02.replynet.prv>
2006-09-11 18:29   ` R: Linux kernel source archive vulnerable Jon Lewis
2006-09-12  5:06     ` Kyle Moffett
2006-09-12  5:27       ` Willy Tarreau
2006-09-12 19:42       ` R: " David Wagner
2006-09-12 20:35         ` linux-os (Dick Johnson)
2006-09-12 21:35           ` David Wagner
2006-09-12 22:56             ` Rene Scharfe
2006-09-13  1:17               ` David Wagner
2006-09-13  4:33                 ` Willy Tarreau
2006-09-13  5:34                   ` David Wagner
2006-09-13  6:17                     ` Kyle Moffett
2006-09-13  6:26                       ` David Wagner
2006-09-13  6:49                         ` Kyle Moffett
2006-09-13  6:59                           ` David Wagner
2006-09-13  8:12                             ` Kyle Moffett
2006-09-14 22:38                               ` David Wagner
2006-09-15  7:28                                 ` Stefan Richter
2006-09-13 10:45                         ` Martin Mares
2006-09-13 11:13                           ` Jan Engelhardt
2006-09-13  6:26                       ` Jan Engelhardt
2006-09-13 19:49                         ` Willy Tarreau
2006-09-13  8:51                 ` Stefan Richter
2006-09-14 23:04                 ` Bill Davidsen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).