Remote code execution is a concern. Your server and your network as a whole (including other VLANs) are susceptible to attack if Jellyfin is compromised. If Jellyfin is running on the host, it would be trivial to hack your server (and anything else running/connected to it). If Jellyfin is in a Docker/Podman containers, it doesnt prevent attacks against the host (sandbox escape, kernel privilege escalation, etc), or against your network over some ports. Even if the server is on it’s own VLAN, a vulnerability or weakness in your router could still lead to a compromise, meaning that any devices that is in any way connected to your router (including personal devices) could be attacked.

There is a lot of depth to this topic of course. And at some point you just calculate your risks and weigh your options. There is no such thing as perfect security of course.

Um, so, uh … umm … uh, I think, uh … I think I know uh … someone uh

Can you elaborate? Seems interesting.

On the first laptop the missing folders are likely to do with the fact that the Flatpaks are installed as system Flatpaks, therefore installed under /var/lib/flatpak (iirc). Flatpak is configured to let you install them as system wide Flatpak apps, meaning other users on your computer will also see them. It would normally require authentication to do that, but many distros configure it to be easy by default.

The second laptop is installing them as user Flatpaks, meaning the folders (mostly shared libraries, desktop entries, and apps) are stored in the user’s home folder.

Just because AOSP uses many of the Linux kernels security features doesn’t magically make other distros more secure. Same with servers vs desktop, which have far different usage requirements and patterns, and vastly different threat models.

Linux desktop is a decade or more behind the curve on exploit mitigations and harm reduction. Social engineering is still a security failure, and it almost as much the fault of OS developers that people are falling for these attacks.

Only recently has sandboxing become more popular for distributing applications, but it still isn’t even close to as secure to AOSP or IOS/MacOS sandboxes. Flatpak and Snap are inherently insecure and that isn’t even their fault because they aren’t really meant to be secure sandboxes; they exist for easy system agnostic app distribution.

Many users still use X11 (or xwayland) which is consistently the source of vulns and regardless is massively insecure. X11 is a nasty rats nest of code and hacks which is massive, complex, and often runs privileged. Ever X11 app has complete access to the X server, and can: record the screen, read all window events and positions, record all keystrokes, send keyboard and mouse events, and much more. Wayland is a good step in the right direction. But Wayland compositors can also suffer from easy attacks, like using LD_PRELOAD to record keystrokes.

Speaking of LD_PRELOAD, most users have .bashrc writeable in there home. Any app that has write access to their home directory can preload a malicious binary which can modify and exploit the running app.

With .bashrc writeable, a hacker can just change tbe user’s $PATH and create a fake sudo binary which records the user’s password, and escalates to root without them knowing. Even specifying the full path isn’t safe, because a hacker can just set an alias which takes priority of the actual path of the binary (eg. /usr/bin/sudo could be an alias of /tmp/sudo).

Now I hear you saying, why didn’t the user just NOT run the malicious script or app? With supply chain attacks being at all time highs, you can’t just rely on trusting your application developer. An app could get compromised and you wouldn’t know. Even if you verify signatures, OpenPGP and GNUPG are inherently broken (see: gpg.fail, Latacora blog, Mathew Green blog)

Most distros use extremely weak memory allocators which allow for easy exploitation of memory corruption vulnerabilities. Hardened_malloc by GrapheneOS works on desktop Linux, with most apps just working fine out of the box. It helps to eliminate (or severely increase the complexity of) memory corruption vulnerabilities.

Many distros don’t use mandatory access control policies like AppArmor or SELinux (eg. Arch Linux and its derivatives), and even if they do it isn’t compare able to AOSP, like Fedora which use SELinux but doesnt by default isolate all applications with strong policies.

Then there are LTS distros, which because of their release schedule and also the way that CVEs are assigned, often miss important patches which go unnoticed (or not triaged for their security impact). See the recent copy.fail vuln which because of its disclosure timeline wasn’t given ahead of time to distros. The only ones affected were slower moving distros, where as rolling release distros were fine (eg Arch Linux).

Of course let’s not forget SETUID and SETGID which are the source of many many privilege escalation attacks, like in the case of that AppArmor vuln about a month ago. Daemon based privilege elevation tools (such as s6-sudo) avoid this problem, but they are not widespread. Systemd’s run0 is a more popular example, but just like everything with systemd it is a massive attack surface and extremely complex under-the-hood.

Linux has many security modules (LSMs) such as MAC (eg. SELinux), Seccomp (for filtering syscalls), Landlock (for filesystem and network isolation), unprivileged user namespaces, etc. The only popular apps which make use of some of these features are browsers.

Of course drivers are another source of vulnerabilities because the are implemented in kernelspace instead of using a standardized ABI.

Linux is not a secure desktop OS. Neither is it very secure for a server OS (without extensive development of tools which properly use the kernels security features).

