Switching to ALSA

The honorable @madaidan has pitched this suggestion because it is still updated and less of a problem to isolate with sandboxing. Questions are : is it easy to uninstall pulseaudio? Is there anything important that depends on it? How much space do we save? - If none then maybe it is not worth the bother. I remember at some point TBB refused to use anything but pulseaudio so this needs to be re-examined.

Discuss.

3 Likes

ALSA utilities are already installed by default on Whonix - they’re a dependency of PulseAudio. Removing PulseAudio would serve as general attack surface reduction as well as eliminating the possibility of escaping sandboxes through it. There’s nothing wrong with ALSA, it just doesn’t have as many unessential features as PulseAudio.

2 Likes

Most important question: Does it work on Debian with most applications?

In 2014, you can still run only ALSA. But unless you compile your applications for yourself and enable ALSA support everywhere - or use a source-based distribution like Gentoo - you might get mixing problems. Pre-compiled applications that distros ship are usually only built with support for Pulseaudio, not pure ALSA. Ubuntu for example prefers PulseAudio. It comes with PulseAudio by default, so every application is compiled to only use PulseAudio.

1 Like

ALSA is most widely supported on Debian. Pulseaudiio and JACK are sound servers bolted onto ALSA to provide more functionality. I recommend permitting pulseaudio for sandboxed application that absolutely need it or else people will run apps unsaboxed entirely to get the needed functionality working, or we can figure out how to use JACK instead or plain ALSA if possible for TBB

https://wiki.debian.org/Sound

1 Like

To challenge the assumption on which all of this is based:

  • Any reference showing that ALSA can be sandboxed while pulseaudio cannot be sandboxed?

To challenge the assumption that pulseaudio has to be uninstalled in order to be able to use ALSA:

  • Is removal of pulseaudio strictly required to make sandboxing work? Can’t sandboxing just only permit ALSA and not pulseaudio? Application in sandbox would then in theory use ALSA and not know there is pulseaudio installed outside the sandbox. Then there should be no need to purge pulseaudio. If pulseaudio runs on top of ALSA, why would removal of pulseaudio be required to make ALSA access work?

In a test-only VM for a quick test of removal of pulseaudio:

sudo apt purge "*pulse*" pulseaudio pavucontrol
sudo apt autoremove

To check that all pulseaudio related packages are gone:

dpkg -l | grep pulse

Tor Browser audio still broken after removal of all pulseaudio related packages.

If you wish to move this forward… Let me know which packages are required to make ALSA work in Tor Browser or generally.


Getting rid of pulseaudio completely might be hard/impossible without not changing currently default installed applications

sudo apt install vlc --no-install-recommends

The following NEW packages will be installed:
libpulse0 […]

2 Likes

IME, everything works fine.

It’s only PulseAudio that adds the functionality to escape sandboxes. It doesn’t exist in ALSA as it’s rather bare bones.

https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/AccessControl/

Yes but this will still serve as general attack surface reduction - no point in having a large amount of code that’s not useful for us. It will also help with sandboxes that the user sets up themselves which don’t handle PulseAudio.

1 Like

On Gentoo Linux, making a system free of pulseaudio and systemd is easy. You could also build a binary distribution on top of Gentoo Linux.

1 Like

Gentoo would theoretically be perfect for us as we could design our system from the ground up to be secure, even enabling a host of compiler mitigations like CFI. However, in reality, it’s much too difficult to maintain. We cannot force the user to compile everything themselves as that would be a massive drop in usability, especially for those on weaker hardware. We also cannot compile everything ourselves and distribute binaries to the user as maintaining this would be near impossible with Whonix’s current resources.

1 Like

Calculate Linux is a binary distribution built on top of Gentoo Linux. If you can’t maintain a binary distribution on top of Gentoo, you don’t have much resource unfortunately. I do system upgrade every week on my Gentoo system. Once you get the hang of it, it takes more CPU time, but not much human time.

The biggest cost would be the initial learning curve.

Another alternative is to compile torbrowser deb package yourself. I compile torbrowser without pulseaudio on my Gentoo Linux. Or, you can install libapulse. Whonix should have its own PPA.

1 Like

