18 ms·

The Insecurity of Debian

248 points by cylo 2y ago

NotPractical 2y ago
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.
- regularfry 2y ago
  > 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 2y ago
    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 2y ago
      I prefer Debian as a workstation, though I tend to use FreeBSD for storage (ZFS), and OpenBSD for network edge servers.
  - nonrandomstring 2y ago
    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.
- layer8 2y ago
  Debian security updates aren’t slow. New vulnerabilities usually get fixed on the same day.
  - darkr 2y ago
    https://security-tracker.debian.org/tracker/status/release/stable https://security-tracker.debian.org/tracker/status/release/s...
    - layer8 2y ago
      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.
- marcosdumay 2y ago
  > 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.
  - JackSlateur 2y ago
    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 2y ago
      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 https://wikileaks.org/ciav7p1/cms/page_28049453.html)
  - ruthmarx 2y ago
    > 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.
- kelnos 2y ago
  > 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 2y ago
  > 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 2y ago
    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 2y ago
  > > 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 https://en.wikipedia.org/wiki/GLinux [2]: https://www.reddit.com/r/debian/comments/j4liv4/comment/g7mmav4/ https://www.reddit.com/r/debian/comments/j4liv4/comment/g7mm... [3]: https://lwn.net/Articles/676809/ https://lwn.net/Articles/676809/
  - cylo 2y ago
    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.
semiquaver 2y ago
FWIW, I’ve worked at many RedHat shops over the years and I’ve never seen one where disabling SELinux wasn’t a normal part of provisioning a server. I haven’t seen the same thing with AppArmor (although I admit I have less visibility into debian systems administration). YMMV but it seems to me that a component which is so inconvenient that it’s normally disabled doesn’t provide much security in the end.
- giancarlostoro 2y ago
  This reminds me of my college years and the one time we used Fedora and someone accidentally set it up with SELinux, we spent hours pulling our hairs out trying to figure out why nothing worked. Only to finally realize SELinux was the culprit and we needed to turn it off.
  - mhitza 2y ago
    SELinux has been enabled on Fedora for as long as I remember. SELinux is complex, badly documented, policy code is obscure macro incantation, and basic debugging tools often aren't installed out of the box on server distros (such as audit2allow). But for the day to day administration of systems, policies are included for distribution packages and most issues can be fixed by enabling a boolean here and there, and relabeling files. The principles, basic admin & debugging part can be learned in a couple of hours, and when you have custom service software, you can throw it in /opt and have it run unconfined (ie: not subject to SELinux rules).
    - XorNot 2y ago
      It's baffling to me that SELinux's UI is like...the best we can apparently do? The underlying concepts of SELinux aren't so hard but trying to manage it in any sort of coherent way is a nightmare - up to and including the provisions in it for a network based policy server component which just never appeared. And it sucks! In theory it does so many things we really really want, and should do more. Like I as a user have a great interest in ensuring my home directory files follow sensible markings based on their content - my SSH keys, AWS keys, or banking files all exist in different logical zones of control. And this is a concept SELinux can handle...but the tools are just so bad at surfacing it.
superkuh 2y ago
Debian is a desktop operating system for human persons who are responsible for their computers. Red Hat is a enterprise operating system for corporate persons where the human persons using their computers are not responsible or in control of their computers. It's apples and oranges. These aren't "attack surfaces left exposed" this is "users allowed to control their own computer and decide for themselves". And I notice the vast majority of this complaint about insecurity is not about running applications on Debian or RHEL, but instead about the systems built up for running things containerized and trying to mitigate all the problems that causes. Debian concentrates more on actually having an OS you can run applications on rather than a system for deploying containers. >In the end, the choice between Debian and Red Hat isn’t just about corporate influence versus community-driven development. It’s also a choice between a system that assumes the best and one that prepares for the worst. Unfortunately in today’s highly connected world, pessimism is a necessity. In the end it's about weather you think you should control your computer or weather someone else will control your computer. Pick appropriately for context.
- logifail 2y ago
  > Debian is a desktop operating system for human persons who are responsible for their computers Debian is many other things as well!
- dspillett 2y ago
  > Debian is a desktop operating system I suspect Debian is used on more server installs than desktop ones. While it doesn't come with enterprise support options like RedHat it is most certainly used on servers, many of which are in corporate environments and are running multiple services (in containers often) or are otherwise multi-user.
  - p4bl0 2y ago
    That may be true for Debian itself (although I know a lot of people who have been running it for years as their daily system and still are to this day, including myself for 15+ years and counting), but Debian is also the base for many other distributions, including Ubuntu and its derivatives (like Mint), which are mostly used on desktops rather than servers.
osamagirl69 2y ago
To be honest the never ending headache of getting things to work with SELinux under RHEL was a big driver for why I moved to debian. Certainly SELinux has its place but I never found the value it offers to be worth the complexity it adds.
- nicce 2y ago
  The same reason why many people choose WhatsApp, Telegram, Slack, Discord over things like Signal or Matrix. They are just easier to use. It is about priorities. Maybe some day we solve the usability problems.
  - p4bl0 2y ago
    I get it for Matrix, but Signal really has had the same user experience as WhatsApp for years now. But anyway, your point still stands. That's why user-friendliness is an important part of security (and why Signal work is so important regarding secure messaging apps).
    - dpassens 2y ago
      At most a little over one year ago, I installed Signal Desktop to open a link in a message I had received on my desktop. This is, apparently, deliberately unsupported, since the app claims that "[f]or your security, chat history isn't transferred to new linked devices". So no, the user experience of WhatsApp is miles ahead of Signal, at least if you want to use a real computer.
      - deleted 2y ago
        [deleted]
    - okanat 2y ago
      I think it is still impossible to backup one's own messages in Signal and then retrieve them back in another phone. It was possible on Android via root but basically impossible for unrooted phones which is a dealbreaker for Apple devices my friends and family use. Signal has to provide 100% of the features and convenience of Whatsapp and some more without compromising security for it to be a viable alternative.
