Re: Tar extract behaviour changed

[christos%astron.com@localhost (Christos Zoulas)]

In article <20191022052605.GA771%mail.duskware.de@localhost>,
Martin Husemann  <martin%duskware.de@localhost> wrote:
>On Tue, Oct 22, 2019 at 06:37:44AM +0700, Robert Elz wrote:
>>     Date:        Mon, 21 Oct 2019 21:20:25 +0200
>>     From:        Joerg Sonnenberger <joerg%bec.de@localhost>
>>     Message-ID:  <20191021192025.GA33725%bec.de@localhost>
>> 
>>   | That said, I don't really see a point in
>>   | allowing one form of arbitrary file replacement and not another.
>> 
>> If we're thinking of it purely as protection against potentially
>> malicious archives obtained from some random internet site, then
>> nor do I
>
>I am not sure. Clearly / and .. are protecting against malicious archives.
>But in my view a directory entry in the (potential malicious) archive
>overwriting an existing symlink is something where the explicit wish of the
>user running the extraction is not honored.
>
>The attack vector here would be someone modifying my file system
>placing malicious symlinks somewhere and later me running the
>extraction of the archive - which is very different from not trusting
>the archive in the first place.
>

Actually a malicious archive can first create the malicious symlink that
points outside the intended extraction tree and then overwrite the
destination. It is much harder to protect against, because then we would
have to normalize and check all symlinks in the archive (and do what?
allow only the symlink pointing to an empty directory case? -- the whole
thing sounds too complicated)

>The other open question is: given that we only have -P, we need to either:
>
> - make sysinst list all directories in the archive and check them for
>   existing symlinks, then ask the user wether the existing symlink should
>   be kept (and then add -P to the tar command line) or
> - simply use -P always on set extractions (where we already know that no
>   .. or / should exist and we kind of trust the archives anyway)
>
>The current state silently breaks existing valid setups ("valid" of course
>in my view, as I personally ran into one that I created myself).

It is simple enough to add extra flags, but as joerg@ implied, it is more
security theater. It does protect against accidents though (tars created
with / files by).

christos