Wayland Keylogger • Hacker News Board

Re: Wayland Keylogger

#71

Post by canofbars » Sun, Jan 31, 2021, 1:17 AM UTC

microtonal wrote: post #14

tubularhells wrote: post #10

SE Linux is enabled by default in Debian, Ubuntu, Fedora and Manjaro (iirc), so I stopped reading at the introduction. The exploit presupposes the lack of this basic hardening.

Of those distributions, only Fedora sets SELinux to enforcing by default. Moreover, AFAIK Fedora (and RHEL) are the only distributions that had wide-scale testing of the reference policy [1] [2]. So, if you enable SELinux with the reference policy on the other distributions that you mention, it is likely that you will run into all kinds of issues. [1] https://github.com/SELinuxProject/refpolicy [2] https://github.com…

Every day I become more and more of the opinion that Fedora/RHEL are the only distros that are actually worth using. I recently installed ubuntu server to see what it was like compared to fedora server and was shocked to see that the python package still links to python 2 (!) despite it already being officially discontinued.

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.

Re: Wayland Keylogger

#72

Post by the_duke » Sun, Jan 31, 2021, 1:17 AM UTC

sprash wrote: post #57

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

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.

Re: Wayland Keylogger

#73

Post by saagarjha » Sun, Jan 31, 2021, 1:27 AM UTC

Blikkentrekker wrote: post #68

saagarjha wrote: post #62

Earlier quoted context omitted.

> That's not what is commonly understood as access to the input system. 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…

> Then most apps have no need to have access to the input system. 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 de…

Your responses make it seem like you have never used a sandboxed app on the Mac, as every single thing you have mentioned has significantly better solutions than you are suggesting as an alternative. Even if you haven't, the things that it doesn't aren't a stretch to come up with and I might as well just list them here:

> 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.

Re: Wayland Keylogger

#74

Post by matheusmoreira » Sun, Jan 31, 2021, 1:36 AM UTC

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'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.

Re: Wayland Keylogger

#75

Post by matheusmoreira » Sun, Jan 31, 2021, 1:42 AM UTC

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.

I want to get notified every time a program performs any type of I/O system call. I want to see the parameters and the data being copied. I also want the opportunity to cancel the system call and even return fake results and data back to the program.

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.

Re: Wayland Keylogger

#76

Post by theamk » Sun, Jan 31, 2021, 1:43 AM UTC

Blikkentrekker wrote: post #59

theamk wrote: post #54

Earlier quoted context omitted.

> giving an application access to the input system gives an application access to everything 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 c…

> 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. 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 wit…

> It would also mean that no modern browser works any more since they need access to far more to even start up.

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.

[0] https://firejail.wordpress.com/features-3/#namespaces

Re: Wayland Keylogger

#77

Post by Blikkentrekker » Sun, Jan 31, 2021, 1:44 AM UTC

saagarjha wrote: post #73

Blikkentrekker wrote: post #68

Earlier quoted context omitted.

> Then most apps have no need to have access to the input system. 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 de…

Your responses make it seem like you have never used a sandboxed app on the Mac, as every single thing you have mentioned has significantly better solutions than you are suggesting as an alternative. Even if you haven't, the things that it doesn't aren't a stretch to come up with and I might as well just list them here: > Eventually, the list is so large that many applications need access to at least one thing from w…

> Your responses make it seem like you have never used a sandboxed app on the Mac, as every single thing you have mentioned has significantly better solutions than you are suggesting as an alternative. Even if you haven't, the things that it doesn't aren't a stretch to come up with and I might as well just list them here:

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.

Re: Wayland Keylogger

#78

Post by theamk » Sun, Jan 31, 2021, 1:48 AM UTC

Blikkentrekker wrote: post #68

saagarjha wrote: post #62

Earlier quoted context omitted.

> That's not what is commonly understood as access to the input system. 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…

> Then most apps have no need to have access to the input system. 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 de…

Sorry, a quick response on one point:

> 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.

Re: Wayland Keylogger

#79

Post by karlding » Sun, Jan 31, 2021, 1:54 AM UTC

matheusmoreira wrote: post #75

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.

I want to get notified every time a program performs any type of I/O system call. I want to see the parameters and the data being copied. I also want the opportunity to cancel the system call and even return fake results and data back to the program. 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 appro…

Isn't this ability basically already provided via ptrace? The tracer can mutate syscall arguments, mutate syscall return values, or even block syscalls. The primitives ptrace provides should be sufficient to implement something like this.

That's basically how strace is implemented anyways.

Re: Wayland Keylogger

#80

Post by saagarjha » Sun, Jan 31, 2021, 2:01 AM UTC

Blikkentrekker wrote: post #77

saagarjha wrote: post #73

Earlier quoted context omitted.

Your responses make it seem like you have never used a sandboxed app on the Mac, as every single thing you have mentioned has significantly better solutions than you are suggesting as an alternative. Even if you haven't, the things that it doesn't aren't a stretch to come up with and I might as well just list them here: > Eventually, the list is so large that many applications need access to at least one thing from w…

> Your responses make it seem like you have never used a sandboxed app on the Mac, as every single thing you have mentioned has significantly better solutions than you are suggesting as an alternative. Even if you haven't, the things that it doesn't aren't a stretch to come up with and I might as well just list them here: There's a reason that only a small minority of software can even run in such sandboxes without f…

> There's a reason that only a small minority of software can even run in such sandboxes

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.