gwynforthewyn 2y ago
I fell in love with this article at this sentence: > Still. Many in the open source community have interpreted Red Hat’s decision for what it really was: A dick move. I've had a short essay in draft for a while about the difficulty of a small business trying to make money using The Red Hat Model (https://opencoreventures.com/blog/2023-04-red-hat-model-only-worked-red-hat/ https://opencoreventures.com/blog/2023-04-red-hat-model-only...). Red Hat seem like an outlier who're doing well with that model, but smaller places like Sidero or Bitfield had to find other ways to monetise their open source efforts, and sometimes that had pushback from the community. Red Hat, though, were acquired by IBM, and IBM made it harder for an otherwise thriving ecosystem to exist. Not impossible, but harder. IBM makes money hand over fist (billions according to https://www.ibm.com/annualreport/ https://www.ibm.com/annualreport/). Was there really a reason to make Red Hat harder to redistribute? The interviews I've read come down to "our Red Hat team works hard and we don't want to give that away to low effort projects", though if you've got an interview with a different perspective I'd love to read it.
- ahoka 2y ago
  The Red Hat model is basically “Embrace, extend, and extinguish”.
  - rurban 2y ago
    The Red Hat model is rather to be the professional distro, made by professionals. Ubuntu and Debian are for hobbiests and lawyers, and you should never run a public server on debian/Ubuntu if you care about security.
    - _factor 2y ago
      I’m pretty sure the Red Hat model is to profit off the community efforts while creating convoluted complications in the name of security so they can send their high paid consultants to your business and get paid even more. Was it professional when they let SSH vulnerabilities exist in RHEL7 forcing perfectly useable machines to upgrade to 8 for remediation? Don’t get me wrong, they’re the new “nobody got fired for” company (technically still the same). That doesn’t imply Debian and Ubuntu are less secure except in name. Go to Google cloud and see what CIS hardened images exist. Your perspective is an oversimplification if not completely wrong.
zelon88 2y ago
> 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. And Linux in general has less resources to develop and maintain comprehensive security policies comparable to those provided by Microsoft. Yet here we are, with Microsoft products so "secure" that they're insecure unless you have a PHd in b****, being so convoluted and over-built that people have to migrate away from it just to recover the actual security they used to enjoy back when they were able to wrap their head around the whole stack. If devs want things to be more secure, stop developing more acronyms and just educate the userbase on the acronyms they already have.
- Andrex 2y ago
  After letting Russians waltz into their C-level emails (as well as those of US gov't 365 users) and steal Windows source code using basic password spraying for over six months before patching the hole, "Microsoft" and "secure" shouldn't be in the same sentence ever again. https://arstechnica.com/security/2024/01/microsoft-network-breached-through-password-spraying-by-russian-state-hackers/ https://arstechnica.com/security/2024/01/microsoft-network-b... Wasn't caught for two months and wasn't fixed until months after. How is Microsoft allowed anywhere *near* the bidding process for gov contracts anymore?
crdrost 2y ago
This is a surprising article because I kind of see this in light of the old Linux/BSD wars? “Red Hat owned making this policy apply to most of the popular software they distribute. On Debian the users have to set everything up.” — this sentiment is directly parallel to how BSDs see themselves as providing a whole consistent operating system, Linux meanwhile just wants to ship a kernel. “Debian doesn't care enough about security.” — says everyone who runs OpenBSD. “With SELinux policies, containers are isolated from the system.” — you could almost say they are “in jail,” maybe we could package this up as a syscall, hm, but what to call it... IDK what BSD looks like in 2024, but in ~2004 you would have seen this exact same article about Debian, but comparing to FreeBSD instead of RHEL.
- tuna74 2y ago
  "On Debian the users have to set everything up.” — this sentiment is directly parallel to how BSDs see themselves as providing a whole consistent operating system, Linux meanwhile just wants to ship a kernel." Linux is just an OS kernel. If you want a consistent OS, use RHEL, Ubuntu, Fedora, Android or something else.
fleventynine 2y ago
With the sheer volume of local exploits found in the Linux kernel, I don't really consider these SELinux/AppArmor mitigations to be that useful. Sure, they reduce the attack surface a bit, but if I actually need isolation between workloads, it's best to do it below the kernel (with a VM). If an attacker gets execution in userspace, it's best to assume they can also get into the kernel via some 0-day local privilege escalation...
- NewJazz 2y ago
  seccomp at least restricts access to certain kernel APIs. Although it is quite brittle.
theossuary 2y ago
I came in expecting not to, but I completely agree with this article. I moved off RHEL after using CentOS exclusively for a decade because of the changes in 2023. I loved SELinux, it's a technology you need to sink your teeth into if you want to understand it, but it has decent tooling (like audit2why) and isn't too hard to modify to get working if needed (SELinux booleans are a powerful way to modify base policies without having to recompile). I do a lot in Kubernetes, and there's been more than one CVE with a line like "Affects all versions of docker/containerd, unless running SELinux," which gave me a lot of reassurance that the effort put into making SELinux work was worth it. Now that I'm on Debian, I'm slowly building a new set of policies for the OS. Thankfully SELinux has an excellent reference policy[1] to base off of. I'm hoping my new debian base images for my homelab & elsewhere will have a nice restrictive default SELinux policy by the end of the year. I hope there's more community effort here as well, SELinux really can't compare to AppArmor, and is absolutely necessary for proper security. Honestly I'd love if the wider community took another stab at replacing SELinux with a KSM that had similar functionality but better tooling and design. I'd pick it up in a heartbeat, but right now SELinux is what we have. [1]: https://selinuxproject.org/page/NB_RefPolicy https://selinuxproject.org/page/NB_RefPolicy
- turtle_heck 2y ago
  I agree SELinux is awesome. SELinux can be frustrating without the proper background about what it is, how it works, and how it helps you. There is a surprising amount of tooling for it actually.
- NewJazz 2y ago
  I do a lot in Kubernetes, and there's been more than one CVE with a line like "Affects all versions of docker/containerd, unless running SELinux," which gave me a lot of reassurance that the effort put into making SELinux work was worth it. I've seen this too, but I usually see AA mentioned in the same situations as an equivalent mitigation to SELinux.
  - theossuary 2y ago
    I can't say I've seen the same, so I dug into it. There's a good list from RedHat[1] on CVEs SELinux mitigated. I went through them: - CVE-2016-9962 - Bypasses Apparmor [2], mitigated by SELinux - CVE-2022-0492 - Apparmor and Seccomp also protect against - CVE-2019-5736 - Mixed, blocked by the default SELinux policy in RHEL (not Fedora), not blocked by the default AppArmor policy[3] - CVE-2021-3156 - This one is not a good one for RedHat to put on the list. SELinux by default doesn't protect against it, Debian 10 at the time had a Linux security feature enabled (fs.protected_symlinks) that helped mitigate it, and additionally CVE-2021-23240 came out which had similar effects but only occurred on SELinux systems. - CVE-2019-9213 - Not mitigated by AppArmor, mitigated by SELinux - CVE-2019-13272 - Not mitigated by AppArmor, not mitigated by default SELinux policy, but easy to mitigate by enabling boolean. I'd consider this a win for SELinux, but only just. While digging into this more, I came across this BlackHat talk[4] which really quantifies how SELinux improves security (though doesn't contrast it with AppArmor). I also came across a paper on usability of SELinux and AppArmor[5] which brings up an interesting point: If the tool is too complex, even if it's more powerful, more often than not it won't end up having better results. That's all to say, I think if you're willing to invest a lot of time into it (say you want to make security your niche in your development career), SELinux is still the best. But I can see why many may gravitate towards AppArmor so as to not make perfect the enemy of good. That said, I still wish Debian had a choice between the two, right now SELinux isn't really doable without a lot of work. [1]: https://access.redhat.com/solutions/7032454 https://access.redhat.com/solutions/7032454 [2]: https://github.com/opencontainers/runc/issues/2128 https://github.com/opencontainers/runc/issues/2128 [3]: https://www.cloudfoundry.org/blog/cve-2019-5736/ https://www.cloudfoundry.org/blog/cve-2019-5736/ [4]: https://www.youtube.com/watch?v=EkL1sDMXRVk https://www.youtube.com/watch?v=EkL1sDMXRVk [5]: https://researchportal.murdoch.edu.au/esploro/outputs/journalArticle/Empowering-end-users-to-confine-their/991005540115207891#file-0 https://researchportal.murdoch.edu.au/esploro/outputs/journa...
bawolff 2y ago
Be interesting to know if anyone had any numbers on actual security issues in practise. Complexity is generally really bad for security. It results in people working around the system or just turning it off. Security is not just "in theory" - a perfectly secure system that most users disable is an insecure system. It reminds me a bit of the idea of making people change their password every month. Sure, in theory it reduces time a compromised credential can be abused for. In practise though it means nobody can remember their password, people start using really poor passwords and writing them down on post it notes. The net result is much worse security practically speaking, even if its better theoretically.
Mikhail_K 2y ago
[flagged]
- mmh0000 2y ago
  I really don't get this hatred of systemd. Systemd solves many programs that have plagued Linux forever. Sure, SysV-init was super simple, and it was great back in the 1980s or even the 1990s when your server ran just a handful of daemons. But systems get more complex and featureful over the years. In the year 2024, my standard Fedora Linux desktop, has 73 daemons running in the background... Dealing with sysv single-threaded and start-and-forget architecture is not great on modern systems. You might say, well, why not Upstart!? Well. Upstart added a lot of complexity to the init process, while adding very little overall benefit. Systemd added a lot of complexity, no doubt about that. But, it also added a TON of features that reduced complexity elsewhere on the system. I mean, just to rattle a few things off: * systemctl. Holy fuck! A SINGLE command, that works across all modern Linux to control system services. I do not miss the days of service, chkconfig, /etc/init.d/xxx start, update-rc.d, insserv, rc-update, rcconf, sysv-rc-conf, ntsysv. And every distribution having their own special init scripts that worked in a very specific way to that distro. A great example of this is RHEL5's sshd sysv init script, a 500!!! line shell script to start the ssh daemon... Compared to RHEL9's sshd 24 line systemd unit file. * cron - scheduled tasks being handled by a screwball 3rd party service that had no built-in method of ensuring a cronjob would be retried in the event of a failure... systemd timers fixed that nonsense. * at - see above * autofs - Here's a lovely service that is stupidly complex. Whenever I have to setup autofs I get the feeling that the developers purposefully asked themselves "what can we do to make our application hard to configure?" then, once they had an answer to that question, they went back to the drawing board and asked, "Okay, configuring autofs is hard, but, what can we do to make it even more obtuse?". systemd automounts are drop-dead simple, a 5 line unit file saying what to mount and on what condition. * Parallelization and dependencies - Systemd can start services in parallel and only after their dependencies are ready, unlike SysV’s linear approach. This isn't just for faster boot times; it's also about reliability. Ever had a service fail because another wasn’t ready? Systemd handles that for you. * systemd has overall good built-in security! All services are started in their own cgroup and with posix capabilities and r/w access to the filesystem easily restrictable. You claim systemd is a "badly written multifunction blob" but that's mostly not true, look at `/usr/lib/systemd/systemd-*` and `/usr/bin/systemd-*`. Systemd is split out into multiple purpose-specific executables in almost every place where it makes sense to do it. I could go on all day, but I'll stop here. I agree that the system isn't perfect, and they've made some choices I disagree with. But overall, systemd is a MASSIVE improvement over everything that came before it.
JohnFen 2y ago
Wait, the author is criticizing Debian for not having as heavy-handed a system as SELinux enabled out of the box? That thing that causes so much pain that everyone disables it immediately unless they have fairly extreme security needs?
- commandersaki 2y ago
  Never heard of anyone suggesting to disable AppArmor. As for the efficacy of the two, I'm less interested in the feature sets of the two. I think what'd be more interesting is replicate exploitation scenarios with their default policies and see which subsystem succeeds in mitigating the exploit and which fail.
  - mrweasel 2y ago
    Can't say that I haven't disabled AppArmor on a server or two to make things work short term. Fixing the AppArmor is a bit easier than fixing SELinux policies though.
  - silverwind 2y ago
    Had to disable AppArmor to be able to dump packets with tools like tcpdump.
  - ruthmarx 2y ago
    > I'm less interested in the feature sets of the two. I think what'd be more interesting is replicate exploitation scenarios with their default policies and see which subsystem succeeds in mitigating the exploit and which fail. The feature set is exactly what dictates which systems are more likely to prevent exploitation, though. App Armor simply isn't as granular, and simpler to bypass (e.g. by making a hardlink to a file to override AppArmor policy). AppArmor may be good enough in many situations, but SELinux gives you much more control, so you can be much closer to perfect to protect against unknown situations.
    - commandersaki 2y ago
      Still don't care about the feature set, show me a useful benchmark. If SELinux prevents a hypothetical that's great, but security is a tradeoff and I'd opt for convenience and simplicity to sacrifice potentially negligible risk. For example, I'm seeing that SELinux didn't mitigate ShellShock where AppArmor did (despite being an attack vector that isn't really common). But these are the things I want to know.
