0

My friend and I are developing a screenshot tool for Linux where the screenshot can be saved into a clipboard by using an external tool like xclip or wl-clipboard. Since there are even more clipboard managers (as listed in the arch wiki for example) we'd like to add an entry in our config file so that the user can decide on his own which and how the clipboard manager should be executed/used. It would for example as follows for for xclip:

clip_man = ["xclip"]
clip_man_args = ["-selection", "primary", "-t", "image/png"]

and our code would look like this (pseudocode):

Process(config.clip_man).args(config.clip_man_args).start()

Now we're wondering if this is fine or if this is actually a security concern since someone just need to replace the config file with a malicious program in clip_man and clip_man_args.

Should we search for another solution or is this design decision fine?

2 Answers 2

3

There are plenty of executable configuration files. Example: ~/.profile They can be protected from writing by advanced ACLs and security systems, and so can yours. Distribute your program with a proper installation script, SELinux and Apparmor configuration and your configuration file will be as safe as they get.

BTW, if security policy is properly configured, your software will be unable to start any non-whitelisted external program, making configuration safety mostly moot.

If the target audience does not run a serious security policy enforcement, don't worry about safety - attacker is more likely to attack .profile than your configuration.

3

As with most security questions, the answer here is "depends on what threat you trying to defend against". Assuming that your program doesn't run with any elevated privileges itself:

  • You don't really introduce a new threat if you're trying to defend against an attacker that already has shell access. Anything they could do by modifying the config file they could just do with the shell anyway.
  • If the attacker doesn't have full shell access, but has enough access to modify files, this would let them replace clip_man and clip_man_args with something that downloads a malicious tool allowing them to elevate themselves to full shell access.
  • There's also the potential for enabling spyware: an attacker could replace clip_man with something that does the right thing with the screenshot - but also sends the screenshot to a nasty corporation / government. Users may never be aware all their screenshots, with potentially sensitive information included, are being leaked.
4
  • This threat analysis is not required, as the scenario matches other user configuration files/profiles, which have well-known safety implications.
    – Basilevs
    Feb 11 at 13:01
  • 1
    @Basilevs: You are right, though I would not say the analysis "is not required". I would say it gives a wrong impression of increased security by not introducing this extra clip_man parameter. When an attacker has write access to user config files, no extra screen shot tool configuration will make it worse.
    – Doc Brown
    Feb 12 at 15:31
  • 1
    @Basilevs: you definitely need to do an analysis. It's "safe" as long as a human runs this who is knowledgeable. Things are not so safe when unknowledgeable people do things, or someone decides they should execute this on a server some place. My paranoia immediately went through the roof when I read this question, but then again, Git does this too. You can specify a custom command to open a difftool... doesn't mean I'm not paranoid about this though. Feb 15 at 20:41
  • I never said it is safe. I've said, it is an already well known scenario.
    – Basilevs
    Feb 16 at 2:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.