22 ms·

I do use Linux (almost) exclusively, but I'm well aware of the security limitations. Forget this keylogger. All you need is to somehow write a single line into

I do use Linux (almost) exclusively, but I'm well aware of the security limitations. 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. [1] https://firejail.wordpress.com/ https://firejail.wordpress.com/

Jkvngt 6y ago
Forget it? It’s the main selling point of Wayland that keyloggers are impossible.
- deleted 6y ago
  [deleted]
- Blikkentrekker 6y ago
  It's hardly the main selling point, but yes, it's often stated in such language that is sufficiently bereft of technical specifics so that the lay user reading it will gain the impression that the aforementioned proof of concept is not possible, but also that, when præsented with it, semantics arguments can be fronted that are more technical, to allow a statement that it wasn't so intended. 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.
  - Spivak 6y ago
    Giving every application its own X server kinda works but it breaks all the same things that Wayland does. The idea isn't all that different than XWayland.
    - Blikkentrekker 6y ago
      The difference is that it's optional rather than globally enforced. 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.
  - erik_seaberg 6y ago
    As I understand it, Wayland doesn't define a protocol for using the server's hardware to render. Waypipe requires rendering at the client (probably in software, because datacenter GPUs are a rare extra) followed by a video codec for remoting.
    - Blikkentrekker 6y ago
      Yes, in both cases it is not not for technical reasons. 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.
      - erik_seaberg 6y ago
        What I’m getting at is that Wayland has better hardware acceleration only of compositing. It doesn’t seem to have any support for rendering shapes into pixels, even though that’s mostly why hardware accelerators were invented.
        Blikkentrekker 6y ago
        As far as I know, there is no technical reason why Wayland would have better hardware acceleration. 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.
- josefx 6y ago
  How does that interact with things like the steam overlay were a third party UI is hooked into an application? I would expect that either that functionality is completely broken or that you could still implement keyloggers going this route.
- Spivak 6y ago
  The selling point is that it becomes possible to have a system that's resistant to keyloggers. If the rest of the system is secure then Wayland doesn't undo that unlike X.
- bartvk 6y ago
  What is "2021" about this Github repo?
  - Jkvngt 6y ago
    The fact that the logger still works great.
- zokier 6y ago
  The main selling point of Wayland is the simplification of graphics pipeline > "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_wayland&num=1 https://www.phoronix.com/scan.php?page=article&item=xorg_way...
  - owl57 6y ago
    > 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. 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.
- canofbars 6y ago
  There are like 10 weak points in the linux security model. Wayland plugs one of them but there are still a bunch of ways around it. Yes any program you install from the package manager can still see everything but wayland combined with flatpak and SELinux gets really close to a secure system similar to MacOS.
Kaze404 6y ago
I would love to see a real permission system on Linux, where applications have to explicitly ask me before accessing things deemed important. It's never been a problem for me, but it would give me some comfort.
- psanford 6y ago
  For non-opensource applications (e.g. Zoom) I really like using Firejail[0] to run them within a sandbox. Firejail ships with a good set of default policies which make it explicit what the application gets access to. The filesystem sandboxing is especially comforting. [0]: https://firejail.wordpress.com/ https://firejail.wordpress.com/
  - solarkraft 6y ago
    What are the security downsides of Firejail vs. Flatpaks? Complexity wise the former looks wildly more preferable.
- bartvk 6y ago
  This was introduced in macOS at some point (Catalina release?) and I saw a whole bunch of people complain about the number of dialogues they had to go through. 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.
  - hrjet 6y ago
    Try flatpak with flatseal The permissions are not interactive, you can set them once and forget.
- Blikkentrekker 6y ago
  It would be both annoying and somewhat useless, for giving an application access to the input system gives an application access to everything because then it could give itself access to everything. 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.