ok123456 2y ago
I've seen poorly implemented SELinux policies make a workstation unusable and fill up /var with audit.logs that are tens of gigs. You have to do 100% coverage testing on whatever program you're using. (Good luck if you don't have the source code.) Otherwise, you don't have any guarantee that your program won't seemingly be killed randomly. Good luck, x2, if you have some snake oil "endpoint security" that keeps overriding your SELinux policy changes.
dsr_ 2y ago
> Containers are increasingly the preferred method for developers to deploy their software – myself included. A common misconception is that if you run something in a container, it’s inherently secure. This is absolutely not true. Containers by themselves do not solve a security problem. They solve a software distribution problem. They give a false impression of security to those that run them. To the extent that containers are a software distribution method outside of a single authority, they are a security nightmare. They are the exact equivalent of shipping a developer's laptop off to the datacenter and replicating it as a production image.
- lolinder 2y ago
  > They are the exact equivalent of shipping a developer's laptop off to the datacenter and replicating it as a production image. If you're building your containers on a developer laptop and then pushing them to the registry from there, yes. You can also not do that and instead have all builds happen on a CI server that isn't ever touched directly by anyone, like you should really be doing to build any artifact that gets deployed to production, container or otherwise.
  - dsr_ 2y ago
    Read the proviso again, please: this is a criticism of receiving containers from an outside source, not using them to distribute your own images.
    - lolinder 2y ago
      The proviso could have been read either way, and your claim that it's an exact equivalent of shipping off a developer laptop makes no sense if what you meant was "you're downloading untrusted code from strangers". I read it first the way you apparently meant it but chose to respond to the meaning that made your second sentence make sense rather than the one that made it a non sequitur. Using images from untrusted sources is a not-quite-exact equivalent of downloading code directly from npm and shipping it off to production.
- bornfreddy 2y ago
transpute 2y ago
SELinux Coloring Book PDF, https://developers.redhat.com/e-books/selinux-coloring-book https://developers.redhat.com/e-books/selinux-coloring-book & https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf https://people.redhat.com/duffy/selinux/selinux-coloring-boo... > Learn the basics of SELinux, including type enforcement, Multi-Category Security (MCS) Enforcement, and Multi-Level Security (MLS) Enforcement, with the help of some friendly cats and dogs!
- vfclists 2y ago
  Seriously? Do I see what looks like the Penguin dogging the Dog on page 7?
  - transpute 2y ago
    The book has a few cartoon images, some are repeated. There is explanatory security text for each image. Image semantics can be derived from text semantics.
  - 3np 2y ago
    I guess you see what you want to see
- pvaldes 2y ago
  Selinux coloring book never really explains how to start doing anything useful with the program
Anthony-G 2y ago
Excellent article. The key take-away for me is: > The ugly truth is that security is hard. It’s tedious. Unpleasant. And requires a lot of work to get right. I use Red Hat-based distributions at work and Debian/Ubuntu in my personal life. A few years ago, I bit the bullet and learned enough of SELinux to run my workstation and all my servers in enforcing mode. The author of this article is right to credit Red Hat for all the work they’ve done to provide users with default SELinux policies that work out of the box. At one time, I considered installing SELinux on my Debian system and modifying Red Hat’s policies to work with the Debian packages. I realised how much work would be involved so I chose the path of least resistance: AppArmor (which does the job).
- deleted 2y ago
  [deleted]
okasaki 2y ago
I hear a lot about podman online, but I've never seen anyone using seen.
throw7 2y ago
I disabled selinux after learning about dontaudit rules and having them waste my time. That's not to say on very specific systems that need to be hardened, I do enable selinux and am glad it's an option. And if I have to use a security layer, I take the object based selinux over the path based apparmor.
renewiltord 2y ago
Never used this. All my wealth is still mine. No one stole it. Two decades of Linux on the desktop. Some almost always on. If risk is lower than 1/2decades it's not worth learning. Insecure debian it is.
- kelnos 2y ago
  The article is concerned about server security, not desktop security.
txutxu 2y ago
Debian can run with SELinux if you like that. Debian uses AppArmor by default, probably because of the Canonical influence (there are more Debian developers and maintainers paid by Canonical than by RedHat). But you can run Debian with SELinux (as well as with other LSMs, MACs, etc like Tomoyo). At my last jobs, we disabled any of SELinux, AppArmor and Auditd on Debian/Ubuntu, just for the sake of performance. And we never detected any security issue for our usage and requirements. So I'm not an expert in this field. Not sure what the purpose of the article, or the whole blog, is. You want to influence the choosing of Debian Vs RHEL Vs Oracle Linux in some place? As I'm not sure, will stop here.
- wakawaka28 2y ago
  It reads like either an ad for Red Hat or an add for SELinux which this guy is probably familiar with (unlike most Linux users and professionals).
Brian_K_White 2y ago
Meanwhile everyone agreed that the convenience of magic integration with browsers and other things was more critical than security, in the default config, for a password manager of all things, when debian changed the default keepassxc package to omit optional added attack surface plugins. Not unavailable, just not installed by the default. I wonder how many people that agree with this nonsense position also agreed with the keepassxc nonsense position.
steeeeeve 2y ago
1. You can enable SELinux on debian if you want to. 2. I've never had a conversation with anyone who is enthusiastic about SELinux. 3. I've never run into someone who was good at explaining SELinux policies, how to create them, update them, or explain their decision process other than "well... the app seems to need to do x, so we should let it." 4. I have run into plenty of people that disable SELinux out of the gate to avoid the headache of it. 5. I have run into plenty of people that avoid Redhat distros. This is akin to someone writing an article about how Oracle and Microsoft got databases wrong because they didn't embrace some security feature that only DB2 has and that more than half of DB2 users out there think is a giant pain in the neck.
rmholt 2y ago
Would generation of SELinux policies be a good use case for LLMs? "Generate a SELinux policy for daemon X. This daemon accesses it's config file in /etc and it's runtime data in /var/x. It listens on network. All other activities should be disabled"
- layer8 2y ago
  Only if you’re knowledgeable enough to double-check the resulting configuration and correct any mistakes or omissions.
- kelnos 2y ago
  While I agree the syntax of the policy is a big part of the difficulty, I think it's equally difficult for many apps/services to find out what activities it needs.
h4ck_th3_pl4n3t 2y ago
I think that both AppArmor and SELinux are unusable in practice due to lack of better tools for generating those configurations. There needs to be better graphical tools for this, like a "profiler" or similar that watches a process for a specific time for errors in the config and that incrementally adds features while the process is running. In my opinion, systemd sandboxes are where it's at. [1] They are seccomp based sandboxes, but have a lot of isolation and sandboxing features that are very easy to use, and they can also be incrementally enhanced with both SELinux and AppArmor profiles. [1] "man systemd.exec" or https://manpages.ubuntu.com/manpages/bionic/man5/systemd.exec.5.html https://manpages.ubuntu.com/manpages/bionic/man5/systemd.exe...
- NewJazz 2y ago
  AA at least has what you are describing. https://man.archlinux.org/man/aa-genprof.8 https://man.archlinux.org/man/aa-genprof.8
- nobody42 2y ago
  I'm trying to solve the lack of tools for AppArmor profile composition: https://github.com/nobody43/apparmor-suggest https://github.com/nobody43/apparmor-suggest
turtle_heck 2y ago
Relevant: https://stopdisablingselinux.com/ https://stopdisablingselinux.com/
fsflover 2y ago
If you care about security, consider the security-oriented Qubes OS relying on hardware virtualization and running everything in Debian and/or Fedora VMs: https://qubes-os.org https://qubes-os.org. My daily driver, can't recommend it enough.
Arnavion 2y ago
For systemd services, there's also the option to use the service unit directives that systemd provides to limit caps (CapabilityBoundingSet, NoNewPrivileges, etc), filesystem access (ProtectSystem, ReadWritePaths, etc), other "system" access (ProtectProc, PrivateUsers, RestrictNamespaces, etc) and syscalls (SystemCallFilter). I find these an easier and more direct way to harden than writing apparmor / selinux profiles. `systemd-analyze security <service unit name>` gives a nice list of things to consider tweaking. You don't have to fix everything or pay attention to the exposure ratings, just use it as a guide. I did this for chrony, haproxy, nginx, tor and unbound on my Debian router. I also have some timer units to run scripts to update DNS blocklists and such, which have the same kind of hardening. For the services, some of them have caveats and can't be fully hardened, eg unbound needs PrivateUsers=no because it fails if it can't find an unbound:unbound user to switch to, even if it was already started as unbound:unbound by systemd. And SystemCallFilter makes it easy to get overzealous and only allow the exact set of syscalls that you see the service making, only to have a service update or glibc update that starts making a new syscall and requires another round of debugging, so do it in moderation :)
vfclists 2y ago
SE Linux - A tool conceived by the NSA to discourage users from hardening their systems.
- deleted 2y ago
  [deleted]
