Wayland Keylogger
github.com
github.com
Forget this keylogger. All you need is to somehow write a single line into .profile or .bashrc, which basically every executed program can do, and you own the user account. You can intercept every program with wrappers by changing PATH or adding desktop entries in .local/share/applications, extract all data from applications, use LD_PRELOAD like shown in the submission ... the possibilities are endless.
There isn't even a single decent dynamic firewall with those annoying popups.
Apart from SELinux, there is also firejail [1], which I use to sandbox browsers. Flatpak and Snap are also trying to solve both the packaging and the sandboxing aspect, with moderate success. They also increase the risk due to lack of centralized package ownership, so require a very solid sandbox.
The only reason why the Linux desktop is somewhat secure is the reliance on official package repos, the trustworthiness of the open source communities, and the and the relatively small target group.
I do believe that the path forward has to be Mac OS/Android/iOS style sandboxing - especially for everything not directly from an official repo, but there seems to be relatively little interest in the ecosystem.
Non Linux specific sidenote: ever notice how many VS Code extensions download random binaries from the net? Or just that they can execute arbitrary code? Compromising one of those could lead to some glorious returns for malicious actors, with potential access to lots of source code, credentials and internal networks.
Bottom line: if you touch any sensitive data or work with secure systems at all, you have to be extremely paranoid about your machine - no matter what OS you are on.
On a more practical level: if the statement indeed eventually be phrased so that it does come with the technical truth, the practical gains are not of security, but performance, and only when not using nVidia cards.
Better phrased, it is:
> The current state of Wayland is that it allows for better hardware acceleration when sandboxing on X11 , except with nVidia cards, where on many compositors it does not allow allow for hardware acceleration at all.
X11 allows for similar sandboxing by way of a nested server, but hardware acceleration is insufficiently implemented as of this moment. — this is not a theoretical impossibility and it could be implemented; it simply isn't fully, at this time.
In theory it could also allow for finer tuning in deciding what is visible within what nested server, but that hasn't been implemented yet.
Many Wayland compositors simply lack support for nVidia cards as they use a different protocol than all the others, and many graphics acceleration calls are simply not implemented through nested servers.
Modern X11 compositors work on very similar principles. — the only difference is the Wayland protocol requires that there be such a compositor, and on X11 one is free to even use outdated server drawing calls that have not been used for decades.
- features the trap–bath split
- is non-rhotic, has a fairly consistent linking-r, but no intrusive-r.
- ordinarily features the whine–wine merger, but does split them again in stressed interrogatives
- does not undergo flapping of alveolar stops
- ocasionally realizes fortis alveolar stops as glottal stops intervocallically, but never in a stressed context
- realizes fortis alveolar alveolar stops as affricativess before /u/ and /i/ in a stressed context, rather than as aspirates
- features l-vocalization in the coda of syllables
- features neither yod-dropping nor yod-coalescence such that “soot” “shoot” and “suit” are a minimal triplet
- fronts /ai/ to a realization of [ɑe̯]
I know of no actual English dialect that combines these features, as expected of a non-native speaker, with the exception of it's non-rhotic nature, it seems to gravitate towards a realization that mostly combines the different kdistinctions made in most dialects, assimilating splits, but not mergers.
> "The wayland tag line is "every frame is perfect", by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker" -- Kristian Høgsberg, creator of Wayland [1]
Input handling and related issues are mere afterthought in comparison.
Besides that, this project is not really keylogging Wayland in any meaningful way. Wayland compositor sends the key events to the application and its the applications responsibility from there on to do whatever it pleases; in this case it printing them to stderr but that is incidental. Wayland can't just magically protect you from having malicious code running within your application.
edit: a strained analogy, but this thing is akin to saying that "you can eavesdrop https" and then show ld_preload hooks for intercepting openssl calls.
[1] https://www.phoronix.com/scan.php?page=article&item=xorg_way...
Well, it would be fair game if it were popular to discuss how HTTPS helps against malicious local programs, like it is pretty popular with Wayland.
I really like it, though. New applications have to ask whether they can read/write from ~/Documents or ~/Pictures, or read contacts. I agree with you, and also wish something like this existed for modern Linux desktops.
The permissions are not interactive, you can set them once and forget.
The same of course applies to giving it access to the file system.
Something so simple as an audio manipulation application must have access to the filesystem, unless one only will it to be able to save within a specific subsection thereof, and if it be granted such access, it can now edit whatever file stores whatever application has whatever permissions, thus giving itself full permissions.
The further problems with this scheme are that it's not entirely clear where the limits of one “application” lies which would have to be defined.
It makes a great deal of assumptions that may not be true.
This is also a problem with Linux capabilities. — I remember well an explanation where the auctor demonstrated how in about 2/3 of all Linux capabilities, they, or in combination with one other capability were sufficient to escalate to full root access on almost any modern normal system.
Many of these security restrictions are theoretical of nature, and on most systems amount to very little against a sufficiently skilled attacker, but do inspire a false sense of security.
> but it would give me some comfort.
And that is what it seems to truly be for: not making the user safe, but making him feel safe, and the latter often has a negative influence on the former.
How do you figure? There are systems already (like Wayland) where default access to input only gives you input when the app is active, and entire different process is required for global hotkeys or key logging.
There are no nice GUIs to manage that AFAIK, but this is not an impossible problem to solve anymore.
> The same of course applies to giving it access to the file system.
uh, what? no. giving a browser access only to "~/Downloads" will work great and will make it much more secure.
The modern Linux is much more than capabilities and user-based permissions. A mount namespace with selectively bind-mounted dirs can do wonders for security. And things like "bindfs" which can translate UIDs on the fly can give even more isolation.
That's not what is commonly understood as access to the input system.
> There are no nice GUIs to manage that AFAIK, but this is not an impossible problem to solve anymore.
So long you be willing to live with a walled garden environment where one's text editor either can't edit the files on one's system any more, or is given sufficient permissions to circumvent all of this regardless.
> uh, what? no. giving a browser access only to "~/Downloads" will work great and will make it much more secure.
It would also mean that no modern browser works any more since they need access to far more to even start up.
You should `strace` a browser and be surprised that it constantly needs to read and write files from all over the system.
I would also be rather annoyed with a browser that can only save files in one folder rather than wherever it please me.
Finally, even if this browser only have access to `~/Downloads`, it would still be capable of modifying any file that something else put there, thus allowing it to easily install malware into anything that anything els downloads, without the user's knowledge.
> The modern Linux is much more than capabilities and user-based permissions. A mount namespace with selectively bind-mounted dirs can do wonders for security. And things like "bindfs" which can translate UIDs on the fly can give even more isolation.
There is a good reason that SELinux never truly penetrated: — it is capable of much of this, but it would also make most applications unworkable and users would complain about no longer being able to do as they will.
More or less what the situation is on Android, or Windows.
Then most apps have no need to have access to the input system.
> So long you be willing to live with a walled garden environment where one's text editor either can't edit the files on one's system any more, or is given sufficient permissions to circumvent all of this regardless.
Sandboxing does not mean the OS cannot extend the sandbox on demand in response to user consent.
> You should `strace` a browser and be surprised that it constantly needs to read and write files from all over the system.
These should be enumerable.
> I would also be rather annoyed with a browser that can only save files in one folder rather than wherever it please me.
See above for sandbox extensions.
I never said as much; I simply said that giving them access to it is tantamount to giving them full access, and that many other such privileges also are.
Eventually, the list is so large that many applications need access to at least one thing from which they may escalate to full access.
> Sandboxing does not mean the OS cannot extend the sandbox on demand in response to user consent.
The point is that as soon as one have given the text editor consent to write to arbitrary text files on the system, one has given it full access as now it can edit the file that contains these permissions.
In the alternative, one has to grant it access to files, or directories, on an individual basis with every save, which is something users will quickly grow tired off, especially if it be configured to periodically save.
> These should be enumerable.
They are, and users will quickly complain that it becomes unworkable to grant access to each of these individually.
> See above for sandbox extensions.
I would also become annoyed very quickly if I had to give permissions again every time I wanted to save elsewhere.
And you didn't address the fact that if he browser have recursive write permissions to the `~/Downloads` folder, it can alter anything that any other application downloaded to it, and thus install whatever malware it wish in there.
What you want can work in theory, but few users would be willing to live with their the extreme reduction in quality of life and productivity, or walled garden that results from it.
> Eventually, the list is so large that many applications need access to at least one thing from which they may escalate to full access.
This makes zero sense. If an app wants access to keylogging APIs, then it better be an app where it makes sense to be able to keylog other apps. 99% of apps have no reason to do this and have no need for full access.
> In the alternative, one has to grant it access to files, or directories, on an individual basis with every save,
No, the alternative is that you give the application access to a file and now it owns that file.
> And you didn't address the fact that if he browser have recursive write permissions to the `~/Downloads` folder, it can alter anything that any other application downloaded to it, and thus install whatever malware it wish in there.
You can deny the browser the ability to read or write to the directory in general, but it may create new files and have permission to those.
Overall, it is eminently possible to make useful software, perhaps even most useful software, that operates under a reasonable sandbox.
There's a reason that only a small minority of software can even run in such sandboxes without failing to work as intended or indeed pestering the user with dialogs for permission every second, and of many that can run in them, it's a security theatre that doesn't help if the software truly were malicious.
Are you running your text editor, terminal, IRC bouncer, or audio server in such a sandbox?
> This makes zero sense. If an app wants access to keylogging APIs, then it better be an app where it makes sense to be able to keylog other apps. 99% of apps have no reason to do this and have no need for full access.
There are, as said, far more things they need access to that can escalate to full privileges quickly:
- access to write arbitrary files owned by the user
- access to read from arbitrary ports that the user owns
- access to ptrace arbitrary processes the user runs
- access to edit the `PATH` of the user
> No, the alternative is that you give the application access to a file and now it owns that file.
Do you frequently use your text editor to edit one file, and one file only?
Give it access once to edit a script you wrote, now it owns the file; say it be malicious, it now changes the script so that next time it is executed, it allows for arbitrary code to run.
Not to mention having used it once to edit the initialization or environment variable files and user profiles.
> You can deny the browser the ability to read or write to the directory in general, but it may create new files and have permission to those.
In which case, it can exploit a race condition to replace a file that was created by something else immediately after the other software unlinks it to recreate it under the same name to trick the user.
It can also then create a symbolic link to trick other applications and gain write permissions of files it shouldn't have since almost no software is secured against such symbolic link attacks.
> Overall, it is eminently possible to make useful software, perhaps even most useful software, that operates under a reasonable sandbox.
It is, so long one be willing to forgo having basic control of one's system.
Android does it, as said, but in Android, the user does not enjoy such control, by design.
Again, it seems like you have not used macOS.
> Are you running your text editor, terminal, IRC bouncer, or audio server in such a sandbox?
What I am doing is not particularly relevant, given that I have needs that require me to run with SIP disabled (which, due to rather unfortunate design choices, means there are relatively trivial ways to escalate to root). However, there are many popular text editors that are sandboxed, for example the built-in TextEdit or CotEditor (which ships on the Mac App Store, to boot!). Terminals usually do not run in sandboxes for obvious reasons (although, many people are happy with the ones that run on iOS, so…). I don't run an IRC bouncer or audio server but I would certainly like it to run in sandbox, and can see a very clear way to have them do so.
> far more things they need access to that can escalate to full privileges quickly
The number of applications that need to do the things you mentioned are few are far between. I mean, honestly, does anything need to ptrace an arbitrary process other than a debugger? I think there is exactly one process on my computer that can edit PATH for my user…
> Do you frequently use your text editor to edit one file, and one file only?
Uh, is this not how you use a text editor?
> Give it access once to edit a script you wrote, now it owns the file; say it be malicious, it now changes the script so that next time it is executed, it allows for arbitrary code to run.
> Not to mention having used it once to edit the initialization or environment variable files and user profiles.
Yes, but again: user consent. If I give an app the ability to access a file, then it can access the file. If I don't, then it can't touch it. This is clearly better than "the app can do everything".
> In which case, it can exploit a race condition to replace a file that was created by something else immediately after the other software unlinks it to recreate it under the same name to trick the user.
> It can also then create a symbolic link to trick other applications and gain write permissions of files it shouldn't have since almost no software is secured against such symbolic link attacks.
Who said anything about this identity being tied to the filename, or even enforced by the application itself? Validation is done correctly in the kernel, of course.
Still, few programs need to change PATH, open arbitrary ports or ptrace other processes. These scenarios are so special that they should require explicit user approval. Also, apart from text editors, most programs don't ever need to access arbitrary files from the file system.
Android being locked down is a distributor's decision. They have average users in mind that might not ever need nor want to fiddle around on their system with a debugger and a text editor.
> if [t]he browser have recursive write permissions to the `~/Downloads` folder, it can alter anything that any other application downloaded to it, and thus install whatever malware it wish in there.
The solution is to give each program which uses Downloads folder its own folder. On my system, I think there are about 2 programs which can write to that folder, so this is not that much.
If it really bothers you that you have ~/Downloads/Firefox and ~/Downloads/Chromium, then there are things like mhddfs which "merge" two directories -- browsers actually save to `~/.downloads/Firefox` and `~/.downloads/Chromium` and you have a single unified "~/Downloads" folder which shows files from both.
You are thinking again about old-style permissions control -- like SELinux. Yes, they are not going to work well, as you cannot really deny .cache access.
But this is not what we do in the modern system. You start a new mount namespace, and then mount a new tmpfs over /home. Then you bind-mount outside ~/.config/protected-firefox-profile to a ~/.mozilla inside the sandbox. And you expose ~/Downloads as-is.
And then you run firefox in that sandbox -- none of the system calls fail, any file which was written can be read back (sometimes only until the browser restarts), but your ~/.bashrc is totally safe.
You can improve this as much as you want. For example, want a private /tmp except shared /tmp/.X11-unix ? Sure. Want to hide your /etc and /var except few selected files? no problem.
This still assumes that there is a "sandboxed" and "non-sanboxed" parts of the account. You'll restrict more dangerous programs, like browsers, network clients, and games -- and leave things like text editors unrestricted, so there is no problems with editing text files.
Oh, and the thing that I am described are not some theoretical TODOs -- they are all supported and usable. I am running my own system made out of shell scripts and duct tape, but there are products out there like firejail [0] which implement all that.
But yes, it's true that issues with the cache can be resolved with this, but not saving outside of a single file path, and whatever utility that then moves the file outside of that single path would still need full permissions or be granted permissions.
It can be done, but at the cost of a great deal of convenience and restrictions.
But practically, as a person who runs sandboxed browser daily, it there is not "a great deal of convenience and restrictions". Even before sandbox, I'd download files to default location and later move some of them elsewhere -- so this is not really changing. A requirement to place files which need to be uploaded into a shared folder is somewhat annoying, but I found out that I don't upload that many files from browsers anyway.
Now you are moving goalposts. Initially, you were discussing restrictions on the file system.
I concur that the current desktop security model is probably unfixable. All the tools to improve on it are here though. Android kinda solved it by restricting every app to its own assets and files by default. If the app needs more, it has to ask for permissions.
The problem with user approval for every single action is decision fatigue. It is already happening on Android: every app is asking for a ton of permissions. And it turns out that many of them are not granular enough. For example, Signal needs the numbers from the address book to find contacts, but nothing else. If I want that feature, I still have to give Signal access to the entire address book.
I already use strace to understand what programs do but it would be great if I could also intercept these calls in real time. Just keep the program waiting until I approve its open system call on that specific file.
That's basically how strace is implemented anyways.
Smaller than you imply as there is no standard Linux desktop for them to target. Not only are there multiple desktops, there are multiple systems for almost everything in Linux. Even seemingly ubiquitous things like .profile and .bashrc aren't everywhere as neither zsh nor fish use those.
TLDR; I think the diversity of the Linux world also helps.
And can just check for .bashrc, .zshrc and whatever the popular shell uses.
The diversity argument is moot. If anything it just prevents software from being available on Linux due to small differences causing big inconvenience for business software authors to be worth the hassle. From security perspective, most of Linux desktop is Glibc + almost same set of base C libraries + SystemD + Sudo + GNOME/KDE whatever. Having 2-3 choices cover 95% is not a barrier for security exploits.
Rob Pike told in 2000 that Linux has put back computing. It's not exactly Linux but the so-called "community" with their luddite attitudes.
Linux Desktop is a cult.
even benign apps that phone home like pulumi and terraform are fun to see and block with annoying popups.
monitoring egress really is the only realistic play. i rolled my own[1], inspired by opensnitch[2].
netfilter_queue is really great, and definitely makes annoying popup dynamic firewalls possible.
1. https://github.com/nathants/tinysnitch 2. https://github.com/evilsocket/opensnitch
Things will break from time to time until you modify the default profiles, and you will need to write profiles for applications that do not ship with one by default, but it is worth the time you spent.
[1] A MAC just like SELinux, but with easier syntax. It is the default on Ubuntu, Debian, OpenSUSE, and others.
[2] I think Fedora does enforce SELinux by default, though.
No this would be exactly the wrong path. One of the major strengths of FOSS/Linux is the fact that there are multiple authorities checking the code for bugs and security issues. You usually have at least three stages: contributor -> release manager -> package maintainer. On some distribution you even have a dedicated security team. And on top of that, since it is FOSS you have full synergy across the whole ecosystem. Which means e.g. if the Debian security team finds a bug the Arch team can correct the problem within hours.
FOSS needs to play it's strengths and the fact that the general case is running trusted software whereas the exception is running untrusted software is one of those major strengths. Which means additional complexity and user annoyances stemming from overarching access control measures only apply selectively to a small set of programs.
Responsive package maintainers do not help in any way with Firefox zero days, vulnerable codec parsers in MPV, a weird LibreOffice extensions scanning all my files and sending it to a server, or a VS code extension downloading and running random binaries.
I want to get my packages from a trusted central repository. AND I want most of applications to be sandboxed and have restricted access permissions to the filesystem and network.
There is no reason why repos can't package desktop applications in a way that runs them inside a sandbox by default, whatever the concrete implementation is, with me also having the ability to run randomly downloaded binaries with the same security guarantees.
Despite the claims otherwise (with 0 proof), FOSS has next to no advantage in the security realm vs proprietary stuff. At the very least the security guaruntee you get from open source code, is that you have the ability to verify the code (and not pre-compiled binaries you get from the project's website) has no backdoor or otherwise malicious crap in it.
$ whoami
admin
$ sudo -- sh -c 'f="/home/admin/.bashrc"; chown root:admin $f; chmod 640 $f ; chattr +i $f'
$ ls -al /home/admin/.bashrc
-rw-r----- 1 root admin 1445 Jan 31 09:53 /home/admin/.bashrc
$ rm /home/admin/.bashrc
rm: cannot remove '/home/admin/.bashrc': Operation not permitted
$ echo "writing?" >> /home/admin/.bashrc
-bash: /home/admin/.bashrc: Operation not permittedThis is the right takeaway. Unfortunately, given the previous paragraph and the name, I suspect a lot of people are going to think "Wayland is insecure, so why bother?". The reality is closer to "many parts of Linux are insecure, and Wayland closes one of the holes".
The problem with it is, that it works fine when one purely speak of being able to write and read from files, but the moment servers such as display servers or Pulsaudio and DBus come into play, the picture becomes more difficult.
All of those technologies work on a simple binary level where the subuser has access to the socket, or it does not, for finer grained control the kernel is required to speak the protocol, which will obviously not happen.
So, those services themselves must come with a means to filter communication appropriately, and sandboxing technology is beholden to the extent thereof.
Flatpak had to provide an alternative DBus-proxy server to do this with DBus, similar to using nested X11 servers; no solution has been reached for Pulseaudio, whereof I know, and no plans even exist for a variety of more obscure servers that software might need to communicate.
For instance, ZNC can be instructed from the IRC client to load modules that contain arbitrary code. Therefore, any IRC client that has acces to ZNC has ZNC's full capabilities, as it does not come with such finer granulation as of this moment.
If any sandboxing technology is to be effective, a large number of servers that are in common use often need to provide specific support for that specific sandboxing technology, or simply not be accessible at all from within it.
Pulseaudio is not getting much work these days, I believe the work currently is happening in Pipewire, which was built to have a fine-grained permission system that can work with any sandbox and is backwards-compatible with Pulseaudio.
I'm not sure how your IRC bouncer would work there, but presumably if you sandboxed that, it only needs to talk to the IRC socket and nothing else. For other obscure servers that have no concept of security, I'm not sure what can be done about that if nobody wants to modify them or replace them. You might just have to accept that they will need to run at elevated privileges and can clobber your system or home directory.
The security considerations in Wayland are primarily aimed at not being a weak link undermining sandboxing efforts, which is the case with X11.
Without sandboxing, writing to e.g. ~/.profile would in most cases be enough for a malicious application to take over the machine. Equivalents apply to all platforms.
which is not really a step forward since now I have do go and sandbox every app.
It's a step forward because you can, but it's ultimately up to you. You're still better off with Wayland, but no matter what you use, there's a huge glaring security hole if things are not sandboxed.
Let's be honest with LD_PRELOAD you can currently get pretty much anything.
Through you can setup SeLinux to make such attacks impossible or at least much harder needing other vulnerabilities/insecure design to succeed.
But some programs abuse LD_PRELOAD for various reasons.
Also there are so many other ways to undermine security that once you locked everything down Linux became supper hard to use.
The funny think is, non of this attack vectors are a major problem for server/embedded or similar non-desktop Linux use cases. As in them you can normally run a hardened Linux, where such attacks simple are not possible.
It hints to how Linux is not really designed as a desktop system. And IMHO is fundamentally unsuited to become a modern desktop (or handy) OS without changing it so much, that's not really Linux anymore. This is also why I never had much hope for the libre phone.
Of course if you run the programs under same account you can keylog them. You can also connect to Chrome and steal the cookies directly, wrap terminal to install pty loggers, backdoor ssh and so on.
The real point of wayland security is you can safely run multiple user accounts on the same desktop. And the LD_PRELOAD tricks (or PATH tricks etc..) do not work across accounts, unless you are doing something stupid.
I wish people would stop saying silly things like "But for any possible way to break it, I could add countermeasures as well. Applications could use 'getenv' ....". That's not how you break keyloggers! You break them with privilege separation. The least-code version would be:
1. Create a separate user for web browsing, with its homedir and all
2. Create "/etc/sudoers.d" entry to launch browser which does not require password, but also does not allow any arguments, enforces HOME and only passes through a small subset of env vars
3. Launch your browser with "sudo -H -u browser-user firefox". Make it a desktop shortcut or something so you are not tempted to enter your password if someone messes with the shortcut.
that's it -- this will stop this attack, and many others, cold. And will not require any SELinux.
The point is that Wayland security is useless because the security boundary on Unix is fundamentally the user account:
> Of course if you run the programs under same account you can keylog them. You can also connect to Chrome and steal the cookies directly, wrap terminal to install pty loggers, backdoor ssh and so on.
> The real point of wayland security is you can safely run multiple user accounts on the same desktop. And the LD_PRELOAD tricks (or PATH tricks etc..) do not work across accounts, unless you are doing something stupid.
If this indeed be the point, then I ask you to come with a single official Wayland reference that promotes it as such and phrases it as such, as that is not the point the advocates make at all, and they phrase it simply as “One can no longer be keylogged by malware.”, which is a very dubious claim.
Once malicious software has been executed as one's user, that is the end of it, and one's entire account can now be treated as forfeit, and Wayland does nothing, and cannot do anything due to the fundamental designs of Unix to stop that.
Furthermore, there are already quite a few mechanisms on X11 to achieve what you illustrated. — that does not mean that Wayland is useless, it simply means that it does not provide a solution to any existing problem in this specific field that is not provided elsewhere.
There are two common claims that are very frequently made by official sources such as GNOME that are false:
- X11 cannot be sandboxed.
- With Wayland, one cannot be keylogged.
> that's it -- this will stop this attack, and many others, cold. And will not require any SELinux.
Yes, never running malicious code with the privileges of one's user would stop it from gaining access to said user, but the promises of Wayland are protections even if the former have happened. — this is false advertisement.
The offical Wayland reference does not talk about malware at all, as this is not not something that windowing protocol can solve. The best they can do is to promise "client isolation" -- which means that one client cannot affect other via wayland protocol
I am sure there are some Wayland advocates somewhere who are making dubious claims. This does not mean the Wayland security is useless -- this just means that specific systems are not secure yet. People on the internet can claim all sorts of crazy things, and you should not hold what random bloggers say against the whole system.
Re X11 sandboxing, from my reading, the general opinion is that X11 is impossible to secure. They did SECURITY extension, but it apparently does not work well, see this wonderful quote from Debian's ssh manpage [0]
> Debian-specific: X11 forwarding is not subjected to X11 SECURITY extension restrictions by default, because too many programs currently crash in this mode.
What other X11 isolation mechanisms are there? Xnest breaks seamless window switching, things like VNC introduce a ton of latency.
So before the Wayland we did not have a desktop with solid client isolation, so not one cared about process isolation either. What's the point of running browser from trusted account if any random desktop app can steal its keystrokes? The best one could do was Quebes OS, and this had plenty of its own overhead.
Now with more people switching to Wayland this should help. It's far past the time that people stop assuming that "one human user" == "one entry in /etc/passwd" and start separating services by account.
[0] https://manpages.debian.org/buster/openssh-client/ssh.1.en.h...
It can also be configured to use Xephyr.
In X11 I can just make use of 'xhost si:localuser:browser-user'. But it seems that I would need to give full access to my main user's XDG_RUNTIME_DIR (/run/user/1000/), so that it can access the 'wayland-1' socket from the browser user. Is there a better way to do this?
There's plenty of malware in Linux; it's just never called malware. I'm generally more wary of installing random software on a Linux box than I am on my personal macOS machine.
When I ssh into a customer's machine to discover a bitcoin miner that is definition of malware; and there have been plenty of exploits that involve shodan style scans that take advantage of server software with poor defaults.
Look, if you have user access to the account, you can get its data. Even if you somehow make Wayland 100% secure, you can still replace “firefox” shortcut with malicious version which also steals all your passwords. No windowing aystem involved at all.
It's the difference between having a poor quality lock on your door and having no door at all.
As for dropping events... the idea is to isolate clients, such that it's as if X resources not owned by the client do not exist to the client. If the UX of the client depends on violations of that rule, then it's either a program like a window manager that should go on a trusted whitelist, or it's up to something nasty.
Note that Firejail does this by using Xpra as a proxy to the real X server.
-simulated keyboard/mouse input (some progress recently with some composers)
ability to inspect window attributes (e.g. window title, executable and handle)
ability to manipulate windows (e.g. maximise, close, etc)
Considerations do need to be made in the framework / protocol for accessibility. I'm hoping the situation has changed. Possibly someone could comment on that.
Fedora Silverblue/CoreOS look like a massive step in the right direction which no other mainstream distros are working on.
Fedora also seems to be the only distro willing to set sane defaults for everything (SELinux, Wayland, CGroupsV2, soon to be pipewire, python 3) while every other distro waits around for someone else to make the first move.
How recently? Ubuntu 20.04 dropped python 2 completely.
except for fedora they don't support selinux well
https://devblogs.microsoft.com/oldnewthing/20200318-00/?p=10...
Wayland does not allow programs to use the Wayland protocol to snoop on other programs. X11 does allow this. That's the key distinction. Wayland does nothing to prevent programs from snooping on each other using any of the other features of your operating system. Wayland is only one part of a secure system.
I wish we'd stop having this fucking keylogging discussion already.
To limit what malicious software that runs as one's user can do, one must limit what the user can do, and that's exactly what they attempt to do.
I personally præfer that the user be trusted to be wise enough to run software that he does not trust in a contained environment, and he be given the freedom to control his own environment as he pleases.
This is completely untrue. You can gain root access on Android and have full access to do anything while still keeping applications sandboxed. Limiting user freedoms is simply an extra thing that came with new mobile OSs.
Many “users” on Unix do not correspond to any particular physical human being.
Windows has the normal desktop that shows your programs and separate desktops for special purposes. There is a desktop where your screensaver runs. So if your screensaver crashes it is not possible for your screen to show up.
Another desktop is where the login screen is on. Normal programs can’t connect to that desktop so they can’t capture your keystrokes as you type your password.
This isn’t about ‘walled gardens’.
Yet the most common way to denigrate Xorg is to assert that Xorg is basically a keylogger. Which might be true, but as this post shows just switching to Wayland doesn't offer any additional protection under the key-logging point of view.
You might combine a sandboxing technique with Xorg too, by the way.