The Pipelight version 0.2.3 introduces new security concepts for using Windows plugins on Linux - this includes EXPERIMENTAL sandbox support and an easier way to update to the current version of plugins. Since the number of supported plugins and Pipelight users is increasing the topic security got much more important and we started to develop new mechanisms to lower the surface for attacks. We will of course still provide regular pipelight updates, especially for security critical stuff (0.2.2 for example was only a security update containing a new version for flash and some minor bug fixes), but we wanted to improve this even more. Before we take a closer look at these new features I want to inform you about some changes which are not directly related to this Pipelight version but important nevertheless:
--[Pipelight PPA]--
The most common way to install Pipelight on Ubuntu is by using our PPA or to be more precise to use two PPAs since the Wine build of Erich E. Hoover is required by Pipelight. Since we are working together with Erich E. Hoover the division in two PPAs was more some kind of artificial restriction caused by the PPA system, but did not really represent the way we shared patches and code. Recently we decided to merge our work into a single new PPA so that is no longer needed to add two PPAs and moreover allows us to update packages more easily. The disadvantage of this change is that Launchpad does not allow us to redirect users from an old PPA to a new one and this step requires manual user intervention. The required instructions in order to switch to the new PPA are:
sudo add-apt-repository --remove ppa:mqchael/
pipelight
sudo add-apt-repository --remove ppa:ehoover/
compholio
sudo add-apt-repository ppa:pipelight/
stable
Since not all users will read this notice, we will keeping pushing new updates also into the old PPAs but may stop this in the future. It is therefore recommend to execute the commands above.
--[Pulseaudio]--
One common problem while using Pulseaudio is that the provided ALSA emulation layer contains some bugs which randomly break the sound output and cause fast-forward playback in Flash or Silverlight. One way to work around this problem is to avoid the ALSA emulation and directly communicate with the Pulseaudio server, which is not directly supported by the original Wine version. Nevertheless, Canonical wrote some patches to implement this missing feature and also applied them to the regular Ubuntu version of Wine. We decided to include them also in our build since it is possible to switch between both of them and it may fix the sound problem in some cases. If you experience new issues since the update, take a look at https:/
/answers.
launchpad.
net/pipelight/
+faq/2444 on how to switch back to ALSA. For those of you who are not using Pulseaudio nothing will change since Wine will automatically fallback to pure ALSA.
--[Smaller / Experimental Plugins]
The number of supported plugins increases and also creates a new problem which is caused by the fact that most browsers try to avoid loading the same plugin multiple times. They do not load a plugin twice if the inode and device of the plugin file is the same as it would be the case if you have multiple symlinks or hardlinks to the same file. This has the disadvantage that we need to copy our libpipelight plugin file for every supported plugin and therefore waste much more space than theoretically would be necessary. Since we need to replace these files on every update, we need to store the copies at a central place in the filesystem and it therefore requires root rights for this step. Until recently we automatically created these libraries for all supported plugins.
This solution is not longer practical as we also started to implement smaller and experimental plugins and therefore split them into two categories. The first category contains the most commonly used plugins like Flash or Silverlight while the second one contains only plugins which are not used by a larger part of the community or simply do not work very well yet. The plugins inside the first category will still behave like in old Pipelight versions and you can enable them by using "pipelight-plugin --enable" while plugins from the second category will need an extra call of "pipelight-plugin --unlock-plugin NAME". The "--unlock-plugin" / "--lock-plugin" commands will create / remove these copies and therefore the disk usage by pipelight will more likely fit your number of used plugins. If you try to enable a locked plugin, you will also get an error which shows how to unlock the plugin. The current supported plugins by category are:
Normal plugins:
- Silverlight
- Flash
- Unity3D
Exerperimental:
- Schockwave (was put into this category as the number of users is quite small)
- Grandstream (Camera surveillance plugin, does currently work only in Firefox, only useful if you have such a camera!)
- Foxit PDF (highly experimental, does not work most of the times)
--[Plugin Updates]--
Our current solution for providing plugin updates to our end users is to issue a new version of Pipelight as the normal plugin updaters do not properly work inside of Wine. While normal plugin updates will be included in the next regular release, we try to push out new versions within a timely fashion if the update is security related. Nevertheless it takes some time till an update reaches all users since we can not provide packages for every distribution and it therefore depends on the corresponding package maintainers.
The plugin versions are mainly controlled by the dependency-
installer script which contains the download URLs and hashes for the plugins. If the hash does now longer match your installed version an upgrade will be triggered. To give our users at least a manual way to update this script independently from the pipelight package, we implemented the "sudo pipelight-plugin --update" command which will fetch our current git version of the script. The git version should be updated within 24 hours after an plugin update, but feel free to poke us in the #pipelight channel on IRC Freenode if we missed an update. The script is signed by a 4096 bit GPG key shipped with the pipelight package so that you can be sure that noone else is able to mess around with it. You can also add this command as a daily cron job if you want to receive plugin updates immediately.
--[EXPERIMENTAL Sandbox]--
*** WARNING: Even though we announce the sandbox here, it still has to be considered HIGHLY EXPERIMENTAL. This part addresses only experienced developers! ***
Last but not least the main change inside this release is the support for our new sandbox called 'pipelight-sandbox' (I know, very creative) which should protect you from any harmful action done by a plugin. The NPAPI itself does not support any sandboxing and it is therefore not possible to restrict the permission of a plugin. To get around this restriction we decided to put the whole wine process with the plugin into a sandbox to protect our users against Windows malware or other infections. Our aim was to use a sandbox which does not have any big impact on the speed and perfectly fits our needs. We started to write our own implementation, which is based on namespaces (similar to lxc containers) which has mostly two advantages: the namespaces do not have any impact on the performance compared to for example ptracing a process and instead of denying access to specific functions we need to grant them.
The sandbox will protect you from any permanent changes by marking your filesystem as read-only (except the wine directory) and completely separating all processes inside the sandbox from your regular ones. The processes inside the sandbox will not be able to see the processes outside, since they are run in a different PID namespace, and all kind of communication through sockets or shared memory is blocked. The only exceptions are the pulseaudio socket and the Xorg socket so that the plugins will be able to play sound and display video data. Both sockets are not directly available but will be proxied through our sandbox so that we can filter out file handles or other possible harmful messages. All these exceptions are not hard coded into the sandbox but are controlled via command line parameters. To protect not only your computer but also other machines on the network all local IP addresses are blocked except the Port 53 TCP/UDP to allow DNS resolving with local dns caches.
As mentioned in the introduction our current implementation is still HIGHLY EXPERIMENTAL since changing the namespaces requires root rights and the pipelight-sandbox must be a SUID binary. We would like to get some feedback from EXPERIENCED PROGRAMMERS before we are going to release the first stable version and therefore provide the sandbox inside a separate PPA. The only disadvantage caused by the usage of namespaces is that it requires a recent kernel (>= 3.8) to work properly and you will need Ubuntu 13.04 / 13.10 if you want to use the standard Ubuntu kernel. If you have a suitable kernel, you can test the sandbox with Pipelight by executing the following steps:
sudo add-apt-repository ppa:pipelight/
experimental
sudo apt-get install pipelight-sandbox
sudo dpkg-reconfigure pipelight-multi
You will need to answer the question whether you want to enable the sandbox for Pipelight with yes otherwise Pipelight won't use it. The reason behind this question is that the sandbox also works with other linux processes and is not only limited to wine. Packages for other distributions may follow when the sandbox reaches a stable state, but it is also very easily to compile it yourself. The only needed build dependencies are the development files of iptables.
The sandbox is still under development and not all features like graphic acceleration may work with all drivers. One small issue we found during our tests is that not all distributions load the required iptables modules during the start of the system. The iptables rules are only active inside another network namespace and therefore they won't affect your normal system, but the necessary modules must be loaded. If you see an error, when you start your browser from a terminal, which is telling you that iptables is not found, simply execute "sudo iptables -t mangle -L". This command will simply list the rules of the mangle table and is just used as a dummy here to force iptables to load the missing kernel modules.
If you are interested in playing around with our sandbox or want to hack it, feel free to take a look at "pipelight-sandbox --help" to get more information about the available options or take a look at the wine-sbox script used by Pipelight. The command "pipelight-sandbox bash" will for example give you a sandboxed bash instance where only /tmp write access is allowed.
-------
-------
-------
If you want to see all the changes in detail please take a look at the the full changelog:
https:/
/bitbucket.
org/mmueller201
2/pipelight/
raw/master/
debian/
changelog