sirjaz 2y ago
This is one place windows does have things set right with ntfs acls
- wongogue 2y ago
  But that kills filesystem performance.
- kelnos 2y ago
  Filesystem ACLs are part of the puzzle, certainly, but are insufficient if they're the only mechanism.
kkfx 2y ago
Honestly? SELinux is a nice idea, practically obscene, like many others, Solaris RBAC a "so important security feature" essentially no one use for real to name another. Today most security breaches came from crappy applications with an immense set of dependency put into production because someone want them, there is no protection for them, adding long and painful system stuff is only a way to have also badly configured systems. Debian issues are more in a complex custom setup, preseed it's a nightmare compared to NixOS, which is much more important than SELinux, regularly disable on most deploys.
theteapot 2y ago
I'm way more worried about how a compromised xz-utils made it past the package maintainer and into the Debian repos. Mitigating supply chain attack vectors like this seem like the bigger priority by far and low hanging fruit. I don't follow Debian leadership but haven't come across any reaction or policy change to address this from them?
goodpoint 2y ago
SELinux is Mandatory Access Control system. MAC is not that useful for most servers: The real risk comes from network-facing services and they are much better protected by seccomp and cgroups, usually configured in systemd, and Debian uses that extensively. Seccomp can even protect vulnerable system calls. SELinux is not able to do that.
ruthmarx 2y ago
I wonder if this article title is a deliberate reference to 'The Insecurity of OpenBSD' article which also addressed a lack of SELinux or similar systems.
sunshine-o 2y ago
Not only Debian, the lack of SELinux is one of my main concern with NixOS
hsbauauvhabzb 2y ago
RHEL doesn’t have any indication as to how the contrib repositories work. SELinux might be nice, but it won’t have any impact if I install a malicious package. And yes, I need contrib as I need the ability to use graphical drivers and play proprietary formats.
brvier 2y ago
Haha first step of most Redhat user : shutoff selinux. RedHat have such bad moves, deploying unfinished, instable and unsecure softwares.
MarkusWandel 2y ago
For my personal machines, I have an early install script that turns SELinux off and makes the system boot with mitigations=off. Personal machine, behind my own firewall etc. I'd hate to be a system administrator, and despite my existing habits, this article convinces me that, if I was, I would try to actually understand SELinux.
4oo4 2y ago
The discussion of container security is completely lacking any mention of userns remapping, which is an excellent container security feature that's extremely easy to enable and use compared with AppArmor/SELinux (and would work extremely well in parallel with them). That way if someone does manage to break out of a container they have the privileges of a dummy user that doesn't exist on the host, so unless they are using a kernel exploit, they don't have any privileges to be able to do any damage. https://docs.docker.com/engine/security/userns-remap/ https://docs.docker.com/engine/security/userns-remap/

