• 0 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: November 4th, 2023

help-circle

  • I accidentally overwrote /etc/passwd once and I allowed /boot to run out of space during a kernal update and I created a local user with the same user that was also on the realm/domain that I had joined and various bash script issues.
    Some stuff I’ve had to fix that someone else did:

    • named a file rm -rf
    • rm -rf /bin instead of ./bin – Also the fact that they had sudo was crazy and also I guess this was the second time
    • chmod -R 777 /
    • Various software bugs running swap out of space or hitting the inode limit by creating files over and over again with a timestamp in the filename and having to remove all of them because there was no backup to the OS
    • Someone disabled SELinux because something wasn’t working but didn’t tell anyone – ugh
    • Compiled java because they googled some issue and followed some old tutorial without understanding anything instead of using alternatives and symlinked the old java from /bin to /home/theiruser/java – had sudo because he was a Windows domain admin.
    • Cybersecurity guy didn’t know what some VMs did so he turned them off and figured he’d find out if/when someone complained. Caused a massive core services outage.
    • Same Cybersecurity guy deleted a bunch of data because he wanted to see how the sysadmins would respond and witness backup restorations. He did not inform anyone.
    • Cybersecurity guy above still has Domain Admin and sudo everywhere. I would have personally removed his privileged access regardless of what ‘CyberSecurity’ management thought but I was leaving for a new job by then anyway so I figured I’d just let them eventually lie in the bed they made.

    There’s more but I don’t want to keep going because it is Sunday and I don’t want to ruin it.







  • Your immutable OS stays stable. For example, running a sudo pacman -Syu with a bunch of stuff from AUR in your Arch container for example will not bring down your OS or otherwise make it unstable. The immutable image you first install has been tested and it is the same image as the testers – same with the upgrades and updates, so long as you don’t overlap the image with rpm-ostree in this case.

    Immutability keeps your OS stable and if something does happen to go wrong, you just roll it back.

    If that isn’t something you need/want then that’s not something you need/want.


  • Yes, though keep in mind containers aren’t like VMs so the hardware isn’t virtualized or anything. The root system and everything in it is still immutable as well. In usage, it doesn’t matter for the container but it isn’t changing the root since what is writable to the container is outside of the root.

    Using containers this way is the way Silverblue was intended to be used for by the user and pretty much any other immutable distro of note.





  • In a memo sent to employees Mozilla says it wants to bring “trustworthy AI into Firefox”. To help it do this sooner it’s merging its Pocket, content, and AI/Ml teams.

    That’s pretty concerning. It could go either way but I assume they are going to try to shove more sponsored content in an effort to further monetize Firefox in spite of getting hundreds of millions of dollars a year in donations. Maybe I’m just cynical about Mozilla though.



  • I’m not trying to convince you to come back but as for the rpm/flatpak/compiling thing, I recommend people run and I run distrobox containers to solve that. So, I have an Arch and Ubuntu distrobox container. You don’t install them either, you just tell distrobox to download them and it runs them. You install the software with AUR/whatever and apt/whatever and then distrobox-export the app(s) from the container. Then it all runs like any other app from your launcher. You don’t really have to know anything about how docker/podman works and runs. It takes care of it.





  • In my opinion Dan Goodin always reports as an alarmist and rarely gives mitigation much focus or in one case I recall, he didn’t even mention the vulnerable code never made it to the release branch since they found the vulnerability during testing, until the second to last paragraph (and pretended that paragraph didn’t exist in the last paragraph). I can’t say in that one case, it wasn’t strategic but it sure seemed that way.

    For example, he failed to note that the openssh 9.6 patch was released Monday to fix this attack. It would have went perfectly in the section called “Risk assessment” or perhaps in “So what now?” mentioned that people should, I don’t know, apply the patch that fixes it.

    Another example where he tries scare the reading stating that “researchers found that 77 percent of SSH servers exposed to the Internet support at least one of the vulnerable encryption modes, while 57 percent of them list a vulnerable encryption mode as the preferred choice.” which is fine to show how prevalent the algorithms are used but does not mention that the attack would have to be complicated and at both end points to be effective on the Internet or that the attack is defeated with a secure tunnel (IPSec or IKE for example) if still supporting the vulnerable key exchange methods.

    He also seems to love to bash FOSS anything as hard as possible, in what to me, feels like a quest to prove proprietary software is more secure than FOSS. When I see his name as an author, I immediately take it with a grain of salt and look for another source of the same information.