| ▲ | 0xbadcafebee 5 days ago |
| Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work. Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is. What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs. |
|
| ▲ | zdragnar 5 days ago | parent | next [-] |
| > What's insane about all these discussions is that NOBODY IS HACKING X SERVERS I knew someone who worked for a small loan type company. Passwords were stored in plain text, but even worse, the login form didn't actually check the password at all, it created valid sessions as long as you provided a valid user name. When he informed his boss that was very bad, his boss simply said that nobody has abused it, and nobody would, don't waste time changing it. The point, of course, is why would you wait until people are getting hacked to address a known vulnerability? Sure, there are others, and they should be closed too, and they are when they are found. It makes no sense whatsoever to leave one open just because. |
| |
| ▲ | da_chicken 5 days ago | parent | next [-] | | I think the point being made isn't that X.org shouldn't fix their vulnerabilities. It's that there's always a huge amount of discussion about vulnerabilities and security models when one is found in the display server or the window manager when actual exploitation doesn't seem to be particularly high. Many distros, if not most distros, disable port 6000+ listening for X.org by default. So, immediately, it's not a remote exploit. OK, so it's scope is already limited to local escalation attacks. Looking at the CVE, the only reason it's high is because (a) X.org is everywhere, (b) you don't need to interact with [another] user to exploit it, and (c) it's not particularly complex to exploit. That is bad, but it's also behind most of the other security, rather than bypassing essentially all of it like Heartbleed or Shellshock. So, either I have to have X forwarding turned back on, or have people with SSH access to a server that is also running X. Both of those seem like uncommon situations. You probably shouldn't be running X or permitting X to be started unless you need X forwarding, and X forwarding is a pretty odd requirement given modern application design being so web-browser-focused. So it might be CVE High 7+ if you're on a system where it's possible to exploit it. But it feels like you shouldn't often be on a system configured in a way where it could be exploited in spite of the prevalence of X. Essentially: This isn't a rehash of the libXfont problem. | | |
| ▲ | immibis 4 days ago | parent | next [-] | | This is because Wayland wants to differentiate itself from X on security. Wayland has to show it's more secure than X - as part of that, Wayland has to show that X is insecure. | | |
| ▲ | jonway 4 days ago | parent [-] | | No, wayland already differentiates itsself from X11 because X is a tool for graphical network terminals and Wayland is a tool for single machine rendering. X11 is a mountain of tech debt that almost nobody wants to maintain. | | |
| ▲ | 4 days ago | parent | next [-] | | [deleted] | |
| ▲ | theodric 4 days ago | parent | prev [-] | | Wayland is what you get when you decide to start a space program because, let's be honest, the electrical gremlins in your 1983 Mercedes 560SL are beyond properly fixing, and the kids still need to get to school | | |
| ▲ | jonway 4 days ago | parent [-] | | X is equivalent to calling your spouse on the telephone when they are sitting next to you on the couch. | | |
|
|
| |
| ▲ | 0xbadcafebee 5 days ago | parent | prev [-] | | But there is no vulnerability at all. For a normally configured X server with TCP listening, the server should be configured to use MIT magic cookies for authentication. This randomly-generated string is needed to authenticate and establish a connection to the X server. You can use the xauth command to manually configure it as needed. It's the equivalent of HTTP Digest authentication, and nobody's demanding that we rewrite HTTP because Digest authentication. It's in plaintext, so you shouldn't use it; but if a hacker doesn't know the secret, they can't get in. | | |
| ▲ | da_chicken 5 days ago | parent | next [-] | | > But there is no vulnerability at all. For a normally configured X server with TCP listening, the server should be configured to use MIT magic cookies for authentication. This feels like you're not understanding why something is called a vulnerability, how they're defined, or why they get rated the way they do. "It's not vulnerable in a best practice configuration," is not the same thing as, "there is no vulnerability." That is incorrect and misleading, and I think you're conflating risk and severity. The definition used for a vulnerability is [0]: "A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability." (emphasis mine) The CVSS score is not a measure of risk. It is a measure based on the qualities of the defect that was identified and how widespread the software is. A higher CVSS score is associated with higher risk, but your risk is going to vary based on your configuration. All they did was go to the calculator[1], plug in the answers that best fit the definitions provided for what those areas and responses mean (e.g., CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H for CVE-2025-62229), and they get that 7.3 score [2]. [0]: https://nvd.nist.gov/vuln [1]: https://www.first.org/cvss/calculator/3-1 [2]: https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:L/AC:L... | |
| ▲ | hirako2000 5 days ago | parent | prev [-] | | Digest as I understand it is a weak authentication protocol, it doesn't mean it is implemented with known vulnerabilities. I distinguish vulnerability from weak. The weakness is not necessarily intended, but the question is, does it do what it is supposed to do. Or is there a known bug: non intended possible exploit, that would make it a vulnerability. If it isn't known then it doesn't exist. But we can assume all software do have bugs. Digest is part of the http protocol, if the protocol is found to have vulnerability I can imagine it would be dropped and be rewritten. The digest part, not the entire http protocol. A hacker may not have the password, but manages to brute forces it. Is that a digest vulnerability or does it fall onto the application to integrate some preventing brute force authentication measures? My take is digest doesn't pretend to prevent brute force attacks. Some may not agree with that logic, but since about everything is made of a combination of vectors, and that each typically has some weakness, all you get is a balance between usability, cost, and security. We can make the case for your typical cryptographic signature, or encryption algorithm. ECDSA standing as well respected, solid cipher. Is it vulnerable? It is vulnerable to the potential power of machines we may build in times to come. Quantum or leaps ahead. Will it be vulnerable then? Yes but it isn't a vulnerability. We would then call ECDSA obsolete. Digest is obsolete yes. The interesting part about cryptographic methods is that we may know of some being obsolete ahead of time. So long as we can determine they can be brute forced. For now it isn't obsolete despite the existence of quantum resistant alternatives. Hacker news uses ECDSA for the exchange of keys between server and client, then encrypts all connections using another algorithm safe against quantum computers. Thanks. But beyond that, probably not. Is X obsolete? Vulnerable? Seems like X developers themselves admit it is a vulnerability. They didn't know of the possible exploit. As to the severity? It's often subjective from my experience. Happy to be wrong, and we don't have to agree. |
|
| |
| ▲ | nurettin 5 days ago | parent | prev | next [-] | | I don't dispute your anecdote but I think the point was: x11 has been around for decades, and these things just don't happen. And the reason is that there are much simpler and more effective ways to pwn a box than trying to screenshot an x session or trying to hook for key presses. So the vulnerability surface just isn't large enough. | | |
| ▲ | Suzuran 4 days ago | parent | next [-] | | That's not how this works. If you cannot prove conclusively that something is not the case ever, then you must accept that somewhere in the infinity of possibility it is. | |
| ▲ | kragen 5 days ago | parent | prev [-] | | I have definitely seen "these things" happen. | | |
| ▲ | nurettin 5 days ago | parent | next [-] | | What did you see specifically? And on what OS? | | |
| ▲ | 41throw-it 4 days ago | parent | next [-] | | Hi -- throwaway I have seen this happen as well. A memory corruption vulnerability in popular software allows unpriv shellcode to reach out and drop a rootkit which loads a rat as a kernel module. Attacker has control. Several big problems. cobaltstrike beacons blocked. Instead pierce nat with STUN to attacker proxy. Use socket activated VNC/RDP/X. Why not just steal the sessions and local data? Remote services log access (ip, time, location), easily correlate and forensics would lead back. Local data encrypted at rest, hands on keyboard needed any way since recon incomplete. Are they planning to scan memory for ssh key unlocks or intercept ssh -sk key? This is big, noisy and take developer time. If you log in to a email this leave forensics and is a CFAA violation while risking FAANG security. Attacker needs to shoulder surf. Most hack is install crypto mining or steal a password. Maybe it is ransom. How do you get 2fa code if you want access to sensitive information? How do you steal hardware keys? You can back door browser, MitB but it gets updated away and you lose access. back door anything and lose access or discovered. This is not a advanced attacks but it is targeted attacks. People are saying x server never get hacked, but computers get hacked. with X11 the chain is Exploit -> Game over. with wayland you need to go farther. | |
| ▲ | anthk 4 days ago | parent | prev | next [-] | | All of NIXen. ~/.profile ~/.env ~/.xprofile Exploiting TMPDIR, /tmp race conditions, ~/.mailcap and mutt (I used that to get access to 'premium' binaries under restricted accounts). If you have Emacs you can do tons of stuff from a single account. And so on. | | |
| ▲ | nurettin 4 days ago | parent [-] | | Not sure what mutt has to do with X. Maybe you replied to the wrong thread. | | |
| ▲ | 41throw-it 4 days ago | parent [-] | | ~/.xprofile I agree in a little way to what you say, but if you can write .xprofile you can with no work escalate from the x socket. |
|
| |
| ▲ | kragen 5 days ago | parent | prev [-] | | Can't give details. |
| |
| ▲ | LtWorf 5 days ago | parent | prev [-] | | Source? | | |
| ▲ | kragen 5 days ago | parent [-] | | No, I've seen them. Myself. I didn't get this from a source. | | |
| ▲ | LtWorf 4 days ago | parent [-] | | So you didn't report the bugs? | | |
| ▲ | kragen 2 days ago | parent [-] | | No bugs were involved, just X11 functioning as designed. | | |
| ▲ | LtWorf 2 days ago | parent [-] | | So you just don't like X11. Ok. But what was your point then other than share your personal feelings? | | |
| ▲ | kragen a day ago | parent [-] | | It sounds like you're out of your depth in this conversation, Lieutenant. I have ambivalent feelings about X11, but they aren't relevant to the topic at hand. 0xbadcafebee said, "Why do people keep persisting this myth? X11 has authentication. ... What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring ..." and then nurettin followed up by saying, "x11 has been around for decades, and these things just don't happen. And the reason is that there are much simpler and more effective ways to pwn a box than trying to screenshot an x session or trying to hook for key presses." But in fact I have seen people gaining elevated privileges by "hijacking" X servers when the authentication was configured to be lax, and I've sometimes configured my own authentication to be lax (because configuring it properly was a hassle), so I know it's not an "imagined threat" from "NOBODY" or a "myth" or things that "just don't happen" because "nobody is trying" them. But it's not a "bug" either. It's a design tradeoff. X just wasn't designed to provide a security boundary between applications, to encrypt its network traffic, or by default to use any authentication at all other than host-based authentication. Even MIT-MAGIC-COOKIE-1 auth was an add-on, and it is sent in the clear, permitting replay attacks. These are defensible tradeoffs, and ssh -X and the current xauth defaults improve the situation significantly, but Wayland's design provides a lot more isolation between applications by default, which is probably a more defensible tradeoff. |
|
|
|
|
|
|
| |
| ▲ | themafia 5 days ago | parent | prev | next [-] | | > is why would you wait until people are getting hacked to address a known vulnerability? Do you have some other way of _reliably_ identifying vulnerabilities? > It makes no sense whatsoever to leave one open just because. It makes sense to have security options. If I want to leave it fully unlocked, that's my business, and I possibly have good environmental reasons to do this. What you should really care about are security _defaults_. And in X11's case I'm not aware of any distribution that ships the server with TCP connections to the sever enabled. You have to go well out of your way to even begin using this functionality. | | |
| ▲ | zahlman 4 days ago | parent [-] | | > Do you have some other way of _reliably_ identifying vulnerabilities? This is irrelevant given that we are talking about known vulnerabilities. No, you can't reliably find all the vulnerabilities by auditing the code. Yes, if you audit the code and believe you have found a vulnerability, you fairly reliably are correct in your belief. And should probably take action even if you aren't. | | |
| ▲ | themafia 4 days ago | parent [-] | | > we are talking about known vulnerabilities. In a context which does not involve them. I simply ignored the subtle goalpost shift and addressed the core issue of the article. > And should probably take action even if you aren't. Where they action could include "disabling as a default option." Yes? |
|
| |
| ▲ | portaouflop 5 days ago | parent | prev [-] | | It does make sense if the vuln doesn’t fit in your threat model.
There are always an uncountable number of vulnerabilities and you can never fix all that are found. No idea of course if the threat model that said boss had in mind made sense. But I always recommend to come up with a reasonable threat model first and then think you can harden against it. |
|
|
| ▲ | tapoxi 5 days ago | parent | prev | next [-] |
| I think the issue isn't that you downloaded random hostile software, but that other software you do use has some sort of vulnerability (recent Unity vulnerability, browser sandbox escape, etc) and an issue like this would allow for privilege escalation. Wayland doesn't need X11's vulnerability as its only argument, Wayland is a much simpler design that is easier to iterate on because it doesn't assume the client and server are on different machines. The fact that it moves privileged APIs like screen capture behind portals is a bonus. |
| |
| ▲ | kelnos 5 days ago | parent | next [-] | | So simple and easy to iterate on that Wayland compositors are still not as full-featured as X11 desktop environments after more then a decade, and can't be due to protocols no one is able to agree to implement. | | |
| ▲ | phkahler 5 days ago | parent | next [-] | | >> Wayland compositors are still not as full-featured as X11 desktop environments It depends what features you care about. X11 doesn't have tear-free video playback, HDR, or as good a security model as Wayland. | | |
| ▲ | toast0 5 days ago | parent | next [-] | | X11 has options for tear free video playback; it's not in the base protocol, and not all drivers offer it, etc, but it's acheivable. Fundamentally, you need to send the next frame to the server and ask it to switch frames during vblank (+/- notification), on today's systems, this is more of a coordination problem than a technical one; there's plenty of video ram to go around to double/tripple buffer. HDR would fit in the X11 model of many bit depths, however the specifics don't really; afaik, X11 has a maximum bitdepth of 32 for pixel values, which means either limiting to 2-bits of alpha channel or using palettes (I think I saw that indexed colors can be defined with 16-bits per channel). An extension might be possible (with everything that brings), but I think the ship has sailed. I agree that Wayland's security model prevents some undesirable interactions that X11 allows, but it also prevents or makes difficult some desirable interactions, so it's a mixed bag. | | |
| ▲ | Imustaskforhelp 5 days ago | parent [-] | | > I agree that Wayland's security model prevents some undesirable interactions that X11 allows, but it also prevents or makes difficult some desirable interactions, so it's a mixed bag. That is so true, I wanted to have a typing sound from my pc everytime I typed on wayland and I looked at LITERALLY every single solution and none of them worked... simply because of the security model of wayland (so things like Mechvibes and alternatives don't work generally speaking) On one hand, its a good thing to prevent things like password injection etc. but on the other, really? I got frustrated and I created a lot of github issues on every such project if they said that they are working on wayland and I didn't care if it meant running it as sudo, I just asked them kindly if there was a way or not/ what's the issue here There are still times where I get a lot of notifications simply because someone commented on those issues So naturally a lot of people are/were frustrated about it. Not sure if its a good thing or not, but I 100% agree about this comment of yours Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers, Please let me know if there are apps which do this though, I know about weston but I haven't found ways to work with it/make it work (maybe my skill issue) Are there any solutions to these things though? Fundamentally that mechvibes things requires an app to view the key from every other application and make a sound, Nothing stops it from being a key-logger as well if it had that capability and Wayland was created with a better security model but as you say and I experienced, that security model comes up with its own compromises and I am not sure if that's a good thing or bad thing.... | | |
| ▲ | throwaway7486 5 days ago | parent | next [-] | | > Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers Waypipe[0] for native Wayland applications, and if you need to forward X11 apps there's xwayland-satellite[1]. You can hook xwayland-satellite with Waypipe and forward X11 apps through Waypipe. This way you get even better performance than with traditional X11 forwarding methods. The other day I was playing Steam/Proton games through the network this way. Of course, X11 forwarding also works fine on Wayland with ssh -X, but as I said, consider Waypipe + xwayland-satellite. [0] - https://gitlab.freedesktop.org/mstoeckl/waypipe/ [1] - https://github.com/Supreeeme/xwayland-satellite | |
| ▲ | prmoustache 5 days ago | parent | prev | next [-] | | > Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers, waypipe just works too. That replaces any reason to do SSH forwarding. Also some desktop like Gnome (maybe KDE has similar feature?) offer remote desktop. In Gnome's case it is using RDP protocol instead of VNC. | |
| ▲ | toast0 5 days ago | parent | prev | next [-] | | With the caveat that I haven't used Wayland ... [1] Waypipe is supposed to help replace things like remote X. I'd be surprised if there's no vnc server that offers a wayland desktop... that would be a big missed opportunity. For your noisemaker, I think you might have a better time integrating at another level. Either intercept the inputs before the display server gets them, or integrate into the display server itself. X was more flexible, but as long as it's just typing -> noise, you don't need it to have the same architecture as it did in X. [1] Wayland has no compelling features for me, and X remains viable for me as well. At some point, hardware support might be compelling, or IMHO, something will come to replace Wayland and X that is compelling. | |
| ▲ | yjftsjthsd-h 5 days ago | parent | prev [-] | | > Another big issue imo to me feels like ssh, X servers ssh forwarding/vnc just works, Yet I haven't really found ways to do things like VNC on wayland on a server or something as easy (or even possible?) on wayland as compared to x servers, Yes, this should be workable, assuming your compositor is compatible (a meaningful caveat, but not insurmountable): * To forward one application like `ssh -X`, you want waypipe * For VNC, it really depends on your compositor, but wayvnc works for many of them. (And GNOME does their own thing and I think KDE has their own official option) |
|
| |
| ▲ | jitl 5 days ago | parent | prev | next [-] | | I remember watching tear free HD video in 2011 on a netbook I dug out of the e-waste dumpster in the UC Berkeley CS building basement. Chrome/Openbox/X11. That laptop was literally trash. | |
| ▲ | mikkupikku 5 days ago | parent | prev [-] | | Using a compositor fixes screen tearing, no need to use Wayland for that. | | |
| ▲ | phkahler 6 hours ago | parent | next [-] | | >> Using a compositor fixes screen tearing, no need to use Wayland for that. Right, and that abandons the whole X drawing API in favor of passing around client drawn bitmaps. That was one of the big points of Wayland too - X has a whole bunch of stuff that no modern apps use anyway so lets throw it out and build up a better version of the capabilities we need. If we abandon the X drawing API and half an OS included (memory management) and use KMS, all that's left is the features that are security holes. | |
| ▲ | marmight 5 days ago | parent | prev [-] | | Even a compositor is unnecessary to fix screen tearing these days: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests... |
|
| |
| ▲ | imtringued 4 days ago | parent | prev | next [-] | | Aren't you just doubling down on Wayland being simple? X11 is the kitchen sink here. | |
| ▲ | jonway 4 days ago | parent | prev [-] | | What missing features? Xforward? |
| |
| ▲ | uyzstvqs 5 days ago | parent | prev [-] | | Wayland is the way to go. The same applies to Flatpak, Pipewire, systemD, etc. I'd say that this is obvious, and doesn't even need to be argued, to 99%+ of those who actually use the Linux desktop. The only opposition to this is a small group of decelerationists with a major, irrational aversion to change. | | |
| ▲ | vacuity 5 days ago | parent | next [-] | | Having only two major options, X and Wayland, doesn't mean either one is correct. It is generally true that X needs to be replaced, but Wayland is not necessarily the replacement we need. It would be good to have more competition. On a separate note, I think it's probably true that Wayland has significant drawbacks that preclude it from being an obvious replacement. | | |
| ▲ | LtWorf 5 days ago | parent [-] | | I see wayland as the pulseaudio of display. Everybody is pushing it and trying to convince the people who have problems with it that it's completely fine and their problems aren't important (like blind people being completely unable to use the computer). At some point the pipewire of display will come along and we'll all forget wayland was ever a proposed solution. | | |
| ▲ | dTal 3 days ago | parent | next [-] | | That's not really how any of this works. Pulseaudio is both a protocol and also an implementation of that protocol. Pipewire also implements the pulseaudio protocol, hence its compatibility with all existing software. Wayland is a protocol only. Every compositor - and there are many - implements it "from scratch". The "pipewire of display" would simply be yet another Wayland compositor. No one is going to solve the problems of Wayland in one fell swoop by releasing another Wayland compositor. What is actually happening is that problems are being gradually solved by the introduction of protocol extensions, which usually get adopted by other compositors after achieving success in one. | |
| ▲ | krupan 4 days ago | parent | prev [-] | | Man I hope you're right |
|
| |
| ▲ | mx7zysuj4xew 5 days ago | parent | prev [-] | | Everything you listed is bloated, slow, incompatible, unfinished or unstable. My system worked fine 20 years ago on far less capable hardware. Now even with high end workstations systems lag, crash or have strange behavior | | |
| ▲ | gf000 5 days ago | parent [-] | | [flagged] | | |
| ▲ | okanat 5 days ago | parent | next [-] | | We are running systemd with all bells and whistles on Raspberry Pi based 1 GB RAM systems. systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs. Our actual application is containerized with systemd thanks to broad set of options increasing system security quite a bit. It works great. You know what's bloated? Replacing all those functions with custom bash scripts or worse system services. | | |
| ▲ | yjftsjthsd-h 5 days ago | parent | next [-] | | > We are running systemd with all bells and whistles on Raspberry Pi based 1 GB RAM systems. systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs. Er. I have Linux boxes that have 128MB of total RAM doing useful work in my house (not using systemd). This is not the win you think it is. | |
| ▲ | gldrk 5 days ago | parent | prev | next [-] | | >systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs. That’s absurdly high for a headless system that’s doing nothing. There are countless millions of embedded devices doing useful work today with 1/10 the RAM. They run modern Linux just fine without the ridiculous bloatware. | | |
| ▲ | gf000 5 days ago | parent [-] | | Who said that systemd doesn't run on it? Also, what's bloated about systemd? It's a C binary, while I suppose you are into a ridiculous line-by-line textual interpreter? |
| |
| ▲ | Imustaskforhelp 5 days ago | parent | prev | next [-] | | My thoughts on systemd are complicated but I wasn't around at the time of systemd
Personally it is my opinion that Linux really split in two due to systemd partially because of the idea of the sheer size of systemd code There are things like https://github.com/Sweets/hummingbird which, I, not even a C person can understand and appreciate its simplicity. I am not saying that we always need such simplicity, but that I am merely giving an opinion that there are people who actually want to understand what they are running as their root and this sense of "control" really is so hard to get from things like system-d System-d is also thus a little "bloated" compared to other inits which really show in systems like containers etc. where most developers if possible try to have alpine containers (I have seen this especially so much in golang/rust communities partially because golang is mostly static available and rust can be done the same too or compiled with musl pretty easily) As such, personally, I can understand both systemd and other init systems, I feel like there are some guides which prefer using hummingbird etc. (https://github.com/comfies/tldrlfs) and I feel like for actually understanding "linux" from linux from scratch, other inits can be good. Another minor nitpick I have of systemd is that its glibc based, Glibc has some of the weirdest complexities I have ever seen and a lot of package management in my opinion has been built around it and personally it feels like the decisions were made in a different era where different types of resources were constrained and updates weren't as widespread but now it has been a mess which is why we need so many linux distros in the first place with their opinions and package management I genuinely prefer musl for this, So I prefer things like alpine/void in the process as well yet to me, freedom matters a lot. There should be a freedom of choice in such matters and systemd severely restricts it for many. I feel like systemd is way too ambitious and which is why it requires glibc to be more feature complete in the first place, not sure if its a good or bad thing but I am merely stating what I feel like. As I said, I have nothing against systemd myself but I am just giving the nuance I felt like, as I was trying to build my own linux distro trying to make it hyper compact and I came into this rabbit-hole, My philosophy almost was out of curiosity regarding what are the smallest systems which are still functionable (Hint: its tiny core linux which is an absolute pleasure although it isn't "secure" partially because they run everything as root If I remember correctly but ) >We are running systemd with all bells and whistles on Raspberry Pi based 1 GB RAM systems. systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs Okay but what are your thoughts on alpine, Alpine's motto or the first thing you see in bold letters on their website (https://alpinelinux.org/) is Small. Simple. Secure. Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox. Combined with either gcompat to run glibc or personally I genuinely prefer golang/rust applications (mostly golang) like running gitea on alpine etc. and I found it to be an absolute pleasure server side to work with mostly, except sometimes software download especially python when I was running alpine on android using userLand was a somewhat-issue but maybe I had skill issue or something but I genuinely learnt a lot trying to install python on it. Bun/Deno just works out of the box, in fact deno is even available in the apk format of alpine out of the box I truly love alpine/appreciate its message. I feel like systems should be small partially because that means that such software could run even on much older systems just out of the box Alpine features raspberry pi images and there is dietpi which has some decent low iso file sizes, Check them out as well if possible Personally I love alpine but I also love the idea of using debian or some immutable distro which uses systemd and then running alpine in container, it seems to be the best of both worlds really. | | |
| ▲ | herewulf 4 days ago | parent | next [-] | | You might be interested in Devuan (Debian but with OpenRC init), or for immutable, Guix System (Shepherd init). | |
| ▲ | LtWorf 5 days ago | parent | prev [-] | | When distributions started to use systemd, it was extremely buggy. The first 24h of me using it, I found 3 different bugs in journald where it was losing data. I'm currently using systemd, but it was far from being ready when all the fanboys with very basic use cases were insulting anyone who complained about it. |
| |
| ▲ | anthk 4 days ago | parent | prev | next [-] | | 350MB? I run a CWM under 350MB under OpenBSD plus Dillo and a few of terminal tools under i686. | |
| ▲ | 5 days ago | parent | prev | next [-] | | [deleted] | |
| ▲ | mx7zysuj4xew 5 days ago | parent | prev [-] | | [flagged] | | |
| ▲ | tomhow 5 days ago | parent [-] | | WTF? You can't address people like this on HN, and comments like this are completely unacceptable. You might not owe containers better, but you owe the community better if you want to participate here. Please take a moment to read the guidelines and make an effort to observe them if you want to keep participating here. https://news.ycombinator.com/newsguidelines.html |
|
| |
| ▲ | anthk 4 days ago | parent | prev [-] | | Wayland won't run fast on my n270 CPU based netbook. Pipewire it's good but sndio it's much faster. And SystemD it's a joke compared to the simple setup at /etc/rc.conf under OpenBSD and rcctl. |
|
|
|
|
|
| ▲ | zahlman 4 days ago | parent | prev | next [-] |
| People keep talking about X11 security in the context of servers and networking, but I'm more concerned about exposing more attack surface to local malware (i.e. keylogging other processes, capturing program state). |
| |
|
| ▲ | jeroenhd 5 days ago | parent | prev | next [-] |
| Of course X has authentication, but once you're in, you're in. There are no elevated windows, screen recording permissions, or any sort of keylogger prevention. That was normal a few decades ago, but the world has moved on since. There's no real reason it can't do any of that, it just doesn't and there are no real plans to add these features. I'm not convinced by the "if you run a program you should assume you've already been hit by a CIA 0day". Obviously nobody is dialing into your X11 server from the internet, but this is a relatively easy nobody:nobody -> root/wm-session/whatever elevation of privilege. |
| |
| ▲ | josephcsible 5 days ago | parent [-] | | If malware is in your X server, doesn't that mean it's running under your user account? And if that's the case, then couldn't it just steal your data right off the filesystem without needing to get it from X? | | |
| ▲ | zahlman 4 days ago | parent | next [-] | | The valuable data on your machine might not be something permanently stored in the filesystem, but ephemerally recorded in a process. Say, a memorized password. | | |
| ▲ | josephcsible 4 days ago | parent [-] | | Couldn't the malware still get it without having to deal with X? E.g., by attaching to your process as a debugger? | | |
| ▲ | int_19h 4 days ago | parent [-] | | Try doing that on a regular Linux install, you might be surprised. | | |
| ▲ | josephcsible 4 days ago | parent [-] | | I assume you're talking about Yama, but that's not universally enabled by default. And even if it is, malware could do something like wait for you to open Firefox, then immediately kill it and launch its own version with its own code already baked in. | | |
| ▲ | int_19h 2 days ago | parent [-] | | It's enabled in all mainstream distros that I know of. I work on debuggers and this is the single most common issue that people report with attach. And yes, if the malware is running under the same account that you use to login, it can do a lot, X or no X. That's where various forms of sandboxing come in. And the problem with X is that it is basically impossible to properly sandbox an X app. |
|
|
|
| |
| ▲ | lmz 5 days ago | parent | prev [-] | | It could be a remote X client on another machine. |
|
|
|
| ▲ | jchw 5 days ago | parent | prev [-] |
| > Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work. Any program you incidentally run within a typical graphical user session will have access to the X socket and a cookie, they will be able to connect. And after they connect... They basically just can do anything they want with zero real restrictions, including most likely some fairly trivial paths to root escalation. Even if they're running inside of a sandbox or container, with only an X11 socket poking through. This problem was realized a very long time ago with the security extension but most of it never really caught on. > Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is. If you believe this is true, then what exactly is the point of any security measure? Why bother using isolation and sandboxing, or passwords? Why does Windows bother patching flaws if they know there are certainly more of them and they will never fix them? Do you by chance also smoke because you're going to die anyways? > What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs. Lol. That's primarily because the Linux desktop is utterly irrelevant, not because nobody would care to do it. Is it really surprising that attacks against desktop computers would focus almost entirely on the OS that has 90+% of the market share? We don't get free software OS desktop malware for the same reason we don't get free software OS software ports. Watching and waiting with security was a totally acceptable position in the 90s, but we get the general gist these days. We need security-by-design. On the server side of Linux where Linux is relevant, the situation is much more impressive; auditing using eBPF, sandboxing with gVisor, microVMs with Firecracker and cloud-hypervisor, isolation using namespaces and seccomp-bpf and more. On the desktop side, people are still arguing over whether or not it's a problem that any X client can by default silently keylog the entire system trivially. Okay, but a lot of us actually see that as a problem, and we're not interested much in "hearing you out". Most of us recognize that the Wayland protocol has warts (and too many damn protocols), but X11 has many more warts. I didn't care what was the successor to X11 specifically, I just cared that we eventually made some progress. Most people have nothing to offer here and just suggest we should've stuck with X11. Okay dude, but nobody wants to. The X.org devs would like to move on. The desktop environments really would like to move on. There was basically one serious guy that actually wanted to work on improving X11 and he turned out to be kind of crazy and couldn't stop breaking shit anyways. |
| |
| ▲ | zzo38computer 5 days ago | parent | next [-] | | You could use a proxy server (regardless of the protocol), which might improve security (and other things) better than other methods do, I think. There are problems with both X11 and Wayland, although I dislike some of the features of Wayland. | | |
| ▲ | jchw 5 days ago | parent [-] | | Yeah, with Qubes that's exactly what they do. I forget what the software is called, but they use an X11 proxy that tries to enforce policy. That said though, that does require you to proactively run every X application with this sandboxing. For Qubes which forces everything into VMs this is doable, but for most other systems there isn't an obvious way to handle this sort of thing. My only major complaint about Wayland that can't just be fixed relatively easily is Mutter refusing to support SSD. (Well, the actual technical problem could be fixed relatively easily, but the social one not so much.) | | |
| ▲ | fpoling 5 days ago | parent [-] | | Firejail uses nested X11 servers like xeohyr or xrdp to restrict application access to the primary X11. | | |
|
| |
| ▲ | zahlman 4 days ago | parent | prev [-] | | > including most likely some fairly trivial paths to root escalation Why would this be likely? | | |
| ▲ | jchw 4 days ago | parent [-] | | Because there is no isolation whatsoever. A terminal running as root can just be typed into. Some apps can be coerced into code execution when messaging them over X11. You might have to get a little creative, but there's a lot of room for creativity. Needless to say, though, if the user doesn't have anything open with root privileges or cached sudo, then you probably won't be escalating to root with only X11. You'd have to wait for something to crop up. I'd reckon though if you are resident for long enough during a desktop session you'll find an opportunity. (And on most desktop systems that still, of course, leaves the usual points of interest outside X11. But if you wanted a way to escape, say, Flatpak containment, this is definitely a good start.) |
|
|
