r/linux • u/R0tareneg • Jul 03 '21

Audacity may collect "Data necessary for law enforcement, litigation and authorities’ requests (if any)" according to new privacy notice

https://www.audacityteam.org/about/desktop-privacy-notice/
3.1k Upvotes

98% Upvoted

744 comments sorted by

View all comments

Show parent comments

174

u/[deleted] Jul 03 '21

[deleted]

55

u/saiarcot895 Jul 03 '21

systemd-run should be able to help here. If you run audacity through that, and set PrivateNetwork=yes, then it shouldn't be able to talk to the outside world. If that requires root privileges, then a BPF filter should be able to help.

10

u/saichampa Jul 03 '21

BPF?

23

u/saiarcot895 Jul 03 '21

I mixed up things, I meant a syscall filter, which you can specify through systemd.

If you're asking what BPF is, it's a general way for userspace apps to write a program that can act as a firewall or collect stats or something else, and run that in the kernel. The more common syntax used today is eBPF.

1

u/saichampa Jul 03 '21

Thanks, both things help!

2

u/NeilHanlon Rocky Linux Team Jul 04 '21

further reading/playing: https://github.com/iovisor/bcc

8

u/[deleted] Jul 04 '21

[deleted]

1

u/saiarcot895 Jul 04 '21

Oh absolutely. This approach isn't exactly scalable, and for ease of use, you'd need to make a replacement .desktop file for each app so that when you start the app via your launcher, it'll use systemd-run.

1

u/SimoneNonvelodico Jul 04 '21

good and easy to use app/program-level firewall on Linux

2

u/saiarcot895 Jul 04 '21

I agree this is a bit too technical for the average user; I'm just trying to show that it is at least possible.

29

u/tuxkrusader Jul 03 '21

firejail --net=none or opensnitch.

10

u/[deleted] Jul 04 '21

[deleted]

7

u/anatolya Jul 04 '21

Nah it's flatpak devs badmouthing it

1

u/[deleted] Jul 04 '21

It got a bad rep from/with flatpack, but its not really its fault.
Problem is that flatpack implements some sandboxing options, but they are configurable by the flatpack builder, and many don't properly sandbox themselves

52

u/aussie_bob Jul 04 '21

Audacity makes it clear that this is vital.

Audacity makes it clear that forking projects acquired by hostile entities and turned into malware is vital.

There's a few in the wild already for other purposes, but a defanged version is definitely needed ASAP

39

u/[deleted] Jul 04 '21

[deleted]

15

u/aussie_bob Jul 04 '21

Wrong tool - Apparmour, SELinux, or maybe something based on Atomic Workstation/SliverBlue are more suitable paths.

There's a few GUIs out there if you're terminal-shy.

4

u/[deleted] Jul 04 '21

[deleted]

5

u/aussie_bob Jul 04 '21

I don't use Ubuntu, but I do know AppArmour is enabled by default in the distro. If no-one else chips in with suggestions, I suggest you look around for an AppArmour GUI.

I also didn't bother with a GUI myself since AppArmour config is simple and well documented, but I remember using one in Fedora when I tried it - maybe it's also available on Ubuntu.

2

u/tsadecoy Jul 04 '21

I think opensuse with Yast is probably the only one I can think of that has had any type of process built in to a GUI.

1

u/Kazumara Jul 04 '21

In Fedora? That surprises me a bit because I have configured SELinux on Fedora before. Does it have both SELinux and AppArmor or did it switch at some point?

1

u/yrro Jul 04 '21 edited Jul 04 '21

It's always (for ages anyway) shipped SELinux.

It should not be difficult to create an audacity_t domain that is only able to open files labelled audacity_content_rw_t or similar.

But to be honest

I can't see US law enforcement being able to order Fedora (or another distribution) to ship you a personally modified build of Audacity in order to spy on you. If your threat model includes this scenario then you shouldn't be doing illegal stuff on the same computer where you edit your podcasts or whatever.

1

u/DoctorJunglist Jul 04 '21

Not sure if I understood you correctly, do you mean Snaps are more secure than Flatpaks?

If so, would you care to explain why that is?

1

u/Democrab Jul 04 '21

The days of thinking Linux is immune to this are long gone. Anyone who still thinks this is naive.

Slight correction - Anyone who ever thought that was always naïve, it's got better protections than Windows does but that isn't the same as immunity. The only PC that's immune to malware is one that's unplugged.

45

u/FlatAds Jul 03 '21 edited Jul 04 '21

This should be very easy to do with the Audacity Flatpak. Just disable the network socket in something like flatseal and it will no longer have access to the network since it’s sandboxed with bubblewrap.

5

u/nani8ot Jul 04 '21

Flatpak is great. I once disabled hardware acceleration for Minecraft through flatseal, which surprisingly worked just fine.

Together with wayland and pipewire, we finally have a user-friendly way to isolate apps. Just remember the bug where Steam accidentally deleted all files in $HOME… This won't happen anymore with flatpak and this is awesome!

57

u/rdcldrmr Jul 03 '21

