Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Tar extract behaviour changed



On Thu, Oct 24, 2019 at 06:56:57AM +0700, Robert Elz wrote:
>     Date:        Wed, 23 Oct 2019 23:30:47 +0200
>     From:        Joerg Sonnenberger <joerg%bec.de@localhost>
>     Message-ID:  <20191023213047.GA73056%bec.de@localhost>
> 
>   | (1) Abuse of symlinks to shuffle the tree somewhere else. IMO whoever
>   | wants to do that should be using null mounts and deal with it
>   | appropiately in sysinst or whatever on their own.
> 
> With that attitude we may as well simply delete symlink support from
> NetBSD and use only null mounts everywhere.   That's not workable at all.

Deal with this properly in sysinst would mean:

1) run a script like:
 rm -f /tmp/list
 for s in *.${suffix}
 do
   for dir in $( tar tvf "$s" | egrep '^d' | awk '{ print $9}' )
   do
     readlink "$dir" && echo "$dir" >> /tmp/list
   done
 done

2) if /tmp/list is not empty, create a message showing its contents
 and ask the user something like:

    The following directories are symbolic links and will be replaced
    with plain directories:

        $(cat /tmp/list)

    Do you want to

      a) proceed and replace the symbolic links?
      b) trust the $s archive and extract without symlink checks?
      x) abort installation and fix the local setup (e.g. via null mounts)

Option (b) then would add -P to the tar extraction flags.

This will not change anything for nearly all users, but be a pretty strange
experience for the few where it hits.

> ps: if the end solution is to simply use -P in sysinst during extraction,
> then we really also need to be generating signed sets, and have sysinst
> verify the dignatures before extracting.

I'd rather go this very hackish way and always add -P.

If you install sets via sysinst and do not trust the archive, you are doing
something wrong. A strange symlink attack would be no worse than a
bogus usr/bin/su or even bin/sh.

Having sysinst verify the SHA512 checksums that we provide with the sets
would be easy at least on some install media (and for fast-enough 
architectures could even be done by default). Verifying the signatures
on the check sums could only happen for real releases and would require
a bit of infrastructure (probably close to what we would need to set up
for signed binary pkgs anyway).

Martin


Home | Main Index | Thread Index | Old Index