SECURITY_cope_non_Gpl

Introduction

Sometimes there are security flaws resulting from closed sources, parts that can't be fixed or simply aren't fixed quickly, and give the attacker or automatic programs the opportunity to use these security flaws.

So we will explain how to cope with these flaws, which will give the following:

Advantages:

• Easily maintainable system (especially with modules that need to be rebuilt at each kernel upgrade, such as the madwifi HAL that is a wrapper to a proprietary module).
• This solution can also be used by others architectures than X86 and X86_64.
• Increase security.

Disadvantages:

• performance loss
• compilation time
• space

This article is mainly for normal users because the people who deal with hackers already use virtualization with open-source (closed source would increase the risk too much) and services or critical things and that give them some advantages, like:

• Instantly restore the "vitalised" system state
• More tracable,loging...
• Separate system

That can be the purpose of another page...

How it works

So, the previous information maybe obvious for some people that use technology such as chroot-jail, user-mode Linux, and virtual machines.

The main idea is to trap the closed-source in a separate system and interface it with the main system for providing the capabilities that are closed-source for server capabilities such as wifi , or use a separate system in order to run closed-source programs.

This can be use in two ways:

• Server machine can use proprietary kernel modules in order to provide services such as:
  • Proprietary wifi(mad-wifi, ndiswrapper...)
  • Proprietary modules from some raid card manufacturer (some provide open-sources modules such as highpoint or promise but some don't).
• Client machine
  dealing with X11

Comparison

There are to many technologies that an X86 user can use, so we need to compare them.

Closed-source Programs,modules...

• Kernel modules
  we will use user-mode Linux and a minimalist Gentoo if the modules can be directly used by the architecture (X86,X86_64(now there is more and more things available for this platform),mad-wifi(the hal is available for a lot of architectures))
  for non X86 users,and if the modules can't be directly used by the architecture we will need to use a virtual machine
• Flash
• wine
  must know if it's possible to run code out of the wine environment
• win32-codecs
• games
  • unreal tournament(security flaw)
  • kernel modules

for things such as games,flash i don't know how to deal with X11:

do we need to run X11 in the "virtual machine" or can we network it to the main Linux installation