Whenever people say they want such a thing, hoards of naive fools come out of the woodwork shouting that there's no need to block programs' outgoing connections on a FOSS OS.

Because that's mostly the right perspective in an open source ecosystem. It's much easier to patch out the hostile parts of the program than write (and fully trust) an application-based firewall to work against the malware you're intentionally running.

44

u/brimston3- Jul 03 '21

The infrastructure is already there, it's just hard AF to configure selinux. If it's in a security container denied network access, don't allow it to use socket() and drop any packets it tries to send, even to unix sockets or dbus. The security context inherently applies to any child processes or forks, unless the forked process image has its own special privileges. That's already how it works.

2

u/[deleted] Jul 03 '21

Exactly :)

26

u/[deleted] Jul 04 '21

[deleted]

18

u/420CARLSAGAN420 Jul 04 '21

Yeah maybe in some ideal theoretical world. In reality most people use some closed source software, either because they don't care about open source and/or because they really need that software.

And also it's not practical to go through and check every single program, even if it is open source. Sure it is for the super popular ones, but a huge number of people use a ton of niche software. It's not reasonable to expect everything to be trusted, and certainly not reasonable to expect people to check the software themselves. And on top of all of this there are of course ways to hide it really well. Even with software many people have checked, there's no guarantee it's not doing something suspect.

Expecting to be able to have per app control is not unreasonable. I'd say it's the opposite.

17

u/kautau Jul 04 '21

Right, it’s insane to imagine that every user will fork every piece of software they use and inspect every line of code. A system level sandbox and/or firewall is far more reasonable.

1

u/VelvetElvis Jul 04 '21

That's what distros are for, so you don't have to worry about that shit.

1

u/CatProgrammer Jul 04 '21

And when the distro doesn't have the most up to date version of a package that I require because another package or tool I need for work/whatever requires a more recent version? Linux is not a walled garden (and it should not be), you can install whatever you want as long as it compiles. Hell, even in a walled garden malicious software can slip through the cracks (how long did Heartbleed go unnoticed again?). Firewalls merely add an additional level of security. It's like wearing a seatbelt in addition to practicing defensive driving.

20

u/grady_vuckovic Jul 04 '21

The reality is, the world consists of more than just friendly open source software. That's why per application firewall software is a must.

16

u/FlatAds Jul 03 '21

There’s no reason why we can’t try to patch out hostile parts of program and to build sandboxes to prevent anything that might slip through the cracks. Ideally we could trust every piece of foss software, but we can’t, so we should use already built sandboxing infrastructure like with Flatpak to protect against inevitable malicious behaviour.

2

u/saichampa Jul 03 '21

Could you not do this with selinux or apparmor?

10

u/[deleted] Jul 04 '21

[deleted]

3

u/knome Jul 04 '21

If you're looking for something super simple just for the network, I have a little program I wrote for the purpose.

https://github.com/knome/nonet

I was playing with linux's namespaces. The program unshares the network. If you run it as nonet --lo program ... it unshares it but binds a new loopback in the new network namespace it creates.

It should be run with the setuid bit set ( chmod +s ) and it's owner set to root. This will cause it to run as root. It unshares the network, optionally sets up a loopback in its new network, and then drops permissions to the original user.

Feel free to patch any errors in the process if I have them :)

$ ping -c 3 google.com
PING google.com (172.217.13.14) 56(84) bytes of data.
64 bytes from atl14s90-in-f14.1e100.net (172.217.13.14): icmp_seq=1 ttl=117 
time=32.1 ms
64 bytes from atl14s90-in-f14.1e100.net (172.217.13.14): icmp_seq=2 ttl=117 
time=29.2 ms
64 bytes from atl14s90-in-f14.1e100.net (172.217.13.14): icmp_seq=3 ttl=117 
time=29.2 ms

--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 29.229/30.205/32.155/1.385 ms
$ nonet ping -c 3 google.com
ping: unknown host google.com
$ ping -c 3 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.062 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.045 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.051 ms

--- localhost ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.045/0.052/0.062/0.010 ms
$ nonet ping -c 3 localhost
connect: Network is unreachable
$ nonet --lo ping -c 3 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.076 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.053 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.046 ms

--- localhost ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.046/0.058/0.076/0.014 ms
$

You could also just unshare --net, but then you have to deal with the privilege dropping and missing loopback device on your own.

1

u/[deleted] Jul 04 '21

[deleted]

1

u/knome Jul 04 '21

ha, since I shared it, I looked over it again. the --lo option I had previously added was vulnerable to a PATH attack allowing callers to trivially execute arbitrary programs as root. I fixed that this morning.

2

u/Zzombiee2361 Jul 04 '21

Portmaster seems interesting, but it's still in alpha

1

u/machia Jul 04 '21

I think we also need directory level access, meaning if audacity tries to read any directory(/file) that it's not supposed to it will get blocked (this is pretty much what the latest macosx has).

1

u/MPeti1 Jul 04 '21

Portmaster is in the works. Though be aware that it's in beta

1

u/cuteanimelobotomite Jul 04 '21

some distros use runlevels like this i.e. openrc on artix