Hi,
there's a severe vulnerability in the Linux kernel source code archives:
The Linux kernel is distributed as tar archives in the form of
linux-2.6.17.11.tar.bz2 from kernel.org. It is usually unpacked,
configured and compiled under /usr/src. Since installing a new kernel
requires root privileges, this is usually done as root.
When unpacking such an archive, tar also sets the uid, gid, and file
permissions given in the tar archive. Unfortunately, plenty of files and
directories in that archive are world writable. E.g. in the 2.6.17.11
archive, there are 1201 world writable directories and 19554 world
writable files.
This opens the door for at least three kinds of attacks:
1. Whoever manages to exploit any server (e.g. PHP on a webserver) has
world writable directories at a well defined place, perfect to hide
any malware, bot, rootkit,
2. Any user or intruder can modify the kernel source and thus compromise
the kernel to be compiled.
3. any user or intruder could modify the build or installation
system/Makefiles in order to have any kind of malware executed by
root the next time a kernel is built or installed, or any other
kernel module making use of the kernel tree.
Solution: Ensure that the file ownership and permissions are set
properly before distributing the tar archive.
regards
Hadmut

Fri, Sep 08, 2006 at 12:52:22AM +0530, Raj Mathur wrote:

I wouldn't know if something has changed drastically between 2.6.16
and 2.6.17.11, but:

raju@mail:~$ find /usr/src/linux-2.6.16/ -perm -666 ! -type l
raju@mail:~$

Not a single world-writable file or directory. Perhaps pre-release
kernel tarballs are more lax?

my machine (I also have a 2.6.16):

# find /usr/src/linux-2.6.16/ -perm -666 ! -type l | wc -l
20434

Just to doublecheck I wrote a script which parses the kernel tar:

pax_global_header 52 b mode=666 uid= 0 gid= 0
linux-2.6.17.11/ 0 b mode=777 uid= 0 gid= 0
linux-2.6.17.11/.gitignore 462 b mode=666 uid= 0 gid= 0
linux-2.6.17.11/CPYING 18693 b mode=666 uid= 0 gid= 0
linux-2.6.17.11/CREDITS 89536 b mode=666 uid= 0 gid= 0
linux-2.6.17.11/Documentation/ 0 b mode=777 uid= 0 gid= 0
10581 b mode=666 uid= 0 gid= 0
7249 b mode=666 uid= 0 gid= 0
11655 b mode=666 uid= 0 gid= 0
17843 b mode=666 uid= 0 gid= 0
21291 b mode=666 uid= 0 gid= 0
5332 b mode=666 uid= 0 gid= 0
32801 b mode=666 uid= 0 gid= 0
0 b mode=777 uid= 0 gid= 0
35 b mode=666 uid= 0 gid= 0

A friend of mine confirmed to also have world writable dirs and files.

regards
Hadmut

Hi Roland,

Fri, Sep 08, 2006 at 11:16:35AM +0200, Roland Kuhn wrote:
Hi Hadmut!

This is a FAQ, and a pretty lame one; see e.g. the first google hit
for 'linux kernel tarball permissions':

1. If this is a known issue and it is *still* distributed in this way,
than this is not a lame FAQ, it is a matter of *extreme* ignorance.

Ignoring such a security flaw just because it is a FAQ is not
acceptable.

2. Telling someone to ask Google for this problem is pretty
unlogical: It presumes that the user has already realized the
permissions. In this case, why should the user still ask Google, if it
just takes a chmod to fix the problem?

3. And in what way would asking Google achieve any improvement about
this problem? This is a problem to be fixed at the tar generation
side, not at the unpacking side.

4. The URL you gave it absolutely pointless. It just says that the
permissions are they way they are. Your URL is exactly that kind of
useless answer that does not contain any information not already
contained in the question. That way of science-by-google.

5. This is not about how to use tar. This is about security. Security
is about closing security holes, not leaving them widely open
because one could ask Google about how to circumvent them if you
realized them.

6. It is unlogical to untar a source with a uid other than root if you
need to compile, install, and run the program under root anyway.
the contrary: root's sources should be handled by root only and not
by any other uid.

regards
Hadmut

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Fri, Sep 08, 2006 at 11:44:02AM +0100, Lee Ball wrote:

Sorry to add my 2 pence worth but I noticed that Raj ran his command as
a normal user and you Hadmut have ran yours as root. Isn't it going to
be ok as the directories above these world writeable files aren't
writeable/readable by a non-superuser?

Actually it wasn't my own computer where I found the problem. I was
performing some security checks on a customer machine and found these
open directories, so it was someone else's machine.

No, this is not correct. Even if /usr/src is not world writable, you
can write into those subdirectories and files.

Just think about it: you could not write any file into your
home directory since /home is not world writable.

regards
Hadmut

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Hadmut Danisch wrote:
Fri, Sep 08, 2006 at 12:52:22AM +0530, Raj Mathur wrote:
>I wouldn't know if something has changed drastically between 2.6.16
>and 2.6.17.11, but:
>>
>raju@mail:~$ find /usr/src/linux-2.6.16/ -perm -666 ! -type l
>raju@mail:~$
>>
>Not a single world-writable file or directory. Perhaps pre-release
>kernel tarballs are more lax?

my machine (I also have a 2.6.16):

# find /usr/src/linux-2.6.16/ -perm -666 ! -type l | wc -l
20434

Just to doublecheck I wrote a script which parses the kernel tar:

pax_global_header 52 b mode=666 uid= 0 gid= 0
linux-2.6.17.11/ 0 b mode=777 uid= 0 gid= 0
linux-2.6.17.11/.gitignore 462 b mode=666 uid= 0 gid= 0
linux-2.6.17.11/CPYING 18693 b mode=666 uid= 0 gid= 0
linux-2.6.17.11/CREDITS 89536 b mode=666 uid= 0 gid= 0
linux-2.6.17.11/Documentation/ 0 b mode=777 uid= 0 gid= 0
10581 b mode=666 uid= 0 gid= 0
7249 b mode=666 uid= 0 gid= 0
11655 b mode=666 uid= 0 gid= 0
17843 b mode=666 uid= 0 gid= 0
21291 b mode=666 uid= 0 gid= 0
5332 b mode=666 uid= 0 gid= 0
32801 b mode=666 uid= 0 gid= 0
0 b mode=777 uid= 0 gid= 0
35 b mode=666 uid= 0 gid= 0

A friend of mine confirmed to also have world writable dirs and files.

regards
Hadmut

Sorry to add my 2 pence worth but I noticed that Raj ran his command as
a normal user and you Hadmut have ran yours as root. Isn't it going to
be ok as the directories above these world writeable files aren't
writeable/readable by a non-superuser?

Cheers

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Fri, Sep 08, 2006 at 10:55:32AM -0500, Gerald (Jerry) Carter wrote:

It is my understanding that the permissions are
intentionally set that way.

yup, it's not accidently, it set intentionally.

But intention does not imply security.

This hash been discussed several times over the
past year.

Which proves that this is a common problem and not a personal problem
of mine. The more it has been discussed, the less I can understand why
it hadn't been fixed.

Yeah, meanwhile I've read several discussions about this easy. What I
learned so far:
- There are plenty of people with security concerns about this.
- There are plenty of other people ignoring these concerns.
- There is not a single good reason to deliver archive files with
world writable permissions. Until now I just found that it is made
intentionally, but no good reason.

The standard recommendation is to never compile
the kernel as root.

So how would you do

make install
make modules_install

then? This recommendation works only for generating kernel packages,
but not for local installation.

If this was a standard recommendation, why has the Makefile the
install and modules_install clause at all?

And if this is a standard recommendation, it is not sufficiently
published. If it were, the Makefile itself would tell you

"Don't call me as root"

But the Makefile doesn't.

regards
Hadmut

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Thu, Sep 07, 2006 at 05:04:39PM -0400, Troy Cregger wrote:

kernel-2.6.17-gentoo-r7 seems K.

$ find / -perm -666 ! -type l | wc -l
0
$

The debian kernel is K as well.

It's just the upstream kernel which has this flaw.

But this shows that gentoo and debian don't follow the alleged need
for these permissions either.

Ironically, if Microsoft distributed such files everyone would shout
"hidden backdoor!"

regards
Hadmut

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

PGP SIGNED MESSAGE
Hash: SHA1

Hadmut Danisch wrote:
Hi,

there's a severe vulnerability in the Linux kernel
source code archives:

It is my understanding that the permissions are
intentionally set that way.

This hash been discussed several times over the
past year.

The Linux kernel is distributed as tar archives
in the form of linux-2.6.17.11.tar.bz2 from kernel.org.
It is usually unpacked, configured and compiled
under /usr/src. Since installing a new kernel
requires root privileges, this is usually done as root.

The standard recommendation is to never compile
the kernel as root.

cheers, jerry

Samba http://www.samba.org
Centeris http://www.centeris.com
"What man is a man who does not make the world better?"
PGP SIGNATURE
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

vEnpAsN1S4DWQflVvM6Jcqs=
=okZq
PGP SIGNATURE

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

PGP SIGNED MESSAGE
Hash: SHA1

Hadmut Danisch wrote:

Fri, Sep 08, 2006 at 10:55:32AM -0500, Gerald (Jerry) Carter wrote:
>It is my understanding that the permissions are
>intentionally set that way.

yup, it's not accidentally, it set intentionally.
But intention does not imply security.

I'm not necessarily disagreeing with you.

My point was that reporting it here will probably
not get any policy changed. And your original
message did not acknowledge past discussions from
what I could tell.

If you are trying to excerpt community pressure to
get the policy changed, then it would have been
better to make that motivation more apparent.

>The standard recommendation is to never compile
>the kernel as root.

So how would you do

make install
make modules_install

Building and install are separate operations. If
you unpack the kernel as non-root, then the versions
of tar I've tested do not preserve the original
permissions but rather apply the current umask.
You can su to root when you are ready to install.

It's the same reason sing that people advise not
running rpmbuild as root (although many people
continue to do so).

cheers, jerry

Samba http://www.samba.org
Centeris http://www.centeris.com
"What man is a man who does not make the world better?"
PGP SIGNATURE
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iSWcrjVC+TgiV6ew9a/eyq0=
=n3nY
PGP SIGNATURE

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Hi Jerry,

Fri, Sep 08, 2006 at 12:06:41PM -0500, Gerald (Jerry) Carter wrote:

So how would you do

make install
make modules_install

Building and install are separate operations.

Really? Both means to do what is standing in the Makefile.
Both is executing the Makefile.

Installation is, btw, more intrusive since it is not limited to the
source directory. So in my eyes there is no point in compiling as
non-root when you install as root then.

The basic problem is that the wrong tool is used. It may sound
strange, but tar is simply the wrong tool: They want to distribute
source files without any assigned file permissions, but use a tape
archive tool which inherently carries uid, gid and permissions with
it. To circumvent the use of the wrong tool, they are using world
writable permissions.

It may sound funny to consider tar as the wrong tool, but it is.

If
you unpack the kernel as non-root, then the versions
of tar I've tested do not preserve the original
permissions but rather apply the current umask.

This makes it even worse. Because if other versions of tar do not show
this behavior (and I learned tar about 20 years ago on Unix) people do
not necessarily expect this behavior and do not have any reason to ask
google about how to use tar.

If you cannot trust the kernel source to compile it as root, how could
you run it with root permissions (i.e. use it as a kernel)?

regards
Hadmut

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

PGP SIGNED MESSAGE
Hash: SHA1

Hadmut Danisch wrote:

Really? Both means to do what is standing in
the Makefile. Both is executing the Makefile.

That's like saying ping should run as root
since it reads /etc/hosts.

If you cannot trust the kernel source to compile
it as root, how could you run it with root permissions
(i.e. use it as a kernel)?

Your logic is false here. If the kernel maintainers
and developers say don't compile as root and you
do it anyways, That's your choice. But it is not the
same thing as running the kernel. You may disagree but
deliberately choosing not to follow the advice of
the maintainer of a software package does not logically
follow from your statement above.

But again, this is a philosophical issue and now a
technical one. Like I said before, if you want to change
policy, take it up on lkml. Discussing it here will
provide little if any benefit in changing how kernels
are distributed from kernel.org.

Now if you want to talk about Samba :-)

cheers, jerry

Samba http://www.samba.org
Centeris http://www.centeris.com
"What man is a man who does not make the world better?"
PGP SIGNATURE
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

2N1GtBaNNHlM5c+05rXc/ZU=
=zlWk
PGP SIGNATURE

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Don't. Untar. Archives. As. Root.

It's that simple.

are you also going to complain about the fact that there are tar
versions out there that don't strip a leading / from the archive?
Much fun can be had when you carelessly extract as root, then.

Hello,

Sorry to change the subject slightly here on this thread, but I was
wondering about this before the topic came up.

Given the problems with using the tar format for file distribution, are
there any other simple, non-compressed file-grouping formats out there
that weren't originally designed for backups (e.g. don't contain
usernames, permissions, etc)? Something that can be a drop-in
replacement for tar and thus can integrate with gzip/bzip2 easily?
(Don't even say .zip)

There's probably one out there I'm completely naive about, but I haven't
seen one yet that would be a safer alternative.

thanks,
tim

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

9/8/06, Hadmut Danisch <hadmut (AT) danisch (DOT) dewrote:
Ironically, if Microsoft distributed such files everyone would shout
"hidden backdoor!"

That's a fact, but don't forget that the upstream kernel is not being
shipped as part of an update to a commercial product. Besides,
permissions are not hidden backdoor. A backdoor by definition is a
mean to access a program, here we are talking sources.

And i'll second the man who said that you should not compile a kernel
on a live system, it should be as stripped as possible.

this happy note, it's week end time :)
Steph

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Fri, Sep 08, 2006 at 01:38:00PM -0500, Gerald (Jerry) Carter wrote:

Your logic is false here. If the kernel maintainers
and developers say don't compile as root and you
do it anyways, That's your choice.

Your assumption is false here. The kernel maintainers D NT say this:
Read the README file, it does not contain any statement that you do
not have to compile as root. They silently explain how to compile if
you are not root, but they don't tell not to be root.

But it is not the
same thing as running the kernel. You may disagree but
deliberately choosing not to follow the advice of
the maintainer of a software package does not logically
follow from your statement above.

Again: There is no such advice. The README just says

"To do the actual install you have to be root, but none of the normal
build should require that. "

So you don't need to be root in order to compile. But this is not an
advice to not be root.

And the README says:

bzip2 -dc linux-2.6.XX.tar.bz2 | tar xvf -
There is not even the option mentioned.

Now if you want to talk about Samba :-)

Did not have any significant problem with samba so far

regards
Hadmut

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Fri, 08 Sep 2006 23:37:31 +0200, Hadmut Danisch said:
Again: There is no such advice. The README just says

"To do the actual install you have to be root, but none of the normal
build should require that. "

So you don't need to be root in order to compile. But this is not an
advice to not be root.