248 points by cylo 2y ago

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.

regularfry 2y ago
> 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 2y ago
  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 2y ago
    I prefer Debian as a workstation, though I tend to use FreeBSD for storage (ZFS), and OpenBSD for network edge servers.
- nonrandomstring 2y ago
  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.
layer8 2y ago
Debian security updates aren’t slow. New vulnerabilities usually get fixed on the same day.
- darkr 2y ago
  https://security-tracker.debian.org/tracker/status/release/stable https://security-tracker.debian.org/tracker/status/release/s...
  - layer8 2y ago
    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.
marcosdumay 2y ago
> 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.
- JackSlateur 2y ago
  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 2y ago
    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 https://wikileaks.org/ciav7p1/cms/page_28049453.html)
- ruthmarx 2y ago
  > 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.
kelnos 2y ago
> 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 2y ago
> 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 2y ago
  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 2y ago
> > 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 https://en.wikipedia.org/wiki/GLinux [2]: https://www.reddit.com/r/debian/comments/j4liv4/comment/g7mmav4/ https://www.reddit.com/r/debian/comments/j4liv4/comment/g7mm... [3]: https://lwn.net/Articles/676809/ https://lwn.net/Articles/676809/
- cylo 2y ago
  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.

semiquaver 2y ago

FWIW, I’ve worked at many RedHat shops over the years and I’ve never seen one where disabling SELinux wasn’t a normal part of provisioning a server. I haven’t seen the same thing with AppArmor (although I admit I have less visibility into debian systems administration). YMMV but it seems to me that a component which is so inconvenient that it’s normally disabled doesn’t provide much security in the end.

giancarlostoro 2y ago
This reminds me of my college years and the one time we used Fedora and someone accidentally set it up with SELinux, we spent hours pulling our hairs out trying to figure out why nothing worked. Only to finally realize SELinux was the culprit and we needed to turn it off.
- mhitza 2y ago
  SELinux has been enabled on Fedora for as long as I remember. SELinux is complex, badly documented, policy code is obscure macro incantation, and basic debugging tools often aren't installed out of the box on server distros (such as audit2allow). But for the day to day administration of systems, policies are included for distribution packages and most issues can be fixed by enabling a boolean here and there, and relabeling files. The principles, basic admin & debugging part can be learned in a couple of hours, and when you have custom service software, you can throw it in /opt and have it run unconfined (ie: not subject to SELinux rules).
  - XorNot 2y ago
    It's baffling to me that SELinux's UI is like...the best we can apparently do? The underlying concepts of SELinux aren't so hard but trying to manage it in any sort of coherent way is a nightmare - up to and including the provisions in it for a network based policy server component which just never appeared. And it sucks! In theory it does so many things we really really want, and should do more. Like I as a user have a great interest in ensuring my home directory files follow sensible markings based on their content - my SSH keys, AWS keys, or banking files all exist in different logical zones of control. And this is a concept SELinux can handle...but the tools are just so bad at surfacing it.

superkuh 2y ago

Debian is a desktop operating system for human persons who are responsible for their computers. Red Hat is a enterprise operating system for corporate persons where the human persons using their computers are not responsible or in control of their computers. It's apples and oranges. These aren't "attack surfaces left exposed" this is "users allowed to control their own computer and decide for themselves". And I notice the vast majority of this complaint about insecurity is not about running applications on Debian or RHEL, but instead about the systems built up for running things containerized and trying to mitigate all the problems that causes. Debian concentrates more on actually having an OS you can run applications on rather than a system for deploying containers. >In the end, the choice between Debian and Red Hat isn’t just about corporate influence versus community-driven development. It’s also a choice between a system that assumes the best and one that prepares for the worst. Unfortunately in today’s highly connected world, pessimism is a necessity. In the end it's about weather you think you should control your computer or weather someone else will control your computer. Pick appropriately for context.

logifail 2y ago
> Debian is a desktop operating system for human persons who are responsible for their computers Debian is many other things as well!
dspillett 2y ago
> Debian is a desktop operating system I suspect Debian is used on more server installs than desktop ones. While it doesn't come with enterprise support options like RedHat it is most certainly used on servers, many of which are in corporate environments and are running multiple services (in containers often) or are otherwise multi-user.
- p4bl0 2y ago
  That may be true for Debian itself (although I know a lot of people who have been running it for years as their daily system and still are to this day, including myself for 15+ years and counting), but Debian is also the base for many other distributions, including Ubuntu and its derivatives (like Mint), which are mostly used on desktops rather than servers.

osamagirl69 2y ago

To be honest the never ending headache of getting things to work with SELinux under RHEL was a big driver for why I moved to debian. Certainly SELinux has its place but I never found the value it offers to be worth the complexity it adds.

nicce 2y ago
The same reason why many people choose WhatsApp, Telegram, Slack, Discord over things like Signal or Matrix. They are just easier to use. It is about priorities. Maybe some day we solve the usability problems.
- p4bl0 2y ago
  I get it for Matrix, but Signal really has had the same user experience as WhatsApp for years now. But anyway, your point still stands. That's why user-friendliness is an important part of security (and why Signal work is so important regarding secure messaging apps).
  - dpassens 2y ago
    At most a little over one year ago, I installed Signal Desktop to open a link in a message I had received on my desktop. This is, apparently, deliberately unsupported, since the app claims that "[f]or your security, chat history isn't transferred to new linked devices". So no, the user experience of WhatsApp is miles ahead of Signal, at least if you want to use a real computer.
    - deleted 2y ago
      [deleted]
  - okanat 2y ago
    I think it is still impossible to backup one's own messages in Signal and then retrieve them back in another phone. It was possible on Android via root but basically impossible for unrooted phones which is a dealbreaker for Apple devices my friends and family use. Signal has to provide 100% of the features and convenience of Whatsapp and some more without compromising security for it to be a viable alternative.

gwynforthewyn 2y ago