eikenberry 6y ago
> relatively small target group 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.
- owl57 6y ago
  Is it really that diverse? If you just assume Linux=Ubuntu+bash, sure, you lose some users, but is it really a large part of them? (OTOH you definitely can't assume people run a supported version of Ubuntu and not something ridiculously old.)
- higerordermap 6y ago
  Bash is like 70% of Linux users. 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.
nathants 6y ago
> There isn't even a single decent dynamic firewall with those annoying popups. 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 https://github.com/nathants/tinysnitch 2. https://github.com/evilsocket/opensnitch https://github.com/evilsocket/opensnitch
jamesponddotco 6y ago
Aside from wrapping applications with Firejail, I would also recommend setting up AppArmor[1] or SELinux in enforce mode, as most Linux distributions do not do that by default[2]. 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.
- fsociety 6y ago
  This is good advice! I’ve heard many engineers bemoan setting up SELinux policies however they’ll dump a non-trivial amount of time into security theatre.
sprash 6y ago
> I do believe that the path forward has to be Mac OS/Android/iOS style sandboxing 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.
- the_duke 6y ago
  This is not mutually exclusive. We need both. 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.
- rstat1 6y ago
  And yet so many critical open source projects have had majorly serious security bugs that have gone undiscovered or unfixed FOR YEARS. 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.
matheusmoreira 6y ago
There's also the fact the installation instructions of way too many open source projects consist of piping code downloaded from the internet straight into bash. A lot of people are probably used to doing that: they assume it's trustworthy just because it's open source and on GitHub. It's the perfect vector.
girvo 6y ago
A VSCode extension attempted to read/write to my contacts and calendar on macOS. Thankfully the sandbox (?) permissions UI notified me, I reported it to Microsoft and I believe they either pulled it or wound it back to an older version without that code in it. It had no need to access that data, so god knows what it was trying to do.
intc 6y ago
$ 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 permitted
thekingofravens 6y ago
I love the VS wrapper shoutout. It reminds me of VBA, which can do the same exact things inside excel sheets. I remember working at amazon there were a lot of programs where the entire software was hidden behind an excel sheet using this mechanic. It would literally just be a small Visual Basic wrapper that runs compiled code. It was literally because your end user wouldn't trust software you write unless it was either a web app or an excel sheet. So if it had to interact with excel sheets, why not shove it inside one?

Jkvngt 6y ago

Forget it? It’s the main selling point of Wayland that keyloggers are impossible.

deleted 6y ago
[deleted]
Blikkentrekker 6y ago
It's hardly the main selling point, but yes, it's often stated in such language that is sufficiently bereft of technical specifics so that the lay user reading it will gain the impression that the aforementioned proof of concept is not possible, but also that, when præsented with it, semantics arguments can be fronted that are more technical, to allow a statement that it wasn't so intended. 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.
- Spivak 6y ago
  Giving every application its own X server kinda works but it breaks all the same things that Wayland does. The idea isn't all that different than XWayland.
  - Blikkentrekker 6y ago
    The difference is that it's optional rather than globally enforced. 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.
- erik_seaberg 6y ago
  As I understand it, Wayland doesn't define a protocol for using the server's hardware to render. Waypipe requires rendering at the client (probably in software, because datacenter GPUs are a rare extra) followed by a video codec for remoting.
  - Blikkentrekker 6y ago
    Yes, in both cases it is not not for technical reasons. 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.
    - erik_seaberg 6y ago
      What I’m getting at is that Wayland has better hardware acceleration only of compositing. It doesn’t seem to have any support for rendering shapes into pixels, even though that’s mostly why hardware accelerators were invented.
      - Blikkentrekker 6y ago
        As far as I know, there is no technical reason why Wayland would have better hardware acceleration. 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.
josefx 6y ago
How does that interact with things like the steam overlay were a third party UI is hooked into an application? I would expect that either that functionality is completely broken or that you could still implement keyloggers going this route.
Spivak 6y ago
The selling point is that it becomes possible to have a system that's resistant to keyloggers. If the rest of the system is secure then Wayland doesn't undo that unlike X.
bartvk 6y ago
What is "2021" about this Github repo?
- Jkvngt 6y ago
  The fact that the logger still works great.
zokier 6y ago
The main selling point of Wayland is the simplification of graphics pipeline > "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_wayland&num=1 https://www.phoronix.com/scan.php?page=article&item=xorg_way...
- owl57 6y ago
  > 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. 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.
canofbars 6y ago
There are like 10 weak points in the linux security model. Wayland plugs one of them but there are still a bunch of ways around it. Yes any program you install from the package manager can still see everything but wayland combined with flatpak and SELinux gets really close to a secure system similar to MacOS.

Kaze404 6y ago

I would love to see a real permission system on Linux, where applications have to explicitly ask me before accessing things deemed important. It's never been a problem for me, but it would give me some comfort.

psanford 6y ago
For non-opensource applications (e.g. Zoom) I really like using Firejail[0] to run them within a sandbox. Firejail ships with a good set of default policies which make it explicit what the application gets access to. The filesystem sandboxing is especially comforting. [0]: https://firejail.wordpress.com/ https://firejail.wordpress.com/
- solarkraft 6y ago
  What are the security downsides of Firejail vs. Flatpaks? Complexity wise the former looks wildly more preferable.
bartvk 6y ago
This was introduced in macOS at some point (Catalina release?) and I saw a whole bunch of people complain about the number of dialogues they had to go through. 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.
- hrjet 6y ago
  Try flatpak with flatseal The permissions are not interactive, you can set them once and forget.
Blikkentrekker 6y ago
It would be both annoying and somewhat useless, for giving an application access to the input system gives an application access to everything because then it could give itself access to everything. 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.

eikenberry 6y ago

> relatively small target group 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.

owl57 6y ago
Is it really that diverse? If you just assume Linux=Ubuntu+bash, sure, you lose some users, but is it really a large part of them? (OTOH you definitely can't assume people run a supported version of Ubuntu and not something ridiculously old.)
higerordermap 6y ago
Bash is like 70% of Linux users. 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.

nathants 6y ago

> There isn't even a single decent dynamic firewall with those annoying popups. 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 https://github.com/nathants/tinysnitch 2. https://github.com/evilsocket/opensnitch https://github.com/evilsocket/opensnitch

jamesponddotco 6y ago

Aside from wrapping applications with Firejail, I would also recommend setting up AppArmor[1] or SELinux in enforce mode, as most Linux distributions do not do that by default[2]. 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.

fsociety 6y ago
This is good advice! I’ve heard many engineers bemoan setting up SELinux policies however they’ll dump a non-trivial amount of time into security theatre.

sprash 6y ago

> I do believe that the path forward has to be Mac OS/Android/iOS style sandboxing 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.

the_duke 6y ago
This is not mutually exclusive. We need both. 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.
rstat1 6y ago
And yet so many critical open source projects have had majorly serious security bugs that have gone undiscovered or unfixed FOR YEARS. 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.

matheusmoreira 6y ago

There's also the fact the installation instructions of way too many open source projects consist of piping code downloaded from the internet straight into bash. A lot of people are probably used to doing that: they assume it's trustworthy just because it's open source and on GitHub. It's the perfect vector.

girvo 6y ago

A VSCode extension attempted to read/write to my contacts and calendar on macOS. Thankfully the sandbox (?) permissions UI notified me, I reported it to Microsoft and I believe they either pulled it or wound it back to an older version without that code in it. It had no need to access that data, so god knows what it was trying to do.

intc 6y ago

$ 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 permitted

thekingofravens 6y ago

I love the VS wrapper shoutout. It reminds me of VBA, which can do the same exact things inside excel sheets. I remember working at amazon there were a lot of programs where the entire software was hidden behind an excel sheet using this mechanic. It would literally just be a small Visual Basic wrapper that runs compiled code. It was literally because your end user wouldn't trust software you write unless it was either a web app or an excel sheet. So if it had to interact with excel sheets, why not shove it inside one?