World writable tarballs

World writable tarballs

[Mark Rosenstand]

Hi,

It seems that at least the content of the 2.6.16 tarball is world
writable if extracted with GNU tar as an privileged user.

Is this on purpose in order to prove some point?

Re: World writable tarballs

[Alistair John Strachan]

On Sunday 30 April 2006 01:18, Mark Rosenstand wrote:
> Hi,
>
> It seems that at least the content of the 2.6.16 tarball is world
> writable if extracted with GNU tar as an privileged user.
>
> Is this on purpose in order to prove some point?

Read this thread:

http://marc.theaimsgroup.com/?l=linux-kernel&m=113304241100330&w=2

There's no need to repeatedly discuss it.

-- 
Cheers,
Alistair.

Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: World writable tarballs

[Joshua Hudson]

On 4/29/06, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Sunday 30 April 2006 01:18, Mark Rosenstand wrote:
> > Hi,
> >
> > It seems that at least the content of the 2.6.16 tarball is world
> > writable if extracted with GNU tar as an privileged user.
> >
> > Is this on purpose in order to prove some point?
>
> Read this thread:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113304241100330&w=2

This REALLY needs fixing. If it weren't so late right now I might have written
a filter that takes a tarball and sanitizes the permissions. I've got
good reasons
for compiling the kernel as root (when in the make, install, reboot, test loop
it's quite a timesaver).

Yes, I'm the guy who keeps trying to log in as root on ftp.kernel.org over ftp
with no password. For some bone-headed reason I keep thinking the default
username for ftp is anonymous, not the user's.

Re: World writable tarballs

[Sam Ravnborg]

On Sat, Apr 29, 2006 at 09:59:22PM -0700, Joshua Hudson wrote:
> I've got good reasons
> for compiling the kernel as root (when in the make, install, reboot, test 
> loop it's quite a timesaver).

Care to explain why it is a timesaver to compile your kernel as root?
Other do something like:
make && sudo make modules_install && sudo make install

Or variants of this. In this way we run only a minimal set as root.

	Sam

Re: World writable tarballs

[Matthew Reppert]

On Sat, 2006-04-29 at 21:59 -0700, Joshua Hudson wrote:
>
> This REALLY needs fixing. If it weren't so late right now I might have written
> a filter that takes a tarball and sanitizes the permissions. I've got
> good reasons
> for compiling the kernel as root (when in the make, install, reboot, test loop
> it's quite a timesaver).

Isn't it just an extra ten seconds to type the 'sudo' in front of 'make
modules_install' and enter your password?  I guess I totally don't get
it.

Matt

Re: World writable tarballs

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On Sat, 29 Apr 2006 21:59:22 PDT, Joshua Hudson said:

(reversing the two parts of your comment..)

> Yes, I'm the guy who keeps trying to log in as root on ftp.kernel.org over ftp
> with no password. For some bone-headed reason I keep thinking the default
> username for ftp is anonymous, not the user's.

So we have *repeated* whoopsies already...

>                                                  I've got good reasons
> for compiling the kernel as root (when in the make, install, reboot, test loop
> it's quite a timesaver).

And that isn't a warning that maybe you're trying to save *too* much time????

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: World writable tarballs

[Heikki Orsila]

On Sun, Apr 30, 2006 at 01:48:12AM +0100, Alistair John Strachan wrote:
> There's no need to repeatedly discuss it.

I think there is. Sorry for wasting bandwidth.

It's a big security hole deliberately caused by the kernel people (files
in the tar ball have og+w, so it's not problem in roots umask or tar).
Real security needs _simplicity_ but current file modes require
unnecessary _tricks_ for admins. There should be nothing against
untarring files as root. In this case it makes sense too, because only
the tar balls are crypto signed, not the individual files inside the tar
ball, so root can conveniently just verify the crypto signature and
untar the file without any race conditions or trusting other users. The
only real alternative is to create an _unnecessary_ trusted user to do
tar ball handling.

PS. this file permission bug almost bit me. People make errors and this
one is potentially a big privilege escalation, because it potentially
turns normal application bugs into root privileges.

-- 
Heikki Orsila                   Barbie's law:
heikki.orsila@iki.fi            "Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: World writable tarballs

[Willy Tarreau]

On Sun, Apr 30, 2006 at 09:15:01AM +0000, Heikki Orsila wrote:
> On Sun, Apr 30, 2006 at 01:48:12AM +0100, Alistair John Strachan wrote:
> > There's no need to repeatedly discuss it.
> 
> I think there is. Sorry for wasting bandwidth.
> 
> It's a big security hole deliberately caused by the kernel people (files
> in the tar ball have og+w, so it's not problem in roots umask or tar).
> Real security needs _simplicity_ but current file modes require
> unnecessary _tricks_ for admins. There should be nothing against
> untarring files as root. In this case it makes sense too, because only
> the tar balls are crypto signed, not the individual files inside the tar
> ball, so root can conveniently just verify the crypto signature and
> untar the file without any race conditions or trusting other users. The
> only real alternative is to create an _unnecessary_ trusted user to do
> tar ball handling.
> 
> PS. this file permission bug almost bit me. People make errors and this
> one is potentially a big privilege escalation, because it potentially
> turns normal application bugs into root privileges.

Although I don't like finding world-writable files in tar archives, I
think you're exagerating a bit. First, you're not turning normal bugs
into root privileges, and second, you don't need to create a user just
for this, you just have to extract it in a directory that other users
cannot access (chmod o-x).

Also, you'll find several other software on the net with full rights,
so if this really is a concern to you, you'd better get used to this
with simple and reliable solutions (ntp comes to mind).

> Heikki Orsila                   Barbie's law:
> heikki.orsila@iki.fi            "Math is hard, let's go shopping!"
> http://www.iki.fi/shd

Regards,
Willy

Re: World writable tarballs

[Alistair John Strachan]

On Sunday 30 April 2006 10:15, Heikki Orsila wrote:
> On Sun, Apr 30, 2006 at 01:48:12AM +0100, Alistair John Strachan wrote:
> > There's no need to repeatedly discuss it.
>
> I think there is. Sorry for wasting bandwidth.
>
> It's a big security hole deliberately caused by the kernel people (files
> in the tar ball have og+w, so it's not problem in roots umask or tar).
> Real security needs _simplicity_ but current file modes require
> unnecessary _tricks_ for admins. There should be nothing against
> untarring files as root. In this case it makes sense too, because only
> the tar balls are crypto signed, not the individual files inside the tar
> ball, so root can conveniently just verify the crypto signature and
> untar the file without any race conditions or trusting other users. The
> only real alternative is to create an _unnecessary_ trusted user to do
> tar ball handling.
>
> PS. this file permission bug almost bit me. People make errors and this
> one is potentially a big privilege escalation, because it potentially
> turns normal application bugs into root privileges.

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

If people are insistent that they must extract and compile things as root, at 
the very least you should have the following in root's ~/.bashrc:

alias tar='tar --no-same-permissions --no-same-owner '

Then if you want the default (imo flawed) tar behaviour, you can just call tar 
directly.

Really, people that complain about security should have a modicum of a clue; 
allowing a tar file that _somebody else_ applied _their_ security policy, to 
define yours, is a deeply flawed concept. umask is there for a reason.

-- 
Cheers,
Alistair.

Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: World writable tarballs

[Mark Rosenstand]

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?

> Really, people that complain about security should have a modicum of a clue; 
> allowing a tar file that _somebody else_ applied _their_ security policy, to 
> define yours, is a deeply flawed concept. umask is there for a reason.

I merely asked if it was on purpose. In my point of view, it's wrong to
deliberately expose people to such big security threads.

That said, the kernel source is actually the only thing I extract as
root, mostly because I think it's weird to have symlinks in /lib/modules
point to my user's home directory.

Re: World writable tarballs

[Alistair John Strachan]

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.

Even if the world writable thing is fixed (obviously I would not be opposed to 
this), I _strongly_ recommend that you add the two flags to tar as a root 
user so that ANY tar you extract will be extracted with 100% guaranteed safe 
permissions..

(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!)

-- 
Cheers,
Alistair.

Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: World writable tarballs

[Joshua Hudson]

> Isn't it just an extra ten seconds to type the 'sudo' in front of 'make
> modules_install' and enter your password?  I guess I totally don't get
> it.
No sudo.
Besides, the next command after make modules_install is mount.

Besides, if it weren't the fact that the tarball has world-writable files, this
would be more secure than compiling as a normal user. Instead of just
hijacking some user account, they now have to do that followed by
somehow getting my root password.

I disallowed password authentication for root over ssh some time ago.

Re: World writable tarballs

[Heikki Orsila]

On Sun, Apr 30, 2006 at 12:49:16PM +0100, Alistair John Strachan wrote:
> Really, people that complain about security should have a modicum of a clue; 
> allowing a tar file that _somebody else_ applied _their_ security policy, to 
> define yours, is a deeply flawed concept. umask is there for a reason.

I think you are missing an important point here. Any person who compiles
a kernel image trusts the providers much more than file modes if one is
to run the kernel too so it's not like file modes are killer of trust
here. You might also argue that "NO_ROOT_HOLE=yes make modules_install"
is required for kernel to install non-world-writable modules.

My umask is just fine, 077. Also, as noted, it does make sense
that tar preserves attributes because admins use it for backuping.

-- 
Heikki Orsila                   Barbie's law:
heikki.orsila@iki.fi            "Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: World writable tarballs

[Mark Rosenstand]

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.