Gdebi and warn users about 3rd packages

Development Tools & Packages
#1

From security point of view, install 3rd party’s apps could be dangerous

A common way to distribute malware is to take an app and insert harmful code into it, and then redistribute the infected app. So an app that isn’t registered by an unidentified developer might contain harmful code.

URL: https://support.apple.com/en-il/guide/mac-help/mh40616/mac
As far as i know, gdebi doesn’t show warns about 3rd parties problem

I personal agree with this. And beside the hardening, i think warn users from install 3rd party packages is a good idea to notice about unstrusted packages. Here is some test code that could work for this idea

image

From the idea we can do some better check to verify the package and get better result.

1 Like
#2

Interesting.

xpost thoughts from #offtopic TG room

for this to work we would need something amounting to a whitelist or blacklist of packages that were flagged as trusted or not trusted.

To compile a whitelist we would simply need to have a filter for parsing wanted apt output that flags packages as trusted or untrusted.

The blacklist is harder, as we would need to have some kind of audit for the code itself, and/or a method of compiling a list of user flagged packages that are unsavory. In turn, this would give nefarious types (you know who you are) the knowledge that we are on to them, and prompt them to modify script in kind.

I will do some digging, see if I can’t find someone that has put work into this, and if that is not the case, simply parse output to flag 3rd party scripts that are being installed. How this can be used woudl still be up to the end user, unless we are looking to integrate it into parrot-upgrade.

#3

We have many cases of regular packages:

  1. Reinstall (same version)
  2. Downgrade
  3. Upgrade
  4. Install from deb file (no preinstalled package).
    Each cases has 2 different cases:
    A. Trusted package
    B. Unstrusted (custom build, download from internet, modified to add malware, …)
    The point is we try to detect all cases
#4

We would need an automated test harness that can “sign” valid packages if we want to build our own whitelist for Parrot. It can be that simple.

How it might work is that we have some kind of automated crawler that walks repositories, finds packages that are “good” applies a label to them, and BAM we have our whitelist. Then put a flag in the install command that warns when someone is trying to do something outside this list makes the attempt. This additionally allows us to flag users that are outside the ParrotOS “walled garden” so to speak, and modify our upgrade script to boot.

But the problem we will likely run into is that ParrotOS users are notoriously privacy minded, and we would be asking them to collect usage statistics (even if only Boolean and anonymous) and then use that information for whitelisting or blacklisting or both.

There are examples of this done “well” with regards to OSX and how apple “wrapps” the package installer in it’s own verification system. Of course there are ways around this (built into the OS) but it is still there by default.

#5

Debian has GPG key for verifying packages. GPG error when key is expired is a good example of how it works with APT. So if we go this way, our job is somehow sign the GPG key of packages (key should be from Debian or Parrot). The other way is check hash from list of index file which is very limited: What if the .deb file is different version. We don’t know if it is a valid new version or just patched .deb file with malware and different version.
About the OSX, if i’m not wrong, the method is similar APT on Debian: devs push their packages to store, Apples verifies then provide trusted signature.

#6

Yeah right!!!

image