linux-kernel - Re: Chroot bug

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]

Message-ID: <20070925160214.GP6800@stusta.de>
Date:	Tue, 25 Sep 2007 18:02:14 +0200
From:	Adrian Bunk <bunk@...nel.org>
To:	Miloslav Semler <majkls@...pere.com>
Cc:	serge@...lyn.com, davidsen@....com, philipp@...ek.priv.at,
	7eggert@....de, alan@...rguk.ukuu.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: Chroot bug

On Tue, Sep 25, 2007 at 05:43:58PM +0200, Miloslav Semler wrote:
> Adrian Bunk napsal(a):
>> On Wed, Sep 26, 2007 at 12:40:27AM +0930, David Newall wrote:
>>
>>   
>>> Miloslav Semler pointed out that a root process can chdir("..") out of 
>>> its chroot.  Although this is documented in the man page, it conflicts 
>>> with the essential function, which is to change the root directory of the 
>>> process.  In addition to any creative uses, for example Philipp Marek's 
>>> loading dynamic libraries, it seems clear that the prime purpose of 
>>> chroot is to aid security.  Being able to cd your way out is handy for 
>>> the bad guys, but the good guys don't need it; there are a thousand 
>>> better, safer solutions.
>>> ...
>>>     
>>
>> The bad guys most likely also now other tricks to escape the chroot.
>>
>> If you are root in the chroot you can e.g. mount the partition with the 
>> root filesystem inside the chroot.
>>
>> If a bad guy becomes root inside a chroot it's game over.
>>   
> but why there keep 1000001th. It is same as:
> There is milion ways howto dos your system.. Then we needn't repair bugs...

Either something is aimed at being secure or it's not aimed at being 
secure.

For chroot it's documented that it does not prevent root from escaping 
the chroot so that's expected behavior, not a bug.

And regarding security, there's no difference whether there is 1 way or 
whether there are 1000001 ways for root to escape the chroot.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
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/