The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Mark Rosenstand <mark@borkware.net>
To: Alistair John Strachan <s0348365@sms.ed.ac.uk>
Cc: Heikki Orsila <shd@zakalwe.fi>, linux-kernel@vger.kernel.org
Subject: Re: World writable tarballs
Date: Sun, 30 Apr 2006 19:08:15 +0200	[thread overview]
Message-ID: <1146416895.15178.24.camel@hammer> (raw)
In-Reply-To: <200604301351.55136.s0348365@sms.ed.ac.uk>

On Sun, 2006-04-30 at 13:51 +0100, Alistair John Strachan wrote:
> On Sunday 30 April 2006 13:36, Mark Rosenstand wrote:
> > On Sun, 2006-04-30 at 12:49 +0100, Alistair John Strachan wrote:
> > > 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.
> >
> > Yes, GNU tar is acting insane. Given that GNU tar is the most widely
> > used tar implementation (at least for extracting linux sources), why is
> > the kernel packaged to exploit this insane behaviour?
> 
> I think you're missing the point. The tar archive can have whatever the hell 
> permissions it likes; you as the user of tar and risking extraction as root 
> should know what tar does and (if you care) take action to negate it.
> 
> Even back before the kernel tar files made every file writable by all, there 
> were always a few files that were marked executable (!!) by all. Bottom line: 
> you can't rely on the permissions in the tar files.

I think you are missing the point. The point is that the kernel source
gets extracted with world writable permissions, without any reason.

I am fully aware that you cannot trust the permissions of extracted tar
archives with GNU tar unless you explicitly add an unreasonably long
argument, whereas other tar implementations require you to use the p
flag.

The question is: Is it right to exploit this misbehaviour?

> (You probably aren't aware of the recent bug found in the kernel build system 
> where, if compilation was executed as root, it would overwrite the /dev/null 
> node with a regular file -- now THAT'S a security problem!)

Yes, that is indeed a good argument for not building as root. But please
try to stay on the fucking subject or be quiet.


  reply	other threads:[~2006-04-30 17:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-30  0:18 World writable tarballs Mark Rosenstand
2006-04-30  0:48 ` Alistair John Strachan
2006-04-30  4:59   ` Joshua Hudson
2006-04-30  6:18     ` Sam Ravnborg
2006-04-30  6:47     ` Matthew Reppert
2006-04-30 16:32       ` Joshua Hudson
2006-04-30  6:53     ` Valdis.Kletnieks
2006-04-30  9:15   ` Heikki Orsila
2006-04-30  9:37     ` Willy Tarreau
2006-04-30 11:49     ` Alistair John Strachan
2006-04-30 12:36       ` Mark Rosenstand
2006-04-30 12:51         ` Alistair John Strachan
2006-04-30 17:08           ` Mark Rosenstand [this message]
2006-04-30 16:53       ` Heikki Orsila

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=1146416895.15178.24.camel@hammer \
    --to=mark@borkware.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=s0348365@sms.ed.ac.uk \
    --cc=shd@zakalwe.fi \
    /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