• 7 Posts
  • 67 Comments
Joined 1 year ago
cake
Cake day: September 13th, 2024

help-circle
  • it sounds like a Linux password is a red herring, and a secure password even more so

    Yes and no. A secure password is extremely important against some security threats, but completely useless against others. It’s like vitamin C. If you don’t get enough, that’s a massive problem and opens you up to a ton of serious issues, same as if you don’t have enough complexity in your password. But even if you do, it won’t effectively protect you from, say, cancer or unprivileged malware respectively.

    There’s nothing stopping any program from attempting to bruteforce your Linux password, literally running through possibilities hoping to guess it. Modern password implementations usually have some form of bruteforce protection. If you’ve ever entered your password wrong in sudo or KDE’s lock screen, it usually hangs for a few seconds before telling you your password is wrong, even though any modern computer will have determined it was wrong in literally an instant. This is to prevent a malicious program from endlessly trying random guesses until it gets it by making the time that would take to guess a sufficiently unique password too long to be practical. Your phone and optional software available for Linux go a step further, imposing longer and longer delays with each subsequent failed password attempt, and also prevents malicious programs from spawning many threads each independently calling sudo to bruteforce in parallel by completely disabling access until the time penalty elapses. Though you absolutely do need a sufficiently secure password and a anti-bruteforce delay, making it overly long has diminishing returns past a certain point, it doesn’t matter how many thousands of years it would take to bruteforce, but the upgrade from thousands of seconds with a simple password like “hunter2” to years is the important part.

    Also, a password is like a padlock on a wooden box. Even if they don’t have the key, they can still just cut the box open. In computer terms this would be if someone accessed the files in your SSD directly and injected malware with root privileges, both completely bypass the check that’s “normally” supposed to stop unauthorized users. Encryption can help but like you said, physical access is generally considered game over anyway unless they found your computer while it’s off and it is never returned go you for you to enter your password. A computer with encrypted everything wouldn’t boot. Your EFI partition and especially your firmware have to be unencrypted, and anything unencrypted can be tampered with by a sufficiently skilled attacker with physical access to add things like keyloggers and backdoors that sit dormant until you graciously decrypt everything for them.

    If SSH is disabled the class of attacks to be prevented are users ‘voluntarily’ running malware pretending to be goodware.

    More or less as far as I know, provided you don’t have any other way of remote access (VNC, RDP, Anydesk/Teamviewer and similar, that weird Steam remote desktop app, a server running vulnerable software on an open port that can be hijacked, etc). In computing, the general rule to follow is if you don’t need it, don’t enable it, otherwise it’s ripe for abuse. Though that being said, your router should be configured to block local port access from the internet anyway, but if you have another infected device on your network, that’s a major threat. If you do want SSH, configure it to only accept the keys of your trusted devices and not just respond with a password prompt to any device that comes knocking.

    True, but does anyone operate this way? At that point it becomes an iPad or a Chromebook.

    “Trust” in computing is fickle and complicated, just like real life. At the end of the day, you have to make a decison on who and what you personally trust. An iPad or Chromebook would be the least trustworthy computers in my mind because it’s locked down and administered by companies I absolutely do not trust, and though the locked down architecture does prevent other malware from infecting it, there’s probably already malware by any other name on it with proper Google or Apple security signatures that came with the device from the factory.

    This is the same as if your distro maintainer is untrustworthy. They could slip in malware into the official package manager and you’d never know. I personally trust a reputable Linux distro over the literal biggest tech corporations in the world, but I’m still putting my faith in an organization I do not control nor personally know the people in control.

    Open source is more trustworthy than proprietary software because the source code is available, but even that isn’t completely guaranteed to stop malicious code from making it in. The recent xz backdoor comes to mind. You’re still trusting that the people looking at the source code actually catch the malicious part, and that’s not guaranteed when everyone working on it are overworked and stressed like software developers tend to be, and even when that happens, it might be months of years down the line after the damage has already been done. There’s a reason a full security audit of an app can cost anywhere from thousands to millions of dollars depending on how big the codebase is. Also, because the vast majority of software aren’t compiled in a reproducible way, you don’t really have a guarantee that the actual binary executable that’s on your computer exactly marches the source code unless you go through the (usually difficult and frustrating) process of actually compiling it yourself. Sure, you can probably assume that the official release by the source code authors and signed with their cryptographic keys matches the source code since both come from the same place, but that’s not guaranteed and you’re still trusting a person or organization.

    But wait, there’s more! The compiler you use is itself a program that needed to be compiled by another compiler, and so on and so fourth until you literally reach the stage decades back where someone manually wrote the individual bits for the very first compiler in that chain. A malicious compiler can be made to obfuscate the fact that it’s malicious, and only a manual review and reverse engineering of the raw binary (without reverse engineering software, mind you) can prove or disprove it’s compromised.

    Finally, there’s hardware. Even if you audit every single bit of software, the process itself has immense complexity that you can’t audit without, 1, extremely expensive scientific equipment, and 2, destroying it in the process, and that’s only one chip out of the tens of chips in a computer. Your processor could have secret instructions that bypass all security and your only real hope is to bruteforce every possible input to see what happens. And proving existence is much easier than proving absence.

    I’m not trying to scare you, but I do want to illustrate just how hard it is to have absolute trust in any computer. At the end of the day, you can never have a computer you completely trust unless you manually assembeled it from raw materials (not aided by any existing computer) and hand wrote every bit that goes into it. Like I said, we all need to make a decision to have faith in some person or organization we do not know. You can spend every waking minute auditing every last part of your computer, hardware and software, but then you wouldn’t have time to actually use it for the things you want to do. There’s no solution to this, there’s only higher and lower degrees of trust and security, which only you can determine for yourself.

    So no, no one operates that way, because it’s impossible.


  • unprivileged programs have limited/no ability to do scary things to your computer. they might be able to read some data, but it’s not going to implant malware in the boot sequence for Windows.

    No, but they can still severely harm your computer/data. Unprivileged programs can still delete or encrypt everything in your home directory or inject themselves into other unprivileged programs or a commonly used shortcut file. You’re probably thinking of containerized apps which are much more limited than the default user permissions and access can be given only to what is needed instead of everything your user has access to.

    Linux is as susceptible to this as Windows. It’s not that hard to write a proof of concept malware in Python that copies itself to somewhere in your home directory and appends python ~/.some-boring-config-directory-most-people-never-open/some/more/subdirectories/for/obfuscation/persist.py to your bashrc. You can do the same on Windows with Powershell, JScript, or even VBS, all of which can do severe damage even without privilege escalation.

    For example, there was that fake captcha scam a while back which social engineered people into pasting Powershell scripts into their run window, and is able to persist even without UAC permissions. A well known equivalent attack on Linux are those bash shell tutorial sites with the handy copy button next to the listed commands, which can control what is pasted into your clipboard and might not actually give you the command it appears to give you. Even on a user space bash terminal, something like rm -rf /* can delete all your data, ironically not the system and application files that can be replaced (since those require root) but it can delete your personal files that you actually care about just fine. They can also persist on your system by appending stuff into your bashrc with >>, because that file is owned by your user and therefore doesn’t need extra permissions.

    Any modern operating system is so complex and has so many parts interacting with each other that it’s always possible to hide something malicious somewhere in the Rube Goldberg machine which most people will never notice. Real malware don’t use the typical persistence methods normal programs do because they are well documented and easy to defend against. Linux can be said to be better than Windows in this regard due to being open source and auditable and therefore doesn’t have nearly as many undocumented hiding places (and Linux is generally less Rube Goldbergy), but it is definitely not immune. Never ever run any untrusted program or script, not even unprivileged. The biggest thing Linux has over Windows in this regard is the package manager, which is actively moderated by your distro maintainers, so you don’t have to download random installers from the internet like on Windows.









  • DO NOT download and install random programs from the internet. Not a deb/rpm file, not an elf binary, not an install script, nothing. Use your package manager or desktop environment’s app store. At most use flatpak or snap packages.

    Linux gets its reputation for not getting malware from the same place Mac does: It has a managed app repository where you get all your software from. Difference is Mac doesn’t let you install arbitrary programs at all, while Linux expects you to know better than to do that. Someone who doesn’t know what they’re doing downloading Linux programs from random websites will inevitably hit one of the super rare Linux malware in the wild.

    Even ignoring security issues, running an install script even from a reputable open source project’s website can open you up to package dependency hell. And if you ever need to upgrade or modify it, you’re in for a rough time because none of the existing tools built into your distro will help you. It’s even worse than Windows when this happens because Windows at least expects for things like this to happen (because everything comes in its own installer and handles updates separately) and has UX elements to help non tech savvy users deal with their mess of apps, Linux expects anyone bypassing the normal package manager to know what they’re doing and if you don’t, it won’t be a good day for you.



  • Google managed to backdoor Linux and Firefox with their “FOSS” libWebp. Took literally years until some security researcher not affiliated with any of them found the bug by chance and made a public report, and by then it had already been explited by NSO for ages. If they had worked for Google (or Apple/Microsoft/Amazon/any of the other corporations that just imported Google’s libWebp code without looking at it) they would have gotten silenced and the exploit would still be there as a gift to Israel. Turns out just because it’s auditable doesn’t mean it gets audited before it’s too late.







  • Maybe I’m just a young whipper snapper but I don’t get why people would want cartridges when freely copying the files to the main drive is an option since this would only work with DRM-free games. Cartridges were historically used instead of floppy disks or optical disks for DRM as you can make them basically impossible to duplicate. Even now the only reason Nintendo still sells cartridges is to allow the same game to be played in different devices with different logged in accounts while ensuring there is only one copy available between them.

    And so with that in mind the basic idea is that you grab DRM free games (from stores like GOG), and pop them onto SD Cards to turn them into cartridges that Kazeta will detect.

    So now instead of storing games on the computer itself, you have to go out of your way to put them on individual SD cards?

    Also, is it strictly one game per SD card? That would be pretty wasteful of the available space for smaller games.

    I noticed a lot of non-technical people using ChimeraOS/SteamOS getting lost in Steam’s complex menu structure and struggling with basic things like launching and closing games

    I feel like someone who’s so nontechnical they can’t even figure out Steam’s UI, which is developed by a massive company with dedicated UX engineers and comprehensive QA for all their software, would probably also not be able to figure out installing a Linux OS, especially one that doesn’t boot into a normal GUI by default. It also assumes they will have a dedicated computer just for console style gaming, which nontechnical users probably wouldn’t bother with. Unless they plan on selling devices with their OS preinstalled as dedicated game consoles?

    Also, you still have to interact with GOG to get the games. And also be able to find the app data direcrory GOG downloads games to in order to put them onto an SD card.

    This also directly contradicts a quote later in the article: “Kazeta is definitely not for everyone. It requires a bit of work to get started”

    I became disenchanted with digital storefronts and have come back around to appreciating physical media: game cartridges, CDs, DVDs

    I have gotten more and more into collecting old physical games and systems and found them to be a much more pleasant experience than what modern gaming offers

    Fair enough if you just want physical media in general, but I feel like people collecting physical media would specifically want ones branded by the company and not generic SD cards.

    I have become more and more concerned with preserving my digital game collection for play in the future.

    Bur there’s things in between digital storefronts and physical read-only media. Why not just have a special directory on the desktop that autodetects games copied into it? I assume that’s basically what happens when you insert an SD card with a game on it.

    If you want to keep games atomic and prevent corruption of the directory structure, why not just support game directories in the form of tar or zip files and automatically mount them as a virtual filesystem?

    keeping your games untouched and preserved forever

    Don’t flash based storage put your data at risk of corruption if you leave it unpowered for too long? Having the games on the SSD you have powered every day sounds like it would be safer.

    Though at least the flash’s write cycle limit wouldn’t matter with read only cards.


  • HiddenLayer555@lemmy.mltoLinux@lemmy.mlThe state of Linux phones in 2025
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    8
    ·
    edit-2
    3 months ago

    Why? I don’t drive and don’t have a car but I can’t imagine the car itself not already having the exact same features since modern cars already have what is essentially a tablet built in.

    Also, why not just have one of those phone holders on your dashboard like people have been doing before car integration was a thing?


  • Are those actually the only things you find lacking? If so that’s really good, practically the same as using LineageOS without any Google services.

    I don’t use any of the stuff you mentioned and might have to consider Linux mobile as a daily driver if it’s that good. Especially if Google kills custom ROMs, it sounds like the people already running them would feel right at home switching to Linux mobile.

    More importantly, how’s the app situation? Can people generally expect most of the desktop GTK or Qt apps they’re familiar with to be usable on a phone form factor? Is there a reliable way to run Android APKs on regular Linux now? At the very least F-droid apps?