[NotPractical]

I was expecting to see something about how Debian's updates are slow. Instead I learned something about SELinux, which is cool. However, I don't think it's fair to extrapolate from this that Debian is less secure in general. A case has been made here that Debian is less secure for containers and server usage. For desktop users who just want sandboxed applications, I don't think Red Hat's SELinux implementation does much to protect them.

Sidenote: I don't like the implication that community-driven projects are inherently less secure.

> Lack of Resources: Debian as a community-driven project lacks the resources to develop and maintain comprehensive security policies comparable to those provided by Red Hat.

[marcosdumay]

> A case has been made here that Debian is less secure for containers and server usage.

For shared server usage. Most servers are single-use, what makes SELinux mostly useless again.

And on those shared servers, you have to define your actual policies for it to be useful... What a total of 0 people do.

It's hard to completely dismiss the idea that SELinux was a NSA plot to keep userspace capabilities out of reach on consumer OSes.

[ruthmarx]

> It's hard to completely dismiss the idea that SELinux was a NSA plot to keep userspace capabilities out of reach on consumer OSes.

It should be trivial to dismiss given the widespread usage and real world advantages it provides.

And no, a single use server doesn't make SELinux useless. It still means SELinux can lock down whatever services are offered on that box better than pretty much anything else can.

[JackSlateur]

Ha ! Thank you !

Indeed, since the dawn of virtualization and automated deployment, shared servers are a legacy behavior. Well, on Debian's world, at least : for RHEL, you may pay per instance, so there is a financial incentive to share said instances.

Ergo, RHEL and friends are inherently less secure than Debian.

[SubjectToChange]

SELinux still offers a lot of additional protection in the case of RCE. There are literal examples of it working in the wild, e.g.

For several versions of the OS, this worked quite well, but once dual-sim devices2 started coming out, this became more problematic. Furthermore, when SELinux3 became common on Android, this became more problematic since the radio SELinux context that rild started with was too restrictive for the implant to function. - RoidRage Bootstrap Methods (https://wikileaks.org/ciav7p1/cms/page_28049453.html)

[layer8]

Debian security updates aren’t slow. New vulnerabilities usually get fixed on the same day.

[darkr]

https://security-tracker.debian.org/tracker/status/release/s...

[layer8]

If you look at the detail pages, you’ll see that “not yet assigned” doesn’t mean that a fix hasn’t been implemented yet. But you are right that not all CVEs get fixed as quickly as I claimed. However, my experience has been that high-profile ones that surface in tech news usually are.

[regularfry]

> Sidenote: I don't like the implication that community-driven projects are inherently less secure.

I don't like it either, but it may be true anyway. Although I don't think it would be resources so much as focus. The Debian community is not that small.

[pavon]

Yup. I love Debian and use it on all my home computers. I think the author hit it on the head when he described the security as inconsistent. Some maintainers put a great deal of thought into the security implications of the software they are packaging, including contributing to the AppArmour profile. Others ignore it, and others yet are openly opposed to it.

RedHat can declare that everything on the system is going to have SELinux policies following consistent guidelines on what to lock down, and all employees will work with the security team to make this happen. That is harder to do in a community driven project like Debian where ownership and work is widely distributed and entirely voluntary. It can really only happen when the goals are already a strong part of the culture and there is buy-in for specific rules to achieve those goals. For example, Debian's strong free-software requirements have been there from the beginning and so most Debian volunteers are self-selected to agree with or at least tolerate them, and even that has frequent arguments. Security culture is much more mixed, and there are a lot of people in the free software community who think that security starts and ends with fixing bugs when they are found, and push back hard on suggestions that anything more is needed. It is going to take a long time to change that culture.

[rbc]

I prefer Debian as a workstation, though I tend to use FreeBSD for storage (ZFS), and OpenBSD for network edge servers.

[nonrandomstring]

I don't like the implication either. And I agree with you that focus is different. It seems unfair to compare Debian and Redhat this way. One is a "bottom-up" DIY distro where you can start with almost a kernel and basic userspace and build-up. The other is a more mature product targeted at commercial, public facing infrastructure.

The former strongly implies that, if you're using it for the latter case, then you really better know what you're doing. But this capability/competence versus task-fit gets glossed over in the paragraph where the author basically says; because Redhat chose to be a bag of dicks, jumping ship to Debian is the "logical move". It isn't if you don't know what you are doing. And it's sad that RH exited this space leaving a civil cybersecurity hole. The lack of a truly Free and "OOB secure" OS seems the case in point.

There are other reasons to doubt the security of Debian, but "you're using it wrong" isn't the best one to discuss.

[kelnos]

> Sidenote: I don't like the implication that community-driven projects are inherently less secure.

As a heavy open source contributor, I don't like it either. But I'd be kidding myself if I thought volunteers approach all aspects of software development with the same rigor as someone doing it professionally. I'm guilty of that myself; I do the things I find fun, and often don't do the things I find tedious (or have to force myself to do them because I know that future-me will be pissed off at present-me if I don't).

Still, though, there are plenty of for-profit organizations out there that don't feel it's cost-effective to be rigorous about security or some other thing. And many (most?) developers and ops people are evaluated not on how bug-free and secure their work product is, but by how quickly it gets done and shipped to customers.

[perlgeek]

> For desktop users who just want sandboxed applications, I don't think Red Hat's SELinux implementation does much to protect them

Does, like, anything on mainstream Linux distributions really sandbox applications by default? Let's say I run a browser, a mail client, Signal, Discord, whatever on my laptop. If one of them has a code execution vulnerability, does anything prevent that app from reading/writing all of my home directory, take screenshots, send keystrokes to other applications etc?

I haven't used anything but Linux on my laptops and PCs for at least a decade, and I genuinely don't know the answer. Back when I started with Linux, the answer was surely a "no", but maybe anything something has improved in this regard?

[wilsonnb3]

Flatpak apps are sandboxed to some degree, it is pretty common for them to request access to a bunch of locations they don't really need so that the developer doesn't have to make any code changes from the non flatpak version.

I don't know much about the specifics but I think Wayland fixes a lot of the security problems related to keylogging and screenshoting.

[cbarrick]

> > Lack of Resources: Debian as a community-driven project lacks the resources to develop and maintain comprehensive security policies comparable to those provided by Red Hat.

Given that Google uses Debian internally for their workstations [1], employs a number of Debian developers [2], and has discovered and fixed security issues in Debian [3], I find this argument to be entirely disingenuous.

Sure, Red Hat has a well funded security team. But so does Google, and all of the other Debian users in "big tech".

[1]: https://en.wikipedia.org/wiki/GLinux [2]: https://www.reddit.com/r/debian/comments/j4liv4/comment/g7mm... [3]: https://lwn.net/Articles/676809/

[cylo]

I disagree that it's disingenuous. I would love to see Google and other corporations that make use of Debian fund the development of good default AppArmor profiles for many common daemons. Right now they simply don't exist and users are left to fend for themselves.

The point made in the article is that security is hard and often thankless work. So it's not something that's conducive to volunteers doing in their free time often. It does take funding to move the needle on this here, and I think Red Hat is proof of that.