Thanks for the info! Didn’t realize it was dash.

Rust (Golang or any mem-safe lang) is/are useful for designing secure applications, but not the reason Syd is so great. It is impressive because it is unprivileged, simple yet very granular, has tons of exploit mitigations and hardening options, defaults to hardened_malloc (on arm64 and x64), it’s multilayered sandbox (using landlock, seccomp, namespaces, and more), but of course being written in a memory safe language is an important plus (as memory corruption vulnerabilities are a very large class of common vuln). It abstracts the complexity of working with low-level sandboxing API (such as landlock) while allowing you still construct complicated sandboxes). The dev is also very open to add new ideas.

LMDE is mostly just the apps and visual config. It is verg close to regular Debian. I know for a fact it is basically just regular Debian because I have distromorphed it into Kicksecure several times, which only works on Debian.

I thought about it (and I might still) but the project is still in beta and implementing sysctl and MAC would slow everything down development-wise. Switching to Fish would be easy and cool though.

I am excited to see Chimera Linux mature because iy seems like a distro which prioritizes a simple but modern software stack.

Features of Chimera that I like include:

• Not run by fascists
• Not SystemD (dinit)
• Not GNU coreutils (BSD utils)
• Not glibc (musl)
• Not jemalloc (mimalloc)
• Proper build system, not just Bash scripts in a trenchcoat

What I would like:

• MAC (SELinux)
• Switch to Fish over Bash (because it is a much lighter codebase)
• Switch from mimalloc to hardened_malloc (or mimalloc built with secure flag). Sadly hardened_malloc is only x64 or aarch64
• Hardened sysctl kernel policy

What I want out of a secure Linux (or BSD) system is full (top-to-bottom) sandboxing of all components to enforce least privilege. I am want to learn how to make my own distro (most likely for personal use) which uses strong SELinux policies, in conjunction with syd-3 sandboxing, which seems like the most robust and feature rich, unprivileged sandbox in both the Linux/BSD worlds (also it’s totally in safe Rust from what i can tell).

Another thing that I would love to make is a drop-in replacement for Flatpak that is backwards compatible but uses syd-3 instead. It has much better exploit protections than Bubblewrap, and is actually an OOTB secure sandbox. I dont know much about the internals of Flatpak, or how to use xdg-desktop-portal, but I am going to start more simple with a Bubblejail alternative. One major advantage of syd is that you can modify an already running sandbox, so theoretical you could show a popup that says something like “App1 is requesting microphone access.”, where you could toggle on without needing to restart the app.

Need to get better at coding tho lol

Kagi requires an account, therefore associating all your searches to your account. With DuckDuckGo HTML, you can restrict it so it can’t access JavaScript (which it doesn’t do anyways), therefore reducing the risk of fingerprinting or other tracking.

Combine this with Librera Reader and you can listen to eBooks easily.

Yeah, I already understood that. I just thought the comment above was saying it already had ARM emulation, but it was bad or something. I just misunderstood what the above comment was saying.

IIRC, it is a current limitation of rpm-ostree, which results in an ISO that is nearly double in size.

Pretty sure Waydroid uses the x86 image of LineageOS, cus last time I used it (like a year or more ago) I had to get x86 version of APKs I wanted to install.

If I had to guess, they probably don’t use the APIs, inside using scrapping of some sort.

Yeah np. Good luck.

You can use both through the browser, which is the safest way of doing things because the browser sandboxes the web apps, isolating them from your system. If you prefer an app for Messenger, look on Flathub, though I advise against it. The two apps I found for Messenger are Franz and Ferdium (a fork of Franz with more features).

To mitigate the privacy risks:

• Firefox with uBlock Origin (or Librewolf)
• Avoid sharing anything sensitive.

Nothing much you can do sadly.

I just realized your comment shows a Cromite AppImage? Where do you get that from?

I had heard of AM, and I actually stumbled upon your tool before. Thank you for the tool. I wish AppImage was updated to include sandboxing by default.

Yes, i understand that Flatpak weakens browser sandboxes, i was talking about the risk of a Flatpak which has access to user home and therefore could for example access $HOME/.firefox and steal session cookies.

Also I based my assessment of use FUSE2 for normal AppImages on the security hardening used by Secureblue, mentioned here under the section “Filling known security holes”

There is more to xdg-desktop-portal than I said, it is quite powerful.

https://wiki.archlinux.org/title/XDG_Desktop_Portal

https://flatpak.github.io/xdg-desktop-portal/docs/

This Flatpak shows the power of portals on your system, while also requiring no permissions at all: https://flathub.org/en/apps/com.belmoussaoui.ashpd.demo

Same with this one, but it requires arbitrary permissions: https://flathub.org/en/apps/xyz.tytanium.DoorKnocker

AppImages have no sandboxing as you said. They also rely on the deprecated SUID-root binary FUSE2. AppImages are bad for security but they are convenient. A malicious AppImage could for example connect to org.freedesktop.secrets and access your keychain, or run a script that places a script called “sudo” in $HOME/.local/share/bin that is preferred over the real sudo and logs a password, or encrypt your files in a ransomware attack, or exfiltrate your session cookies from Firefox or Chromium browsers.

Flatpaks on the other hand are sandboxed. IIRC Flatpaks can’t access other Flaptak’s data folders in $HOME/.var/app (maybe even if home access is given?), but if given access to the “home” permission they can read and write to anywhere else in the user home, so stealing session cookies from a browser or ransomware could still be possible given the right permission. Modern apps that are designed to work as Flatpaks can use the xdg-desktop-portal to access only specific files/dirs upon user request, but it is only temporary access to a file. All the ways a Flatpak can access the system are defined by its permissions, so by giving more/dangerous permissions (such as devices or full filesystem access) a malicious app can possibly escape the sandbox and access arbitrary permissions. The worst permission an app can have is access to session bus for org.freedesktop.Flatpak, which allows it to arbitrary permissions, host command execution, and access to Flatpak configuration.

Maybe a setup FIDO2 LUKS unlocking, but that requires a security key: https://www.privacyguides.org/en/security-keys/