I could apply most of what I have said to the *BSDs within the context of Desktop OSes.

I agree with most of your points. But the *BSDs are not somehow more secure as a desktop OS. The suffer the same fundamental flaw which are present on Linux: no sane/coherent threat model. Desktop apps run unsandboxed without any MAC policies. The *BSDs also lack many of the useful security features available on Linux (not that most Linux distros do anything with that stuff either, except AOSP and ChromeOS). Just cus a kernel is more “secure” does mean anything when the stuff implemented in userspace doesn’t make use of any of those features.

SELinux is very powerful, same with Seccomp and Landlock. But do any distros make extensive use of that and actually also sandbox applications.

FreeBSD has capsicum (and also an implementation of FLASK?, which is what SELinux is for Linux). OpenBSD has pledge. But are apps required to run in a isolated environment? Many of the *BSDs (and certainly .most of their users) still use X11 instead of modern alternatives like Wayland. The are still monolithic kernels which dont implement drivers in userspace, network, etc in userspace. Not secure at all.

MacOS is more secure, I agree. But it isn’t trying nearly hard enough IMO.

FreeBSD has cleaner code and a far simpler kernel. More eyes on the code doesn’t make the code quality magically better, and vis versa. Linux has many security features not present in the *BSDs, but it also has a massive attack surface and has been historically hostile to security features (see: grsecurity isn’t upstreamed because it was rejected by the kernel maintainers).

Flatpaks are not a secure sandbox. The sandbox exists to distribute apps, and the security is secondary. Apps are very minimally sandboxed. A better permission system would severely weaken the sandbox with basic permissions needed by so many apps. The amount of apps on Flathub that I have seen which need access to org.freedesktop.Flatpak which removes the sandbox. Browsers have their own sandbox crippled because Flatpak blocks namespace access, but that is not a problem for Snaps. Flatpak does not implement many (or any) modern exploit mitigations. Apps that have audio permission have microphone access, and access to all desktop audio. X11 access doesnt use something like Xephyr for a separate X11 to prevent apps from escaping the sandbox, especially on a X11 desktop environment. Etc, etc.

Now dont take me for a Snap shill. I don’t think that is very good either. But at least its permission system is more thorough and apps tend to work better in a lot of cases. It also has on-screen permission requests (at least I think). It still suffers from many of the same problems as Flatpak.

I still use Flatpaks though. Just wish things were better.

In school we had a talk from a guest speaker who professionally developed malware. He said kernel-level anticheat was indistinguishable from malware. He said the same thing about (3rd-party) antivirus.

The eye develop from brain tissue, so I wouldn’t be so sure …

deleted by creator

Dissociative Amnesia maybe?

I would probably go with Artix because it is arch based and therefore you will get updated packages instead of perpetually outdated Debian packages. Then maybe switch out the kernel for the CachyOS kernel and you should be good.

Licenses don’t matter when corpos don’t care anyways. Especially for training LLMs. They don’t care about copyright. I choose to use tools based on there merits over simply going “it has my favorite license.” Even though I say that, I still prefer AGPL even though I understand that of the corpos want to steal, they’ll steal it.

@Uair@autistics.life

Linux Mint is based on Ubuntu Linux. Make sure you are using a .deb which is meant for Ubuntu (or Debian). Laptop is Desktop, as in they are the same OS.

Either double-click the .deb file and click the install button.

Alternatively you might be able to right-click to get a context menu and click install from there.

Last option, you could install the .deb from the terminal app. Open the terminal, type cd ~/Downloads (if the file is in your Downloads folder), then type sudo dpkg -i ./EXPRESSVPN.deb (replace EXPRESSVPN with the exact file name), press enter and type your password.

All these install options do the same thing.

Don’t worry about CPU architectures. If you dont know what that is, then ypu dont need to worry. If the .deb has x86, x64, or amd64, that is tbe right file. If it doesnt say anything then just choose the normal .deb.

Most include micro iirc

Maybe? But in reality the stat changes are to do with an influx of Chinese players that happens every year around this time. The vast majority of Chinese players use Windows.

Also I had a friend try Linux, and while it isnt all sunshine and rainbows (and he is about the furthest from an IT guy i can think it), he gets a solid 40+ FPS more than Windows 10. I am not forcing him to use, he just defaults to it now because shit is way smoother, and the alternative is using W11 which can legit brick your SSD (not worth it in this economy).

Also, I really don’t understand being attached to software or developing a personality around it. If Linux doesnt serve my needs I’ll simple use FreeBSD (or HardenedBSD). If that doesn’t work, I hope by that point RedoxOS is mature. Etc for any software.

Because of federation they are probably un-deletable. Most likely federated to multiple servers.

Screensharing is the only thing i dont think it does. Voice and video good. See snikket or conversations.im

Also the repo image