I fell in love with this article at this sentence: > Still. Many in the open source community have interpreted Red Hat’s decision for what it really was: A dick move. I've had a short essay in draft for a while about the difficulty of a small business trying to make money using The Red Hat Model (https://opencoreventures.com/blog/2023-04-red-hat-model-only-worked-red-hat/ https://opencoreventures.com/blog/2023-04-red-hat-model-only...). Red Hat seem like an outlier who're doing well with that model, but smaller places like Sidero or Bitfield had to find other ways to monetise their open source efforts, and sometimes that had pushback from the community. Red Hat, though, were acquired by IBM, and IBM made it harder for an otherwise thriving ecosystem to exist. Not impossible, but harder. IBM makes money hand over fist (billions according to https://www.ibm.com/annualreport/ https://www.ibm.com/annualreport/). Was there really a reason to make Red Hat harder to redistribute? The interviews I've read come down to "our Red Hat team works hard and we don't want to give that away to low effort projects", though if you've got an interview with a different perspective I'd love to read it.

ahoka 2y ago
The Red Hat model is basically “Embrace, extend, and extinguish”.
- rurban 2y ago
  The Red Hat model is rather to be the professional distro, made by professionals. Ubuntu and Debian are for hobbiests and lawyers, and you should never run a public server on debian/Ubuntu if you care about security.
  - _factor 2y ago
    I’m pretty sure the Red Hat model is to profit off the community efforts while creating convoluted complications in the name of security so they can send their high paid consultants to your business and get paid even more. Was it professional when they let SSH vulnerabilities exist in RHEL7 forcing perfectly useable machines to upgrade to 8 for remediation? Don’t get me wrong, they’re the new “nobody got fired for” company (technically still the same). That doesn’t imply Debian and Ubuntu are less secure except in name. Go to Google cloud and see what CIS hardened images exist. Your perspective is an oversimplification if not completely wrong.

zelon88 2y ago

> 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. And Linux in general has less resources to develop and maintain comprehensive security policies comparable to those provided by Microsoft. Yet here we are, with Microsoft products so "secure" that they're insecure unless you have a PHd in b****, being so convoluted and over-built that people have to migrate away from it just to recover the actual security they used to enjoy back when they were able to wrap their head around the whole stack. If devs want things to be more secure, stop developing more acronyms and just educate the userbase on the acronyms they already have.

Andrex 2y ago
After letting Russians waltz into their C-level emails (as well as those of US gov't 365 users) and steal Windows source code using basic password spraying for over six months before patching the hole, "Microsoft" and "secure" shouldn't be in the same sentence ever again. https://arstechnica.com/security/2024/01/microsoft-network-breached-through-password-spraying-by-russian-state-hackers/ https://arstechnica.com/security/2024/01/microsoft-network-b... Wasn't caught for two months and wasn't fixed until months after. How is Microsoft allowed anywhere *near* the bidding process for gov contracts anymore?

crdrost 2y ago

This is a surprising article because I kind of see this in light of the old Linux/BSD wars? “Red Hat owned making this policy apply to most of the popular software they distribute. On Debian the users have to set everything up.” — this sentiment is directly parallel to how BSDs see themselves as providing a whole consistent operating system, Linux meanwhile just wants to ship a kernel. “Debian doesn't care enough about security.” — says everyone who runs OpenBSD. “With SELinux policies, containers are isolated from the system.” — you could almost say they are “in jail,” maybe we could package this up as a syscall, hm, but what to call it... IDK what BSD looks like in 2024, but in ~2004 you would have seen this exact same article about Debian, but comparing to FreeBSD instead of RHEL.

tuna74 2y ago
"On Debian the users have to set everything up.” — this sentiment is directly parallel to how BSDs see themselves as providing a whole consistent operating system, Linux meanwhile just wants to ship a kernel." Linux is just an OS kernel. If you want a consistent OS, use RHEL, Ubuntu, Fedora, Android or something else.

fleventynine 2y ago

With the sheer volume of local exploits found in the Linux kernel, I don't really consider these SELinux/AppArmor mitigations to be that useful. Sure, they reduce the attack surface a bit, but if I actually need isolation between workloads, it's best to do it below the kernel (with a VM). If an attacker gets execution in userspace, it's best to assume they can also get into the kernel via some 0-day local privilege escalation...

NewJazz 2y ago
seccomp at least restricts access to certain kernel APIs. Although it is quite brittle.

theossuary 2y ago

I came in expecting not to, but I completely agree with this article. I moved off RHEL after using CentOS exclusively for a decade because of the changes in 2023. I loved SELinux, it's a technology you need to sink your teeth into if you want to understand it, but it has decent tooling (like audit2why) and isn't too hard to modify to get working if needed (SELinux booleans are a powerful way to modify base policies without having to recompile). I do a lot in Kubernetes, and there's been more than one CVE with a line like "Affects all versions of docker/containerd, unless running SELinux," which gave me a lot of reassurance that the effort put into making SELinux work was worth it. Now that I'm on Debian, I'm slowly building a new set of policies for the OS. Thankfully SELinux has an excellent reference policy[1] to base off of. I'm hoping my new debian base images for my homelab & elsewhere will have a nice restrictive default SELinux policy by the end of the year. I hope there's more community effort here as well, SELinux really can't compare to AppArmor, and is absolutely necessary for proper security. Honestly I'd love if the wider community took another stab at replacing SELinux with a KSM that had similar functionality but better tooling and design. I'd pick it up in a heartbeat, but right now SELinux is what we have. [1]: https://selinuxproject.org/page/NB_RefPolicy https://selinuxproject.org/page/NB_RefPolicy

turtle_heck 2y ago
I agree SELinux is awesome. SELinux can be frustrating without the proper background about what it is, how it works, and how it helps you. There is a surprising amount of tooling for it actually.
NewJazz 2y ago
I do a lot in Kubernetes, and there's been more than one CVE with a line like "Affects all versions of docker/containerd, unless running SELinux," which gave me a lot of reassurance that the effort put into making SELinux work was worth it. I've seen this too, but I usually see AA mentioned in the same situations as an equivalent mitigation to SELinux.
- theossuary 2y ago
  I can't say I've seen the same, so I dug into it. There's a good list from RedHat[1] on CVEs SELinux mitigated. I went through them: - CVE-2016-9962 - Bypasses Apparmor [2], mitigated by SELinux - CVE-2022-0492 - Apparmor and Seccomp also protect against - CVE-2019-5736 - Mixed, blocked by the default SELinux policy in RHEL (not Fedora), not blocked by the default AppArmor policy[3] - CVE-2021-3156 - This one is not a good one for RedHat to put on the list. SELinux by default doesn't protect against it, Debian 10 at the time had a Linux security feature enabled (fs.protected_symlinks) that helped mitigate it, and additionally CVE-2021-23240 came out which had similar effects but only occurred on SELinux systems. - CVE-2019-9213 - Not mitigated by AppArmor, mitigated by SELinux - CVE-2019-13272 - Not mitigated by AppArmor, not mitigated by default SELinux policy, but easy to mitigate by enabling boolean. I'd consider this a win for SELinux, but only just. While digging into this more, I came across this BlackHat talk[4] which really quantifies how SELinux improves security (though doesn't contrast it with AppArmor). I also came across a paper on usability of SELinux and AppArmor[5] which brings up an interesting point: If the tool is too complex, even if it's more powerful, more often than not it won't end up having better results. That's all to say, I think if you're willing to invest a lot of time into it (say you want to make security your niche in your development career), SELinux is still the best. But I can see why many may gravitate towards AppArmor so as to not make perfect the enemy of good. That said, I still wish Debian had a choice between the two, right now SELinux isn't really doable without a lot of work. [1]: https://access.redhat.com/solutions/7032454 https://access.redhat.com/solutions/7032454 [2]: https://github.com/opencontainers/runc/issues/2128 https://github.com/opencontainers/runc/issues/2128 [3]: https://www.cloudfoundry.org/blog/cve-2019-5736/ https://www.cloudfoundry.org/blog/cve-2019-5736/ [4]: https://www.youtube.com/watch?v=EkL1sDMXRVk https://www.youtube.com/watch?v=EkL1sDMXRVk [5]: https://researchportal.murdoch.edu.au/esploro/outputs/journalArticle/Empowering-end-users-to-confine-their/991005540115207891#file-0 https://researchportal.murdoch.edu.au/esploro/outputs/journa...

bawolff 2y ago

Be interesting to know if anyone had any numbers on actual security issues in practise. Complexity is generally really bad for security. It results in people working around the system or just turning it off. Security is not just "in theory" - a perfectly secure system that most users disable is an insecure system. It reminds me a bit of the idea of making people change their password every month. Sure, in theory it reduces time a compromised credential can be abused for. In practise though it means nobody can remember their password, people start using really poor passwords and writing them down on post it notes. The net result is much worse security practically speaking, even if its better theoretically.

Mikhail_K 2y ago

[flagged]

mmh0000 2y ago
I really don't get this hatred of systemd. Systemd solves many programs that have plagued Linux forever. Sure, SysV-init was super simple, and it was great back in the 1980s or even the 1990s when your server ran just a handful of daemons. But systems get more complex and featureful over the years. In the year 2024, my standard Fedora Linux desktop, has 73 daemons running in the background... Dealing with sysv single-threaded and start-and-forget architecture is not great on modern systems. You might say, well, why not Upstart!? Well. Upstart added a lot of complexity to the init process, while adding very little overall benefit. Systemd added a lot of complexity, no doubt about that. But, it also added a TON of features that reduced complexity elsewhere on the system. I mean, just to rattle a few things off: * systemctl. Holy fuck! A SINGLE command, that works across all modern Linux to control system services. I do not miss the days of service, chkconfig, /etc/init.d/xxx start, update-rc.d, insserv, rc-update, rcconf, sysv-rc-conf, ntsysv. And every distribution having their own special init scripts that worked in a very specific way to that distro. A great example of this is RHEL5's sshd sysv init script, a 500!!! line shell script to start the ssh daemon... Compared to RHEL9's sshd 24 line systemd unit file. * cron - scheduled tasks being handled by a screwball 3rd party service that had no built-in method of ensuring a cronjob would be retried in the event of a failure... systemd timers fixed that nonsense. * at - see above * autofs - Here's a lovely service that is stupidly complex. Whenever I have to setup autofs I get the feeling that the developers purposefully asked themselves "what can we do to make our application hard to configure?" then, once they had an answer to that question, they went back to the drawing board and asked, "Okay, configuring autofs is hard, but, what can we do to make it even more obtuse?". systemd automounts are drop-dead simple, a 5 line unit file saying what to mount and on what condition. * Parallelization and dependencies - Systemd can start services in parallel and only after their dependencies are ready, unlike SysV’s linear approach. This isn't just for faster boot times; it's also about reliability. Ever had a service fail because another wasn’t ready? Systemd handles that for you. * systemd has overall good built-in security! All services are started in their own cgroup and with posix capabilities and r/w access to the filesystem easily restrictable. You claim systemd is a "badly written multifunction blob" but that's mostly not true, look at `/usr/lib/systemd/systemd-*` and `/usr/bin/systemd-*`. Systemd is split out into multiple purpose-specific executables in almost every place where it makes sense to do it. I could go on all day, but I'll stop here. I agree that the system isn't perfect, and they've made some choices I disagree with. But overall, systemd is a MASSIVE improvement over everything that came before it.

JohnFen 2y ago

Wait, the author is criticizing Debian for not having as heavy-handed a system as SELinux enabled out of the box? That thing that causes so much pain that everyone disables it immediately unless they have fairly extreme security needs?

commandersaki 2y ago
Never heard of anyone suggesting to disable AppArmor. As for the efficacy of the two, I'm less interested in the feature sets of the two. I think what'd be more interesting is replicate exploitation scenarios with their default policies and see which subsystem succeeds in mitigating the exploit and which fail.
- mrweasel 2y ago
  Can't say that I haven't disabled AppArmor on a server or two to make things work short term. Fixing the AppArmor is a bit easier than fixing SELinux policies though.
- silverwind 2y ago
  Had to disable AppArmor to be able to dump packets with tools like tcpdump.
- ruthmarx 2y ago
  > I'm less interested in the feature sets of the two. I think what'd be more interesting is replicate exploitation scenarios with their default policies and see which subsystem succeeds in mitigating the exploit and which fail. The feature set is exactly what dictates which systems are more likely to prevent exploitation, though. App Armor simply isn't as granular, and simpler to bypass (e.g. by making a hardlink to a file to override AppArmor policy). AppArmor may be good enough in many situations, but SELinux gives you much more control, so you can be much closer to perfect to protect against unknown situations.
  - commandersaki 2y ago
    Still don't care about the feature set, show me a useful benchmark. If SELinux prevents a hypothetical that's great, but security is a tradeoff and I'd opt for convenience and simplicity to sacrifice potentially negligible risk. For example, I'm seeing that SELinux didn't mitigate ShellShock where AppArmor did (despite being an attack vector that isn't really common). But these are the things I want to know.

