The main problem is that Red Hat is pretty much a proprietary distro. It might not be that technically but that’s pretty much what it is. This of course doesn’t mean that everything that they put out is bad, but personally I’d prefer to not rely on them for anything.
1 Like
@dngray , I’m no expert but is it really not possible to isolate containers from each other with apparmor? You could make a profile for each container and specify it when you launch the container, no?
This is an acid/hot take, but if I have to be honest, there is some truth to it in the workstation realm.
I see the point, and while I appreciate the idea of diversity, there are sometimes things that are better than others.
We don’t use a wrench to hit a nail into the wall; there are better tools for that task.
The main problem is that Red Hat is pretty much a proprietary distro.
I don’t see it that way. In fact, I can’t think of any large-ish organization that has been more supportive of and committed to open source than Red Hat has been.
personally I’d prefer to not rely on them for anything.
It might be possible to avoid Red Hat branded or wholly controlled things, but I think it would be extremely difficult (and not beneficial) to use Linux and avoid Red Hat’s many important contributions to Linux and open source.
As I see it all of us–regardless of the distro we choose–rely on open source software that is to a considerable extent developed, maintained or supported by Red Hat and Red Hat developers (in direct and indirect but important ways).
Some examples include:
- systemd
- selinux
- flatpak
- networkmanager
- kvm (virtualization)
- wayland & x11
- pipewire and pulse audio
- dnf
- rpm
- firewalld
- podman
- fwupd
- many boot components, including widely used secure boot and efi components.
- fedora and its derivatives
- gnome & gtk
- freedesktop standards and projects
- Red Hat is also the second largest contributor to the Linux Kernel (following Intel)
- And some surprises (as of last year, Red Hat was the 3rd largest contributor to Firefox, 5th largest for Webkit)
- Much more
I Love the community/collaborative spirit of Linux, and I often prefer using community distros, but not because I feel that companies like Red Hat or SUSE or Canonical are net negative influences in the Linux space.
On the contrary, many of the nice things we get to enjoy in Linux are made possible in large part because of larger corporate stakeholders willing and able to do much of the heavy lifting, or the boring dry stuff.
10 Likes
Using OpenSUSE which uses CentOS but is unrelated to RedHat can be a good solution.
OpenSUSE does not use CentOS to my knowledge.
5 Likes
My tldr is that CentOS Stream gets more frequent updates and is closer to rolling updates. Old CentOS was more like Debian - super focused on reliability and stability. The two are not interchangeable, especially for servers. For desktop usage, just use Fedora.
Note: I’ve used Rocky Linux as a Cent OS replacement server side and is solid.
2 Likes
Simplest answer is that Debian is quite novice friendly distro. Fact is that quite a number of packages in its repos are simply outdated/has not been updated for long time. But again, total newbie dont care about it.
1 Like
So why can it run .rpm packages ?
If Debian is a novice-friendly distribution, then the year of the Linux desktop is very far away.
3 Likes
Desktop variant I mean…
Im well aware that server variants are far away from being novice-friendly, but no novice should even come close to server(s) imo. Master desktop first, than try server.
I understood what you meant, but my answer is still the same as above.
Many distros use the rpm package format. [wikipedia Ref]
But that does not make that distro derive from Red Hat or related.
6 Likes
Spirallinux is doing the magic
This seems to be conflating intended privacy practices with security risks - one could imagine an “unhackable” system that cannot be compromised by a third-party actor, but that sends a livestream of its users’ webcam feed and keystrokes to its headquarters. High security, zero privacy.
It would seem you’re applying a standard for “anywhere near secure” that would involve a threat model of “nation states are specifically and actively trying to attack me”, not an average person who wants to protect their personal data. That doesn’t invalidate the former, but I think it’s a distinction worth making when talking about recommendations to make to the general public vs. those in very specific situations.
2 Likes
Interesting read as a Debian user.
Re: apparmor, I had already gone the extra mile and installed additional profiles from the Debian repo, enabling them all (and putting 3-4 back in complain/disabled mode when a few things broke). With that said, apparmor is kind of a shit show admittedly. Potemkin village vibes too as a sizeable chunk of the profiles are (literal/marginally better than) placeholders.
After reading the article, I also see the default docker profile as too porous, yet hidden away, which prevents easy editing.
I am still unconvinced re: moving away from Debian, but I am motivated to switch to podman in the near future as a result of the article:
- Unlike the rest of my software installs (Flatpak/official Debian Repo/GrapheneOS/OpenWrt) using Docker is basically installing unvetted apps w/ the heavy dependence on containerization preventing most/all issues.
- All things being equal, podman is rootless which limits its scope if it were to break out of containment
- But instead of leaving it at that, I can leverage the tighter Linux integration and harden podman further w/ systemd
- Docker runs on my server which has the most data if it encounters a zero-day
- podman is more FOSS-friendly than Docker
1 Like
containers are not an adequate security boundary since they all share your host kernel
not really
please consider using gVisor or putting different categories of containers into their own VMs
Or you can use SELinux on Debian.
Can you help me understand. My thought process is:
- Containers limit external software’s scope
- podman also removes root privilege so if something escapes the container/attempt a kernel exploit, they cannot run as root w/o privilege escalation.
Docker Risk = Odds of breaking out of container
podman Risk = Odds of breaking out of container x odds of privilege escalation
Is there clear risk that I’m overlooking/undervaluing? I cannot tell if my thought process is short-sighted or if your feedback is akin to telling someone that their airgapped setup is insufficient because it doesn’t have titanium-reinforced doors.
It feels like we might be drifting into diminishing returns but curious to know more.
if something has a working kernel exploit via the available/exposed syscalls, it is effectively game over
using podman/crun doesn’t help there.
again you need to use something like gVisor or Kata to truly isolate containers from your host kernel.
for many simple/basic services, it is a one-liner to switch to gVisor without any extra work
Those runtimes are absolutely not diminishing returns and should honestly be the bare minimum.
2 Likes