lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 12 Sep 2006 01:06:37 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Jon Lewis <jlewis@...ove2reply.lewis.org>
Cc:	Perego Paolo Franco <p.perego@...ly.it>,
	linux-kernel@...r.kernel.org, Hadmut Danisch <hadmut@...isch.de>,
	bugtraq@...urityfocus.com
Subject: Re: R: Linux kernel source archive vulnerable

On Sep 11, 2006, at 14:29:58, Jon Lewis wrote:
> On Fri, 8 Sep 2006, Perego Paolo Franco wrote:
>
>> Anyway just few considerations:
>> 2) a good sysadmin is aware that /usr/src is NOT supposed to be  
>> world writable
>
> For some reason (bug in how they're being checked out of git, I  
> assume), the latest kernel source tar files have all files and  
> directories world writable.  This is not how it's been in the past  
> and is not how it should be.

-ENOBUG

Please see these threads and quit bringing up this topic like crazy:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113304241100330&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=114635639325551&w=2

To quote:
> 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 not to 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.

So if you must cause a senseless hubbub on securityfocus.com, please  
don't spill it over onto LKML.  This sort of thing is at _worst_ a  
bug in GNU tar that it's behavior is different when root.  I run a  
linux system with SELinux where user 0 is no different than any other  
user and has no special permissions at all, and this kind of  
stupidity bites me a lot.  My user 0 is "kyle" when I want to chown  
files I switch to the "sysadm" role, or if I absolutely need to  
override security policy for some reason I jump through hoops to get  
to the "root" role.  In neither of those cases do I care what UID I am.

So either deal insecure permissions when you can't be bothered to use  
GNU tar securely (easy), don't compile your kernel as root (easier)  
or fix GNU tar not to assume UID 0 is God in the first place.

Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