Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wayland Keylogger

github.com

Post reply on HN
Print view View original

31–40 of 121 posts

Re: Wayland Keylogger

#31

Post by bartvk »

Jkvngt wrote: post #12
the_duke wrote: post #5

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_…

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

What is "2021" about this Github repo?

Re: Wayland Keylogger

#32

Post by Blikkentrekker »

Spivak wrote: post #27
Blikkentrekker wrote: post #17

Earlier quoted context omitted.

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:…

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.

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.

Re: Wayland Keylogger

#33

Post by solarkraft »

psanford wrote: post #29
Kaze404 wrote: post #18

Earlier quoted context omitted.

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.

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/

What are the security downsides of Firejail vs. Flatpaks? Complexity wise the former looks wildly more preferable.

Re: Wayland Keylogger

#34

Post by Blikkentrekker »

Kaze404 wrote: post #18
the_duke wrote: post #5

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_…

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.

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.

Re: Wayland Keylogger

#35

Post by erik_seaberg »

Blikkentrekker wrote: post #17
Jkvngt wrote: post #12

Earlier quoted context omitted.

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

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:…

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.

Re: Wayland Keylogger

#36

Post by shrimp_emoji »

Blikkentrekker wrote: post #17
Jkvngt wrote: post #12

Earlier quoted context omitted.

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

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:…

What dialect of English are you using?

Re: Wayland Keylogger

#37

Post by Blikkentrekker »

erik_seaberg wrote: post #35
Blikkentrekker wrote: post #17

Earlier quoted context omitted.

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:…

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.

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.

Re: Wayland Keylogger

#38

Post by Blikkentrekker »

Spivak wrote: post #28
skymt wrote: post #23

Earlier quoted context omitted.

I'm not sure it's even accurate to say that Wayland closes one of the holes when the hole Wayland closes isn't part of the system's security boundaries. It's like installing a deadbolt in a door standing in the middle of a room.

The "user is the only security boundary" ship sailed long ago with, chroot, SELinux, AppArmor, Snap, Flatpak, namespacing. It will continue to be a bumpy ride retrofitting an ecosystem not made for the tighter boundaries but it's still the goal.

Many of those work by running processes under what is effectively a subuser.

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.

Re: Wayland Keylogger

#39

Post by nathants »

the_duke wrote: post #5

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_…

> 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 2. https://github.com/evilsocket/opensnitch

Post reply on HN