From: Bill Davidsen <davidsen@tmr.com>
To: David Wagner <daw-usenet@taverner.cs.berkeley.edu>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: R: Linux kernel source archive vulnerable
Date: Thu, 14 Sep 2006 19:04:16 -0400 [thread overview]
Message-ID: <4509DFF0.4040309@tmr.com> (raw)
In-Reply-To: <ee7m7r$6qr$1@taverner.cs.berkeley.edu>
> 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.
prev parent reply other threads:[~2006-09-14 22:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4509DFF0.4040309@tmr.com \
--to=davidsen@tmr.com \
--cc=daw-usenet@taverner.cs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox