5

There is an application, Zoom, which depends on software known as ibus. After installation, ibus likes to autostart. I don't want ibus to autostart. I've removed autostart files that start im-daemon from ~/.config/autostart and /etc/xdg/autostart, but the application still starts. I've searched for systemd services and found none which start ibus. If I log out and log back in, the application starts again. How can I find the source and stop this malware-emulating software from autostarting? I'm on Debian 10 Cinnamon.

Currently, I have deleted the binary for im-daemon, which causes the autostart program to fail. However, I still want to know how and why this software strives to hide its activity from the user.

Improve this question
6
  • wiki.debian.org/InputMethodBuster has a non-Gnome section at the bottom that might be interesting for you. Commented Apr 2, 2020 at 14:22
  • im-config gives you no control over the starting of the application. My current solution was to delete the binary for im-daemon so the autostart application fails. But I'd still like to know how this malware-emulating software keeps starting, outside of the normal autostart methods Commented Apr 2, 2020 at 14:29
  • Oh, got it. Afraid I can't help you with that, maybe someone else will. Sorry. Commented Apr 2, 2020 at 15:09
  • Maybe try looking for references to ibus in files ~/.xsession or ~/.xsessionrc. Commented Apr 4, 2020 at 23:25
  • @johndoe github.com/Intika-Linux-Apps/Startup-Watcher may help Commented Apr 6, 2020 at 3:45

1 Answer 1

Reset to default
2
+50

I am assuming you are talking about the Zoom Meeting application.

I ran the command 

strace -o debug.txt -e trace=file -f ./ZoomLauncher

This showed at one point to run libibusplatforminputcontextplugin.so which is part of the zoom package. To guess what is happening without a full deep dive into the product I ran:

strings ./platforminputcontexts/libibusplatforminputcontextplugin.so | grep -i ibus

This showed that there are several strings that reference ibus. So the application likely needs it.

The easier solutions are not using gnome variant or trying to run the application in wine.

If you want to directly want to stop it you could try to stop the changes from happening. I am not running Cinnanmon so I am guessing at the solution so you may need more research. The debug file from earlier can show all files accessed. Running the following can show a cleaned up list of file accesses. 

cat debug.txt | grep -v "No such file or directory\|RDONLY\|exited\|unfinished\|\"/dev/" | grep "[0-9]* openat("

Zoom seemed interested in my "/run/user/1000/dconf/user" file. To be clear (due to recent events in the news) I am not saying this malicious I am saying on my system the modify time changed the same time as when I was running zoom. My lack of statement is due to my current knowledge of dconf is low and from what I know there are many legitimate reasons to change a field in this field for any friendly application. If it is modifying dconf settings there could be something in there that is starting ibus. If that is the solution the I would recommend changing permissions on that file to not allow your user to change it. 

chmod 400 /run/user/1000/dconf/user

or the dconf file under your home directory if zoom is modifying it. This very possibly can cause poor and unexpected behavior, but the question tone seems to indicate that this would be acceptable. There are also options for locking dconf with the same caveats. Locking dconf

Improve this answer
2
  • What recent news relating to dconf? Commented Apr 5, 2020 at 19:17
  • I was referring to zoom having received a lot of media attention lately for problems such as zoom bombing. en.wikipedia.org/wiki/Zoombombing I think evaluating the security of this application is important, but this is not the place. Commented Apr 5, 2020 at 19:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.