The AusweisApp is Open Source and available on Windows, Linux and even FreeBSD too. You just need some NFC Scanner that works via USB and then you can use it without a mobile device.
https://www.ausweisapp.bund.de/open-source-software
There are still warez sites that upload content in RAR archives, which are then split into individual parts. A download manager can then download them all one after another instead of having to do it manually. There are also hosting sites with weird CAPTCHAs or various waiting times.
Dealing with all kinds of weird download sites is the main selling point for me. It's not just warez, you run into them in all kinds of weird places where a nontechnical person needs to share files with a larger audience (google drive etc only works for small audiences), or where somebody decides to monetize by making a couple cents off your download.
With JDownloader you just throw the link in there, and the software deals with mandatory wait times, captchas, throttled downloads, "you exceeded your downloads for today, come back in 24 hours", etc. JDownloader makes sure it eventually succeeds without me having to baby-sit the process
Fair enough. I do remember using those sites back in the day, and the `.rar.000`, `.rar.001` file lists (or was it `.part1.rar`, `.part2.rar`?). I guess I haven't visited or thought about those sites in a while.
I wish there was finally a decent alternative to this junk. JDownloader pretends to be GPL, but parts of it are closed source. Plus, the Windows installer on the official site is a gamble, and you can only find a clean installer in the forum. The developers claim it’s "just adware", but since it’s a web-based installer, different things are offered depending on your IP address. Some of these install themselves even if you decline them, and some also contain real malware. It was actually to be expected that they wouldn't secure their website properly and that someone else would end up spreading malware as a result.
The only reason to still use this software is that it works with every obscure filehoster out there. Alternatives like pyload are much less effective at bypassing all the security measures these sites put in place to block download managers. It also lets you download videos from streaming sites that other tools like yt-dlp refuse to support.
What part of it is closed-source? You can clone it from the SVN, even the MyJdownloaderClient and all plugins are open-source. Only thing that sucks are their docs because its a Google Doc and there isn't really any explanation but I've got a plugin to work via AI.
Not all plugins are open source. Some of them are included in the jdclosed dependency which is just a blob. The developers claim this is to prevent sites from patching them. However this approach is not compatible with the GPL and the developers have simply been ignoring this for years.
That's not why people use JDownloader. There are plugins for every popular file-sharing site that automate navigating download pages, handling countdown timers, and pausing for ratelimits.
Perhaps we should consider designing distributions to be more tailored to specific purposes. Since no one needs the affected module on a desktop computer, distributions designed for that purpose should no longer include it by default. If this approach were consistently followed, significantly fewer systems would be vulnerable to such exploits.
For most users a system with a kernel as minimalistic as the Android GKI kernel combined with sensible SELinux policies, would likely be sufficient.
You can also simply use Flatpak with the Freedesktop Runtime. It runs everywhere regardless of the distribution. For games Steam offers something similar with the Steam Runtimes. You simply develop for that one container and the software will still be running in 20 years. Even though, of course, making software proprietary isn’t best practice. If you make everything open source from the start the various Linux distributions and users can adapt it themselves for their distribution and eventually modernize it as well.
EOL doesn't mean you can't install or use it anymore. It simply means you shouldn't use it anymore because security updates are no longer available. You face the same problem with Windows software that is no longer updated. The only difference is that no one tells you it's no longer supported.
If my employer would still pay me the same salary, I couldn't care less about the license. I'm all for outsourcing this problem to the package managers.
That is why we should get rid of setuid binaries. GrapheneOS does not use them and was therefore not affected. On the desktop there is also a project called Secureblue based on Fedora Atomic that is moving in a similar direction and has already eliminated a large number though not all setuid binaries. As an alternative to sudo, su, and pkexec there is for example run0, which is available in distributions using systemd. Since systemd 259 there is now also the --empower parameter which like sudo elevates the privileges of the regular user. Essentially any distribution could start removing sudo and create an alias so that users don’t have to adjust immediately.
No, it is not affected by the exploit as presented. This is a page cache write, so writing to a binary that root will run later can work too. This isn’t a reason to push an agenda that dislikes setuid binaries.
AOSP and GrapheneOS have a small allowlist of socket types in the SELinux policies preventing using AF_ALG outside of the dumpstate service used to gather system wide debugging information for bug report zips. It's not available as attack surface on AOSP-based operating systems in practice.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled. Other OEMs may enable it but SELinux policy won't permit accessing it. OEMs can weaken SELinux policy but they're restricted by the neverallow rules which disallow permitting apps to access a list of non-standard socket types including AF_ALG.
That would only work if the user had access to a binary that they wanted to run as root. Ideally this shouldn’t happen at all for most users. There is almost never a legitimate reason to run any program as root unless for example it is a service that absolutely requires it. In Fedora based distributions SELinux also prevents systemd from running any binaries or scripts that the user has access to as root. Removing setuid binaries and strictly limiting features like user namespaces through SELinux would make Linux significantly more secure. It’s absolutely ridiculous that even an outdated Android smartphone is more secure than the average Linux distribution these days.
Yeah. The whole Linux security model seems like it was designed centuries ago. Your permissions are supposed to derive from the authority granted to you at the time of your invocation, and from those with the existing authority to grant/delegate them... not from your lineage, name, possessions, or status at birth. I find it kind of funny that generations of *nix engineers appear to have perpetually struggled with this concept. For all the hate it gets, Windows got this part fundamentally right.
AOSP not permitting setuid/setgid binaries is certainly useful attack surface reduction but isn't how it blocks exploiting this vulnerability. It blocks it via SELinux policy having allowlists for socket types which don't permit AF_ALG to be used outside of the dumpstate service.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled.
Kernel attack surface is mainly done via SELinux policies on AOSP including ioctl command allowlists per device type such as permitted GPU driver ioctl commands, io_uring only being permitted for a few core processes and much more. AOSP uses seccomp-bpf for apps, etc. too but it's mainly SELinux doing kernel attack surface reduction in practice.
I’m a Firefox user myself but there are some very valid arguments against it on Android as well. Firefox on Android is significantly more vulnerable to exploits, lacks internal sandboxing and doesn’t properly isolate tabs from each other.
One thing doesn't rule out the other. Just because a browser has a built-in adblocker doesn't mean you can't replace it with another one if it's not working well.
Every browser should have at least a basic adblocker enabled by default. Anything else is a major security risk. In the context of web browsers ads are the main entry point for malware. Either through exploits delivered via ad banners or by tricking users into downloading something. Many search engines such as Google display fake search results that lead to infected versions of otherwise secure software. Additionally some sites offering downloads have ads disguised as download buttons that lead to something else. A browser manufacturer should try to protect its users from such things.
If browsers came with ad blocking that's enabled, it would just make those lists less effective since advertisers would have a serious incentive to work around them. I'd rather ad blocking only be used by people who care enough to install it.
Can this extension effectively block ads on YouTube? When I manually enabled the Rust ad blocker in about:config and added filter lists there, ads still appeared on YouTube and some porn sites. While uBlock Origin blocks everything.
reply