LKML Archive on
help / color / mirror / Atom feed
From: (David Wagner)
Subject: Re: R: Linux kernel source archive vulnerable
Date: Thu, 14 Sep 2006 22:38:06 +0000 (UTC)	[thread overview]
Message-ID: <eeclke$s44$> (raw)
In-Reply-To: <>

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

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.

  reply	other threads:[~2006-09-14 22:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <D432C2F98B6D1B4BAE47F2770FEFD6B612B8B7@to1mbxs02.replynet.prv>
2006-09-11 18:29   ` 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 [this message]
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

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='eeclke$s44$' \ \ \ \
    --subject='Re: R: Linux kernel source archive vulnerable' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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