What precautions should I take with .debs I find on the internet?

Question

So I was browsing the web the other day, and I came across a few places that wanted me to download .deb files - and since those are installed by root (and as such have the "powers" and capabilities of root), I wasn't sure about that.

Answer 1

Things to consider:

• How well known is the site? For example, was it a random blog covered in ads, was it a random user on some forum, or was it a well known, respected site?

• What does it claim to install? For example, does it claim to install a kernel or a iconset, but is it only 1MB big?

• How "important" is it that you have the contents of this .deb?

Ways to test things securely:

I use arkose (its in the standard repos ) sandboxing with my debs (and other things) - use it something like this:

sudo arkose -n -c "cd $PWD; $SHELL"

What that does it give me a "sandbox" (otherwise known as "YAY I CAN SCREW UP!") with copy-on-write access to everything on my computer, including my home directory - so if the nasty nasty .deb does sudo rm -rf /*, I DON'T LOSE ANY DATA!

Another thing that isn't stressed enough is MAKE BACKUPS. Those are extremely helpful, and we have many questions on the topic.

In short, just make sure you think about it, and don't just download a random deb and install it.

Answer 2

If you are downloading a package from untrusted or questionable sources, be paranoid. On popular forums like ubuntuforums.org, if a user makes his first post containing only of a short text like "install this, works for me!", followed by a link, be careful with that link and/ or instructions.

Don't use binary packages if possible, especially from untrusted sources. Get the source (for official Ubuntu packages, this can be done with apt-get source package-name) and have a look at it.

If the package in question is small, it may be worth analysing it. I prefer to use the terminal for that because I then have fast access to other powerful command-line tools like ls, find, file, less, vim, grep, sed, dpkg and lots others. Make use of tab-completion (i.e. hitting Tab to complete commands and filenames), it really saves time!

To download a .deb file, you can use the browser, but copying the link and then use wget is faster since you can already experiment with it.

$ mkdir /tmp/foo && cd /tmp/foo
$ wget http://nl.archive.ubuntu.com/ubuntu/pool/main/n/nvidia-common/nvidia-common_0.2.35_amd64.deb

Next, it's time to check the file itself. less (through lesspipe) can provide a quick overview of the file contents. Arrow keys, page up/down, home/end can be useful for navigating, Q quits the program.

$ less nvidia-common_0.2.35_amd64.deb
nvidia-common_0.2.35_amd64.deb:
 new debian package, version 2.0.
 size 10802 bytes: control archive= 1877 bytes.
     197 bytes,    11 lines   *  config               #!/bin/sh
     703 bytes,    16 lines      control              
     741 bytes,    10 lines      md5sums              
     163 bytes,     9 lines   *  postinst             #!/bin/sh
     206 bytes,     8 lines   *  postrm               #!/bin/sh
     827 bytes,    38 lines   *  preinst              #!/bin/sh
     263 bytes,    14 lines   *  prerm                #!/bin/sh
     365 bytes,    12 lines      templates            
 Package: nvidia-common
 Version: 1:0.2.35
 Architecture: amd64
 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
 Installed-Size: 156
 Pre-Depends: dpkg (>= 1.15.7.2)
 Depends: python2.7 | python2.6, python (>= 2.7.1-0ubuntu2), python (<< 2.8), debconf (>= 0.5.00) | debconf-2.0, pciutils, python-apt
 Conflicts: nvidia-180-modaliases, nvidia-185-modaliases, nvidia-current-modaliases
 Replaces: nvidia-180-modaliases, nvidia-185-modaliases, nvidia-current-modaliases
 Section: admin
 Priority: optional
 Description: Find obsolete NVIDIA drivers
  This package will find obsolete NVIDIA drivers in use,
  detect the hardware and recommend the most appropriate
  driver.
 Python-Version: 2.6, 2.7

*** Contents:
drwxr-xr-x root/root         0 2011-09-07 11:06 ./
drwxr-xr-x root/root         0 2011-09-07 11:06 ./usr/
drwxr-xr-x root/root         0 2011-09-07 11:06 ./usr/share/
drwxr-xr-x root/root         0 2011-09-07 11:06 ./usr/share/doc/
drwxr-xr-x root/root         0 2011-09-07 11:06 ./usr/share/doc/nvidia-common/
-rw-r--r-- root/root      1174 2011-09-07 11:07 ./usr/share/doc/nvidia-common/changelog.gz
-rw-r--r-- root/root       466 2011-06-24 14:45 ./usr/share/doc/nvidia-common/copyright
...

After this, you get an overview of the package dependencies and what kind of files it possibly contains. Time to extract the files and analyse the contents using dpkg-deb. The first command extracts the file tree in a newly created directory fs, the second one extracts it to DEBIAN because no other target is specified:

$ dpkg-deb -x nvidia-common_0.2.35_amd64.deb fs
$ dpkg-deb -e nvidia-common_0.2.35_amd64.deb

We'll use less again to analyze the contents of the maintainer scripts (i.e. the files that will be used/ run during installation (and removal). prerm, preinst, postrm, postinst are scripts run before/after removal/installation which are the most important files to analyse. Use :n and :p to switch between the files. By pressing =, you get the current file name and line number as well as the number of files that are in the list.

$ less DEBIAN/*

If the package scripts look sane, it's time to analyse the installed contents (use tab-completion). For shell scripts and interpreted scripts (like Python), analysis is easier (assuming that you're known with the language).

$ less fs/usr/bin/nvidia-detector    # fs<TAB><TAB>/usr/ <TAB><TAB>bin ...
$ less fs/usr/lib/nvidia/pre-install
$ ls -la fs/usr/lib     # quickly check the directory contents, my memory is weak
drwxr-xr-x 5 peter peter 100 2011-09-07 11:06 .
drwxr-xr-x 5 peter peter 100 2011-09-07 11:06 ..
drwxr-xr-x 2 peter peter  60 2011-09-07 11:06 nvidia
drwxr-xr-x 3 peter peter  60 2011-09-07 11:06 python2.6
drwxr-xr-x 3 peter peter  60 2011-09-07 11:06 python2.7
$ # I conclude: python2.6 is not a symlink to python2.7
$ less fs/usr/lib/python2.7/dist-packages/NvidiaDetector/*
press 'v' to open an editor (e.g. nano, vim) to get syntax highlighting if preferable

Pay special attention to configuration files, especially if they are using directories like /etc/init (for startup scripts) or /etc/modprobe.d (options for loading kernel modules).

For binaries, ldd can give an idea what a program could be used for. The below program uses like a graphical program that uses OpenGL.

$ ldd /usr/bin/glxgears
    linux-vdso.so.1 =>  (0x00007fff7d3ff000)
    libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007fa2ead11000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa2eaa8d000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fa2ea754000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa2ea3b5000)
...

After you are sure that the package looks valid, you can go on install it in VirtualBox booting off a Live CD and use ps aux, top, strace -f -o logfile.txt programname for further analysis.

Answer 3

Both answers (@Lekensteyn, @jrg) are pretty good. In a nutshell, you are installing files (possibly including binaries) from somewhere else, and either you run them (if there are binaries) or they may be configuration files that do something (read: they can do everything).

No matter what operating system or GNU/Linux distro, you should only do that if you trust the source. You are effectively trusting a bunch of alien code and files to run and reside on your computer. If you are really interested in the feature provided by the package, use the tips above.

If it's a bunch of binaries, unless you're willing to spend some weeks doing deep disassembly, there is no way you can know what it does.

In short, quoting @Lekensteyn, be paranoid.