ok123456 2y ago

I've seen poorly implemented SELinux policies make a workstation unusable and fill up /var with audit.logs that are tens of gigs. You have to do 100% coverage testing on whatever program you're using. (Good luck if you don't have the source code.) Otherwise, you don't have any guarantee that your program won't seemingly be killed randomly. Good luck, x2, if you have some snake oil "endpoint security" that keeps overriding your SELinux policy changes.

dsr_ 2y ago

> Containers are increasingly the preferred method for developers to deploy their software – myself included. A common misconception is that if you run something in a container, it’s inherently secure. This is absolutely not true. Containers by themselves do not solve a security problem. They solve a software distribution problem. They give a false impression of security to those that run them. To the extent that containers are a software distribution method outside of a single authority, they are a security nightmare. They are the exact equivalent of shipping a developer's laptop off to the datacenter and replicating it as a production image.

lolinder 2y ago
> They are the exact equivalent of shipping a developer's laptop off to the datacenter and replicating it as a production image. If you're building your containers on a developer laptop and then pushing them to the registry from there, yes. You can also not do that and instead have all builds happen on a CI server that isn't ever touched directly by anyone, like you should really be doing to build any artifact that gets deployed to production, container or otherwise.
- dsr_ 2y ago
  Read the proviso again, please: this is a criticism of receiving containers from an outside source, not using them to distribute your own images.
  - lolinder 2y ago
    The proviso could have been read either way, and your claim that it's an exact equivalent of shipping off a developer laptop makes no sense if what you meant was "you're downloading untrusted code from strangers". I read it first the way you apparently meant it but chose to respond to the meaning that made your second sentence make sense rather than the one that made it a non sequitur. Using images from untrusted sources is a not-quite-exact equivalent of downloading code directly from npm and shipping it off to production.
bornfreddy 2y ago

transpute 2y ago

SELinux Coloring Book PDF, https://developers.redhat.com/e-books/selinux-coloring-book https://developers.redhat.com/e-books/selinux-coloring-book & https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf https://people.redhat.com/duffy/selinux/selinux-coloring-boo... > Learn the basics of SELinux, including type enforcement, Multi-Category Security (MCS) Enforcement, and Multi-Level Security (MLS) Enforcement, with the help of some friendly cats and dogs!

vfclists 2y ago
Seriously? Do I see what looks like the Penguin dogging the Dog on page 7?
- transpute 2y ago
  The book has a few cartoon images, some are repeated. There is explanatory security text for each image. Image semantics can be derived from text semantics.
- 3np 2y ago
  I guess you see what you want to see
pvaldes 2y ago
Selinux coloring book never really explains how to start doing anything useful with the program

Anthony-G 2y ago

Excellent article. The key take-away for me is: > The ugly truth is that security is hard. It’s tedious. Unpleasant. And requires a lot of work to get right. I use Red Hat-based distributions at work and Debian/Ubuntu in my personal life. A few years ago, I bit the bullet and learned enough of SELinux to run my workstation and all my servers in enforcing mode. The author of this article is right to credit Red Hat for all the work they’ve done to provide users with default SELinux policies that work out of the box. At one time, I considered installing SELinux on my Debian system and modifying Red Hat’s policies to work with the Debian packages. I realised how much work would be involved so I chose the path of least resistance: AppArmor (which does the job).

deleted 2y ago
[deleted]

okasaki 2y ago

I hear a lot about podman online, but I've never seen anyone using seen.

throw7 2y ago

I disabled selinux after learning about dontaudit rules and having them waste my time. That's not to say on very specific systems that need to be hardened, I do enable selinux and am glad it's an option. And if I have to use a security layer, I take the object based selinux over the path based apparmor.

renewiltord 2y ago

Never used this. All my wealth is still mine. No one stole it. Two decades of Linux on the desktop. Some almost always on. If risk is lower than 1/2decades it's not worth learning. Insecure debian it is.

kelnos 2y ago
The article is concerned about server security, not desktop security.

txutxu 2y ago

Debian can run with SELinux if you like that. Debian uses AppArmor by default, probably because of the Canonical influence (there are more Debian developers and maintainers paid by Canonical than by RedHat). But you can run Debian with SELinux (as well as with other LSMs, MACs, etc like Tomoyo). At my last jobs, we disabled any of SELinux, AppArmor and Auditd on Debian/Ubuntu, just for the sake of performance. And we never detected any security issue for our usage and requirements. So I'm not an expert in this field. Not sure what the purpose of the article, or the whole blog, is. You want to influence the choosing of Debian Vs RHEL Vs Oracle Linux in some place? As I'm not sure, will stop here.

wakawaka28 2y ago
It reads like either an ad for Red Hat or an add for SELinux which this guy is probably familiar with (unlike most Linux users and professionals).

Brian_K_White 2y ago

Meanwhile everyone agreed that the convenience of magic integration with browsers and other things was more critical than security, in the default config, for a password manager of all things, when debian changed the default keepassxc package to omit optional added attack surface plugins. Not unavailable, just not installed by the default. I wonder how many people that agree with this nonsense position also agreed with the keepassxc nonsense position.

steeeeeve 2y ago

1. You can enable SELinux on debian if you want to. 2. I've never had a conversation with anyone who is enthusiastic about SELinux. 3. I've never run into someone who was good at explaining SELinux policies, how to create them, update them, or explain their decision process other than "well... the app seems to need to do x, so we should let it." 4. I have run into plenty of people that disable SELinux out of the gate to avoid the headache of it. 5. I have run into plenty of people that avoid Redhat distros. This is akin to someone writing an article about how Oracle and Microsoft got databases wrong because they didn't embrace some security feature that only DB2 has and that more than half of DB2 users out there think is a giant pain in the neck.

rmholt 2y ago

Would generation of SELinux policies be a good use case for LLMs? "Generate a SELinux policy for daemon X. This daemon accesses it's config file in /etc and it's runtime data in /var/x. It listens on network. All other activities should be disabled"

layer8 2y ago
Only if you’re knowledgeable enough to double-check the resulting configuration and correct any mistakes or omissions.
kelnos 2y ago
While I agree the syntax of the policy is a big part of the difficulty, I think it's equally difficult for many apps/services to find out what activities it needs.

h4ck_th3_pl4n3t 2y ago

I think that both AppArmor and SELinux are unusable in practice due to lack of better tools for generating those configurations. There needs to be better graphical tools for this, like a "profiler" or similar that watches a process for a specific time for errors in the config and that incrementally adds features while the process is running. In my opinion, systemd sandboxes are where it's at. [1] They are seccomp based sandboxes, but have a lot of isolation and sandboxing features that are very easy to use, and they can also be incrementally enhanced with both SELinux and AppArmor profiles. [1] "man systemd.exec" or https://manpages.ubuntu.com/manpages/bionic/man5/systemd.exec.5.html https://manpages.ubuntu.com/manpages/bionic/man5/systemd.exe...

NewJazz 2y ago
AA at least has what you are describing. https://man.archlinux.org/man/aa-genprof.8 https://man.archlinux.org/man/aa-genprof.8
nobody42 2y ago
I'm trying to solve the lack of tools for AppArmor profile composition: https://github.com/nobody43/apparmor-suggest https://github.com/nobody43/apparmor-suggest

turtle_heck 2y ago

Relevant: https://stopdisablingselinux.com/ https://stopdisablingselinux.com/

fsflover 2y ago

If you care about security, consider the security-oriented Qubes OS relying on hardware virtualization and running everything in Debian and/or Fedora VMs: https://qubes-os.org https://qubes-os.org. My daily driver, can't recommend it enough.

Arnavion 2y ago

For systemd services, there's also the option to use the service unit directives that systemd provides to limit caps (CapabilityBoundingSet, NoNewPrivileges, etc), filesystem access (ProtectSystem, ReadWritePaths, etc), other "system" access (ProtectProc, PrivateUsers, RestrictNamespaces, etc) and syscalls (SystemCallFilter). I find these an easier and more direct way to harden than writing apparmor / selinux profiles. `systemd-analyze security <service unit name>` gives a nice list of things to consider tweaking. You don't have to fix everything or pay attention to the exposure ratings, just use it as a guide. I did this for chrony, haproxy, nginx, tor and unbound on my Debian router. I also have some timer units to run scripts to update DNS blocklists and such, which have the same kind of hardening. For the services, some of them have caveats and can't be fully hardened, eg unbound needs PrivateUsers=no because it fails if it can't find an unbound:unbound user to switch to, even if it was already started as unbound:unbound by systemd. And SystemCallFilter makes it easy to get overzealous and only allow the exact set of syscalls that you see the service making, only to have a service update or glibc update that starts making a new syscall and requires another round of debugging, so do it in moderation :)

