Quoting: dziadulewiczA big hand to Ubuntu also: Linux Mint is based on Ubuntu LTS and Mint uses Ubuntu's software repositories without any compensation :whistle:

And Ubuntu uses Debian's repositories, though I don't know for sure that it's "without compensation". That's kinda how open source software works.

View this comment - View article - View full comments

Quoting: wvstolzingand to cut down the noise in your logs, use a port other than 22 on interfaces connected to the outside world. People are quick to point out that this is not a security measure; & that's true, but it's not meant as such. You just don't want to see 10000 failed attempts per day from probes all over the world on your little home computer.

(Same with opening :80 or :443 to the outside world, regardless whether you're exposing anything of importance. There are a billion probes poking at those ports, no matter what the address might be.)

...assuming they're not just looking at all ports with a tool like masscan (think nmap, but much faster at scanning for open ports).

View this comment - View article - View full comments

Enabling all firewalls and turning on all other security features is a good defense in depth approach. So is arranging your system to not have any listening services, including SSH, if you can make that work for you, since the host firewall of a system with no listening services is only effectively providing a second layer of the same result: no externally originated connections get to touch anything locally.

All of this is sort of a strong perimeter approach tough since one of the single most important things is to harden the system itself. Of that, probably the most important method is to apply operating system and other software updates as soon as practical. This makes sure that announced and unannounced security fixes are applied (sometimes it's prudent for a security fix to be shipped quietly at first to allow the global ecosystem to get patched at least some before making the existence of the vulnerability that was fixed known).

Hardening the system itself matters a lot because it may only take an attacker achieving arbitrary code execution to then exploit a vulnerability in the system that could then be chained through other exploits, if needed, to reach privileged access on the system or otherwise compromise the system and/or its data. The mentioned driver vulnerabilities in the OP seem to all downplay the impact, but I believe I've seen other vulnerability descriptions of "out of range", "out of bounds", "null pointer dereference", and "information disclosure" result in arbitrary code execution, which at the kernel level can mean full system compromise, which as the OP notes, can be done by an unprivileged user, thus arbitrary code execution with those kernel-level vulnerabilities may mean full system compromise, meaning patching the vulnerabilities should be done as soon as practical.

Why as soon as practical? Because an awful lot of vulnerabilities in browsers and the like can lead to arbitrary code execution as the user running the application, which combined with the above, could mean full system compromise. And that's on top of all of the code we're running on our systems from others that we have to trust hasn't suffered what's effectively a supply-chain compromise or in some of our cases, we run because it looks like it'll do something we want (I'll also admit to not always reviewing some code before running it that's from sources other than my OS distribution or some other widely-known and used source and I generally know how to do such a review).

So patch early, patch often. Patching sooner is almost always better than patching later; with good backups, which we should all have (3 copies, 2 backup copies on different media types, 1 backup copy off-site), can minimize a lot of the impact of patching too soon in the rare cases its a problem.

And to expand on what @BlackBloodRun said, if you're not running a service disable it (and possibly uninstall it) since a service that's not available/running/installed can't be hacked no matter how good the attacker is at hacking that service. Like-wise, if you don't use an application, uninstall it: that's one less thing an attacker could potentially exploit if they do manage to get arbitrary code execution on your system. If you must run SSH, especially open to the Internet, a tool like fail2ban can reduce the risk, especially if password-based authentication is used.

View this comment - View article - View full comments

Quoting: KennyQ"Steam Deck hits over 3,000 games either Verified or Playable"

Does the Deck even have 3,000 owners yet?

With over 1700 invites documented on this spreadsheet, it seems plausible to me that there are at least 3,000 owners now:

https://docs.google.com/spreadsheets/d/1QqlSUpqhyBCBYeu_gW4w5vIxfcd7qablSviALDFJ0Dg/edit#gid=1651884584 [External Link]

Edit: Though at least some of those 'got invite' reports appear to instead be a misunderstanding of how to populate one's row in the spreadsheet; I've not tried to check at how common that apparent misunderstanding is in the data.

View this comment - View article - View full comments

Quoting: dpanter

Quoting: vengador4201The Aquatic Adventures of the Last Human

I fixed it by snagging files from the Steam runtime, but the controls didn't work. Did yours work properly?

I looked briefly at the Steam runtime, but apparently looked for the missing library in the wrong way.

I had only tried to get the game to launch to the main menu and hadn't yet tried playing it. I just now played a few minutes and had no issue with at least the ASDF keyboard controls I tried.

I just found a bug in the last line of the getting-it-to-work scripting of my previous post. It didn't affect me because LD_LIBRARY_PATH was previously unset on my box, but it might affect others, so here's the version with the missing ":" added:

 
cat run.sh.orig |sed "s%./lib:%./lib:./usr/lib/i386-linux-gnu/:%" |sed "s%The Aquatic Adventure of the Last Human%TheAquaticAdventureOfTheLastHuman%" > run.sh

View this comment - View article - View full comments

The Aquatic Adventures of the Last Human took a bit of doing for me because Ubuntu 18.04 doesn't ship with a libcurl3 that provides the CURL_OPENSSL_3 symbol. I had to download the 32-bit libcurl3 from Ubuntu 16.04.

It's available at http://security.ubuntu.com/ubuntu/pool/main/c/curl/libcurl3_7.47.0-1ubuntu2.14_i386.deb [External Link] (which is linked from https://packages.ubuntu.com/xenial/i386/libcurl3/download [External Link] )

Once I had the .deb file, I used dpkg-deb to extract the contents (libcurl4:i386 and others conflicts with installing it) and then used them with a modified/fixed run.sh in the directory with the expanded .rar (which I did manually with 7z; I don't recall if I had tried the launcher yet; trying to re-create with an un-install/re-install didn't unpack the .rar).

So these steps might help to re-create what ended up working on my machine, starting from the itch.io library directory:

 
cd aquaticadventure/
7z x linux.rar
cd linux/
wget "http://security.ubuntu.com/ubuntu/pool/main/c/curl/libcurl3_7.47.0-1ubuntu2.14_i386.deb"
dpkg-deb --extract libcurl3_7.47.0-1ubuntu2.14_i386.deb .
chmod u+x run.sh
cp -av run.sh run.sh.orig
cat run.sh.orig |sed "s%./lib:%./lib:./usr/lib/i386-linux-gnu/%" |sed "s%The Aquatic Adventure of the Last Human%TheAquaticAdventureOfTheLastHuman%" > run.sh

View this comment - View article - View full comments

Quoting: NezchanSeveral games aren't working for me, throwing up what seems to be the same error, that I don't have libcrypto so.1.0.0, and some sort of warning about not being able to refresh upload because I haven't bought the game.

This applies so far to Cook Serve Delicious 2, Village Monsters, and Mabel & The Wood.

I note this is from awhile ago, so hopefully @Nezchan has already figured this out, but

libcrypto so.1.0.0

is probably talking about a library from OpenSSL 1.0, which at least on my Ubuntu 18.04 box is at /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 and is part of the libssl1.0.0 package and currently at OpenSSL 1.0.2n.

If you don't have a copy of OpenSSL 1.0 in your package manager, you may be able to symlink the libcrypto.so.1.0.0 filename to your currently installed version of OpenSSL and might get some success. If unfamiliar, the symlink would be created with something like:
 
sudo ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

Another option might be to symlink from the directory with your newer OpenSSL library to the Steam runtime copy, which on my system is at
~/.steam/ubuntu12_32/steam-runtime/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

The games may also want libssl.so.1.0.0, which is another part of OpenSSL and might be fixable in a similar way. You can check for missing libraries, at least that are loaded by the main binary executable by using ldd on that executable, such as with this for Cook Serve Delicious 2:
ldd cook-serve-delicious-2/NEW_CSD2_PS4Steam

View this comment - View article - View full comments