Skype now has a rather functional web interface, at least in Chromium-based browsers. If you need to use Skype, I think this is a preferable solution to the sandboxing approach presented in this blogpost (which I no longer use).

More of the same. After sandboxing Dropbox, I also wanted to run Skype as its own user. Again, this is not an endorsement of Skype, which is proprietary and quite creepy software.

Once again, I chose to use a lightweight solution where Skype is run as a separate user and where I implement access control with various mechanisms, as opposed to more ambitious approaches using containers, virtual machines, etc. The main difficulty is that, unlike Dropbox, Skype is not headless, so it needs to access the X server, whose security model is far from perfect. If Skype could directly access the X server, it could log all keystrokes (even those directed to different applications), take screenshots, etc. I use the approach of running Skype in Xpra, following an idea found here. Xpra acts as an X server to which Skype will connect, and it will display as a client in my real X server, but it will not relay X events of my server to its client unless they are addressed to the client.

However, one should keep in mind the possibility that Skype could access desktop notifications, and possibly (and more annoyingly) that it could be accessing clipboard data.

User setup

Start by setting up the Skype user as in my sandboxing Dropbox guide, following steps from 1 to 5. You can probably be stringent with the disk limit (I used 500MB), but you should be generous with the RAM limit, as Xpra may fail to start otherwise (I used 1024000000 bytes). Step 5 can be followed as-is because the ports used by Skype are the same as those used by Dropbox.

You should also add yourself to the skype group, to be able to access later files created by the skype user.

If you want Skype to be able to access the webcam, on Debian, the skype user should be put in the video group. However, I am not sure about the security implications of this choice.

Pulseaudio configuration

A problematic issue is that Skype will need access to the speakers and microphone. I use PulseAudio with a user-level daemon for my user, and we need to arrange things so that the skype user will be able to connect to the daemon. Of course, however, we will not make the pulseaudio open to all local connections, and only allow them from the skype user.

To do this, we need to change the Pulseaudio configuration to create its socket at a place where the skype user can access it, and instruct Pulseaudio clients to look for the socket at its new place. The following assumes that you do not have a configuration file already:

mkdir -p ~/.pulse
cd ~/.pulse
cp -n /etc/pulse/default.pa .
echo "load-module module-native-protocol-unix socket=/tmp/pulse-socket" >> default.pa
cp -n /etc/pulse/client.conf .
echo "default-server = unix:/tmp/pulse-socket" >> client.conf

Once this is done, restart Pulseaudio. When running Skype (using the script that I will talk about later), the credentials to access the main Pulseaudio server will be passed from the main user using pax11publish.

Mind the security implications: this means that you may consider all sound input and output compromised while Skype is running. This is hardly avoidable, however, as Skype communications themselves cannot be considered secure.

Skype installation

First, apt-get install the dependencies of Skype.

Then, download the Evil Skype Binaries from skype.com, put them in the home of the Skype user and chown them so that the skype user owns them. Of course, retrieve the "Dynamic" version, as the point is that we want to be able to install them without root privileges. As the skype user (sudo su -s /bin/bash skype), extract them. I recommend symlinking the created folder to "skype" so you can have a path that does not change even when you update to newer versions.

Setting up Xpra

Install xpra (it is packaged for Debian).

Then do the following as the skype user, which we will use to host the Xpra socket:

cd ~skype
mkdir xpra
chmod g+rwx xpra

Running Skype

The task of running Skype is a bit complex, so I wrote a script that does it for me. It also does similar sanity checks to the one done by my dropbox wrapper, to make sure that the access restrictions don't suddenly stop working.

The way it works is that starts an Xpra display without Pulseaudio (as we will be connecting to the Pulseaudio server started by our true user) and with --mmap-group and the right socketdir to make the socket accessible to members of the skype group (that is, your true user); also using a specific local encoding to avoid JPEG artifacts. It waits for the server to be ready, and then uses pax11publish to send Pulseaudio credentials to the server. Then it runs Skype in the Xpra display and attaches it from your real session. It also includes what is needed to kill all Skype processes when you are done using Skype.

The script will not work out of the box for you, but you should be able to adapt it to your needs.

One problem that you will have to fix is that sound notifications will not play because Skype will be unable to find them. This can be fixed by going in Skype's parameters, and selecting manually the sound files in the ~skype/skype/sounds folder.