What security policies exist in place for packages and scripts?

Question

I did have used Microsoft Windows since Windows 98 to Windows 7. I have found lots of security vulnerabilities by myself about how viruses, worms, spyware etc. compromises the system.

Microsoft Windows Vista & Windows 7

UAC (User Account Control) system and Drives Autorun prompts in Windows Vista and Windows 7 can prevent some vulnerabilities.

Linux

I am using Ubuntu 11.10 now, and I realized that the most (except one) vulnerabilities does not exist in Linux because of multi-user system.

The Problem

People (even I) used to store *.exe, *.cmd, *.deb, *.sh and other executable and script files (Installers, Portable Browsers, scripts, etc.) in pen drives (flash memories) and other removable media.

• When in Windows 7 (also in older Versions)

  If the target removable media connect to an infected system,
  then connect back to a fresh system,
  and run a *.exe, *.cmd or *.bat (unsigned executable or script) file
  that may prompt a UAC dialog
  and user press Yes

  this may execute malware code as Administrator, injected to the unsigned executable or script file

  I don't know about the signed executable files. Never tested.
  I think, they cannot not be infected or infected file cannot be executed.

• What if, when in Linux?

  Will the same may happen in *.deb, *.sh or any other executable or script files in Linux?

  I mean

  Can the *.deb & other files be infected? (I think they can)

  <p>Is there a mechanism in Linux to verify the contents in <code>*.deb</code> files?</p>
  
  <p>Should I not keep the root access required executable and script files in removable media? If <strong>I should not</strong> then what is the easiest way to manually verify if the file content was changed or not?</p>
  
  <p>What about the repositories and packages from Internet?<br>
  by using <code>http</code>, <code>ftp</code> (not <code>https</code>) the repositories and packages can be infected by an attacker while transporting or over proxies (if used).</p>
  
  <p>Also is there any thing similar to <em>Windows <code>Autorun</code></em> in Linux? (I think it <strong>isn't</strong>)</p>
  

I just want the Linux to be better secured in any condition (even from small mistakes from users).
I will ask about further possible security issues I found.

Answer 1

• Security of Deb and Other Files

You can find a .deb file for a package somewhere on the Internet. Then you can use dpkg -i package.deb and install it. That's no better than picking up an install for Windows somewhere on the Internet. Don't do it unless you are absolutely sure of the source, and even then make sure you have all of the prerequisite packages already installed.

Deb files, safe or not, do follow a format with hashes, etc. so that they have to be rebuilt if they are changed.

Package (.deb files) in the Ubuntu repositores are generally built from source on Launchpad build computers so the contents of the .deb file matches the source, and the source can be viewed by anyone. Many packages have teams maintaining them who follow them and are on the lookout for security problems. New source package versions have to be signed properly by gpg keys using public key cryptography before they can be built.

There are now binary only packages available in the Ubuntu Software Center, so the public can't view the source of those. I don't know about these for sure, but I believe they are reviewed before they are made available.

You generally shouldn't install a package with dpkg -i package.deb, but use apt-get or the software center instead, downloading from an Ubuntu repository. You should also avoid picking up any other kind of script that you can't look at and understand completely before you run it.

The multi-user system Unix-like systems do mean that if you make a mistake you can mess up your account and its files, but not the accounts and settings of other users that have been established on the same system, nor the operating system itself.

The exception is when you run a command with sudo or have to enter a password to install a package or do other maintenance. These are the times to be very careful about the source of what you are doing. This is very similar to using UAC.

• Executable Files on Removable Media

As long as you are using due care, I don't think you need to maintain programs on removable media. Like Windows, most programs are installed as packages and therefore aren't runnable from removable media (although you could put an entire Ubuntu on a flash drive if you want).

• Repositories

As I mentioned above, .deb files use hashes for the files they include to see that they aren't altered by an attacker. Ubuntu repositories also have gpg keys stored on your system when you install Ubuntu, and there is a signature and chain of hashes followed down to the .deb files to keep things secure. Ubuntu is derived from Debian and that project created this approach.

• Autorun

There are things like autorun in Linux and other Unix-like systems. When you install packages those packages can cause programs to start at boot time, or when a user logs in to a terminal, or when a user logs into a GUI session. Most users have a (hidden by default) .bashrc file in their home directories that execute when a user logs in to a terminal.

• CD Security

The Ubuntu download web site not only has the .iso files for CD's and DVD's but also message digests (hashes) you can check to make sure the file you retrieved is authentic down to the bit.

• Ongoing Security

Despite everything else, developers make mistakes and potential security problems can creep into software. Running supported versions of Ubuntu means that you will be offered security fixes for items in the main Ubuntu repositories, and often for items in the universe and other repositories. You should apply those fixes. Long-term-support releases like 12.04 (Precise) offer this service for a longer term than other releases of Ubuntu.

I can't personally guarantee that the precautions are perfect, but I think they are pretty good for the current state of the art.