If you can't put together "none of the normal build should require it" and
the standard advice of "don't run anything as root unless it requires it"
(you *are* aware that's standard advice, right?) to get "therefor, don't
build it as root, since root isn't required", you probably shouldn't be
doing *anything* as root.

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/
PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

McHtoUwCzu44sodl6iqiZsI=
=ZSiw
PGP SIGNATURE

What problems ?

1. tar archives contain information about the user and group of a file.
This is critical for backups, but quite unnecessary for software
distribution in the vast majority of cases. It is a common pitfall
for software authors to leak information about their systems this
way.

2. As discussed in this thread, tar archives contain permissions for
files. Also important for backups, not important for software
distribution IMH

3. tar traditionally allows files to be extracted to any directory,
which can be dangerous.

True, these behaviors can be overridden, or a tool developed that has
safe defaults, but then the tool would be less useful for backups. The
point is, the Unix community has been using a backup tool for software
distribution for many years. Perhaps having the right tool for the job
would be safer.

For instance, a format that only contained filenames and timestamps, and
is built to only output all files under a specific directory tree would
be nice.

I would say cpio, but you don't want any backup designed archivers.

Yeah, I had thought of that as well, but it likely has the same issues.

thanks,
tim

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

What tar are you using? With every tarball I download the files within are
given the owner:group of the user I extract them as.

I have never seen a developer's username or group disclosed

Yes, as a normal user, you can't create files locally owned by another
user, so they aren't, but the username/group are indeed in the tar file.
>From a couple of tarballs I have lying around my system:

me@localhost:/usr/local/srctar tjvf nmap-3.50.tar.bz2
drwxr-xr-x fyodor/fyodor 0 2004-01-18 22:04 nmap-3.50/
-rw-r fyodor/fyodor 15318 2003-09-10 22:12 nmap-3.50/main.cc
-rw-r fyodor/fyodor 75134 2003-12-01 20:09 nmap-3.50/nmap.cc
-rw-r fyodor/fyodor 50952 2003-09-16 02:04 nmap-3.50/targets.cc
-rw-r fyodor/fyodor 67425 2003-09-20 05:03 nmap-3.50/tcpip.cc
-rw-r fyodor/fyodor 7490 2003-09-10 22:12 nmap-3.50/nmap_error.cc
-rw-r fyodor/fyodor 22068 2003-09-10 22:12 nmap-3.50/utils.cc
-rw-r fyodor/fyodor 41675 2003-09-10 22:12 nmap-3.50/idle_scan.cc
-rw-r fyodor/fyodor 68759 2003-09-10 22:12 nmap-3.50/osscan.cc
-rw-r fyodor/fyodor 46270 2003-12-18 16:42 nmap-3.50/output.cc
-rw-r fyodor/fyodor 71462 2003-12-01 20:09 nmap-3.50/scan_engine.cc

and

me@localhost:/usr/local/srctar tzvf wget-1.9.1.tar.gz
drwxr-xr-x hniksic/hniksic 0 2003-11-11 18:42 wget-1.9.1/
drwxr-xr-x hniksic/hniksic 0 2003-11-11 18:42 wget-1.9.1/doc/
drwxr-xr-x hniksic/hniksic 0 2003-11-11 18:42
-rw-r hniksic/hniksic 12928 2001-01-06 04:26
-rw-r hniksic/hniksic 23252 2003-11-08 18:46 wget-1.9.1/doc/ChangeLog
-rw-r hniksic/hniksic 4854 2003-10-23 18:53 wget-1.9.1/doc/Makefile.in
-rw-r hniksic/hniksic 1529 2003-10-04 06:34 wget-1.9.1/doc/ansi2knr.1
-rw-r hniksic/hniksic 4022 2001-11-30 02:32 wget-1.9.1/doc/sample.wgetrc

Sure they are important. Would you want to manually chmod +x all executables
and scripts? Manually chmod +r all documentation? Even stipulating that we
could use the umask value to decide permissions it is still a PITA.

Using umask is perfectly fine, except in the case of executables, so
that is a good point.

This can be mitigated if you don't blindly extract tarballs as root, and you
only extract in safe locations. If you unpack stuff to '/' you deserve to
hose your system.

Well, personally, I think it's just a joke that I can't extract the
contents of an archive as root and feel safe. I mean, think about it
for a second It's not like I'm downloading a random executable and
running it without some trust. Sure, you shouldn't run programs
unnecessarily as root. That goes for any program, but that's a
precaution that's supposed to prevent unforseen vulnerabilities, and
shouldn't be needed to work around braindead default behavior. It's
like saying: never open emails from people you don't know. Yeah, it
might be a good idea, but it's a total failure of the software involved
to rely on that recommendation for security.

Now, beyond the root user issue, isn't it true that if I untar a
malicious archive as a normal user, that my own files could be squashed
too? If I always unpack source files in ~/src as a normal user, and
compile them in their own subdirectories as my own user, I could still
be at risk if I'm not careful. Suppose one day, I unpack foo-0.1.tar.gz
to the directory ~/src/foo-0.1. Then, the next day I download
bar-0.1.tar.gz, which I don't really trust. I just want to unpack it
and take a look at the source before I compile and install. So, I untar
it in ~/src. Let's suppose bar-0.1.tar.gz contains the following files:

bar-0.1/
foo-0.1/evil.c
bar-0.1/benign.c

So, this could inject evil code into my other program. If I were naive
enough to extract an archive in my home directory, my .profile could
receive a lovely shellcode.

True, some boneheads don't package their stuff in a top-level directory
potentially overwriting existing files in the pwd. Perhaps the GNU folks
should add a 'noclobber' option

Yes, I guess what I just described is what you were getting at.
noclobber would be great and all, except not all archive extractors
would behave this way, and if noclobber isn't the default, it will leave
new users vulnerable.

I just think it would be better to have a format that makes it easy to
enforce a top level directory for all files, and removes the leaks
mentioned above. I've searched around since my first posting, and I've
yet to find one, unfortunately.

cheers,
tim

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Fri, 8 Sep 2006, Raj Mathur wrote:

PGP SIGNED MESSAGE
Hash: SHA1

"Hadmut" == Hadmut Danisch <hadmut (AT) danisch (DOT) dewrites:

Hadmut[snip]

HadmutWhen unpacking such an archive, tar also sets the uid,
Hadmutgid, and file permissions given in the tar
Hadmutarchive. Unfortunately, plenty of files and directories in
Hadmutthat archive are world writable. E.g. in the 2.6.17.11
Hadmutarchive, there are 1201 world writable directories and
Hadmut19554 world writable files.

I wouldn't know if something has changed drastically between 2.6.16
and 2.6.17.11, but:

raju@mail:~$ find /usr/src/linux-2.6.16/ -perm -666 ! -type l
raju@mail:~$

Not a single world-writable file or directory. Perhaps pre-release
kernel tarballs are more lax?

Seems to. I just checked linux-2.6.13 and linux-2.6.17.6. While the
first has no world writeable files or directories at all the latter
has tons of it. Interesting.

Cheers,

Chris Kronberg.

PGP SIGNED MESSAGE
Hash: SHA1

Hadmut Danisch wrote:
Hi,

there's a severe vulnerability in the Linux kernel
source code archives:

It is my understanding that the permissions are
intentionally set that way.

This hash been discussed several times over the
past year.

The Linux kernel is distributed as tar archives
in the form of linux-2.6.17.11.tar.bz2 from kernel.org.
It is usually unpacked, configured and compiled
under /usr/src. Since installing a new kernel
requires root privileges, this is usually done as root.

The standard recommendation is to never compile
the kernel as root.

cheers, jerry

Samba http://www.samba.org
Centeris http://www.centeris.com
"What man is a man who does not make the world better?"
PGP SIGNATURE
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

vEnpAsN1S4DWQflVvM6Jcqs=
=okZq
PGP SIGNATURE

9/8/06, Gerald (Jerry) Carter <jerry (AT) samba (DOT) orgwrote:
PGP SIGNED MESSAGE
Hash: SHA1

Hadmut Danisch wrote:
Hi,

there's a severe vulnerability in the Linux kernel
source code archives:

It is my understanding that the permissions are
intentionally set that way.

This hash been discussed several times over the
past year.

--

I skimmed them and it doesn't look like anyone has come up with a
reasonable explanation.

The Linux kernel is distributed as tar archives
in the form of linux-2.6.17.11.tar.bz2 from kernel.org.
It is usually unpacked, configured and compiled
under /usr/src. Since installing a new kernel
requires root privileges, this is usually done as root.

The standard recommendation is to never compile
the kernel as root.
--

Which obviously doesn't help you when a non-root user edits the
kernel, you compile it as 'jerry' but still have to install it as
'root'. You're still hosed.

Is this an artifact of using git? There certainly is N reason for any
kernel files to be world writable.

cp

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

coderpunk writes:

>The standard recommendation is to never compile
>the kernel as root.
>
>

Which obviously doesn't help you when a non-root user edits the
kernel, you compile it as 'jerry' but still have to install it as
'root'. You're still hosed.

Geez, of course not. Unpacking the kernel as non-root honors umask.
Problem solved.
It would help to 'info tar' before posting

-Joe

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

9/11/06, Joe Feise <jfeise (AT) feise (DOT) comwrote:
coderpunk writes:
>
>The standard recommendation is to never compile
>the kernel as root.
>>
>>
>
Which obviously doesn't help you when a non-root user edits the
kernel, you compile it as 'jerry' but still have to install it as
'root'. You're still hosed.

Geez, of course not. Unpacking the kernel as non-root honors umask.
Problem solved.
It would help to 'info tar' before posting

That assumes a proper umask. The kernel source should not depend on
the end user's umask being setup properly.

I'm having a hard time understanding why so many people seem to be
resistant to setting proper permissions in the kernel tree source.
This is the single most important piece of source on a system, it
should be as secure as possible before being released.

Yes, you can mitigate those risks by doing things as non-root (not
everyone does), you can assume a proper umask (not everyone's is), or
you can just fix the permissons at the source and the problem goes
away.

cp

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/