vfclists 2y ago

SE Linux - A tool conceived by the NSA to discourage users from hardening their systems.

deleted 2y ago
[deleted]

sirjaz 2y ago

This is one place windows does have things set right with ntfs acls

wongogue 2y ago
But that kills filesystem performance.
kelnos 2y ago
Filesystem ACLs are part of the puzzle, certainly, but are insufficient if they're the only mechanism.

kkfx 2y ago

Honestly? SELinux is a nice idea, practically obscene, like many others, Solaris RBAC a "so important security feature" essentially no one use for real to name another. Today most security breaches came from crappy applications with an immense set of dependency put into production because someone want them, there is no protection for them, adding long and painful system stuff is only a way to have also badly configured systems. Debian issues are more in a complex custom setup, preseed it's a nightmare compared to NixOS, which is much more important than SELinux, regularly disable on most deploys.

theteapot 2y ago

I'm way more worried about how a compromised xz-utils made it past the package maintainer and into the Debian repos. Mitigating supply chain attack vectors like this seem like the bigger priority by far and low hanging fruit. I don't follow Debian leadership but haven't come across any reaction or policy change to address this from them?

goodpoint 2y ago

SELinux is Mandatory Access Control system. MAC is not that useful for most servers: The real risk comes from network-facing services and they are much better protected by seccomp and cgroups, usually configured in systemd, and Debian uses that extensively. Seccomp can even protect vulnerable system calls. SELinux is not able to do that.

ruthmarx 2y ago

I wonder if this article title is a deliberate reference to 'The Insecurity of OpenBSD' article which also addressed a lack of SELinux or similar systems.

sunshine-o 2y ago

Not only Debian, the lack of SELinux is one of my main concern with NixOS

hsbauauvhabzb 2y ago

RHEL doesn’t have any indication as to how the contrib repositories work. SELinux might be nice, but it won’t have any impact if I install a malicious package. And yes, I need contrib as I need the ability to use graphical drivers and play proprietary formats.

brvier 2y ago

Haha first step of most Redhat user : shutoff selinux. RedHat have such bad moves, deploying unfinished, instable and unsecure softwares.

MarkusWandel 2y ago

For my personal machines, I have an early install script that turns SELinux off and makes the system boot with mitigations=off. Personal machine, behind my own firewall etc. I'd hate to be a system administrator, and despite my existing habits, this article convinces me that, if I was, I would try to actually understand SELinux.

4oo4 2y ago

The discussion of container security is completely lacking any mention of userns remapping, which is an excellent container security feature that's extremely easy to enable and use compared with AppArmor/SELinux (and would work extremely well in parallel with them). That way if someone does manage to break out of a container they have the privileges of a dummy user that doesn't exist on the host, so unless they are using a kernel exploit, they don't have any privileges to be able to do any damage. https://docs.docker.com/engine/security/userns-remap/ https://docs.docker.com/engine/security/userns-remap/