Mixing porting to another base distribution (which is a very complex topic) on which Whonix is based on with “Switching to ALSA” (which looks comparatively a lot easier) is too much off-topic for this forum topic. Please create a new forum thread for that if needed.

As for porting to another base distribution and (Hardened) Gentoo, see also the following development notes:

This seems cool at first sight. Quote:

PulseAudio emulation for ALSA

The program provides an alternative partial implementation of the PulseAudio API. It consists of a loader script and a number of shared libraries with the same names as from original PulseAudio, so applications could dynamically load them and think they are talking to PulseAudio. Internally, no separate sound mixing daemon is used. Instead, apulse relies on ALSA’s dmix, dsnoop, and plug plugins to handle multiple sound sources and capture streams running at the same time. dmix plugin muxes multiple playback streams; dsnoop plugin allow multiple applications to capture from a single microphone; and plug plugin transparently converts audio between various sample formats, sample rates and channel numbers.

What do you think?

This might help with getting Tor Browser to work with ALSA (without recompilation)? (That is, if Tor Browser currently has a hard dependency on PulseAudio for sound which I am not sure yet.)

Indeed.

We don’t have human resources for that either.
Nobody managed to create one yet even though a very popular request:

Related:
Tor Browser Update: Technical Details

Alright. Some issues mentioned on that link (such as Snoop on other application's audio or Have unmediated access to the microphone) may still be issues with ALSA?

However, I can see the general attack surface reduction argument.

Load and unload server modules, including network ones

Makes sense.

Conclusion:

  • Porting from PulseAudio to ALSA is worthwhile. Help welcome. Let me know which packages to remove/add and/or send pull request for anon-meta-packages.
    • Maybe apulse can help.
    • We need audio support in Tor Browser.
      • EDIT: maybe possible thanks to apulse torbrowser
    • VLC is not important enough for installation by default if it was in theory an obstacle for porting from PulseAudio to ALSA.
  • Porting from PulseAudio to ALSA is however is not a blocker for System-wide sandboxing framework - sandbox-app-launcher.
1 Like

Making torbrowser work with apulse is going to be easiest. It’s basically firefox.
Execute apulse torbrowser

If you want to recompile torbrowser, I can show you the steps.

1 Like

Thanks for the offer. Your expertise might be useful in other areas of development.

Forking / re-compilation of software packages by third parties is done as sparingly as possible. The rationale for this has been documented just now:
Kicksecure Coding Style

Related:
Relationship With Upstream

That might come really handy.

Also, I forgot to mention this before but the Firefox content process “sandbox” allows direct access to PulseAudio, meaning that uninstalling it will plug one hole in the Tor Browser / Firefox “sandbox” (although there are still other holes).

2 Likes

https://wiki.debian.org/ALSA

Most infamously, Firefox does not support ALSA directly and instead uses the PulseAudio API, forcing usage of PulseAudio (or a compatibility layer) as well.

I think its going to be usability issue.

Though if someone want to see how this is going to work with FF+ALSA maybe he should look at fedora 34 (released stable). (But no info about if its going to have same thing within debian)

Quite possibly not. Already addresses earlier in this forum thread.

1 Like

good then we have major distro already using it, and i dunno when qubes going to do the same thing as well later since its based on fedora.

rest is how much its of an issue if its used within debian+xfce.

2 posts were split to a new topic: port from pulseaudio to pipewire for audio support

Why PipeWire, why not ALSA?

1 Like

Pipewire is what Fedora uses in its 34 release:

Debian (seems) as well want to make this step and move toward pipewire, This will give pipewire stability and its already written with security in mind and wayland friendly:

PipeWire was designed with a powerful security model that makes interacting with audio and video devices from containerized applications easy, with supporting Flatpak applications being the primary goal. Alongside Wayland and Flatpak we expect PipeWire to provide a core building block for the future of Linux application development.

But its not yet coming even inside fedora 34 without issues e.g:

using only ALSA may causes more problems like compatibility, vm audio syncing …etc

1 Like

https://lists.torproject.org/pipermail/tor-talk/2021-September/045770.html

ALSA support was removed from firefox a few years ago

So only hope is to make pipewire working.

1 Like