Feature discussion: ability to prohibit image upload as a system policy

[RomanHargrave]

Similarly to #798, my organization requires a robust tool for screenshot capture - for both internal and external support tasks, as well as documentation. Because we handle legally protected sensitive information, we require that such a tool have any external storage features (e.g. imgur upload) disabled in such a manner that a user without administrative access is unable to re-enable them.

Flameshot is particularly attractive because there is absolutely no extra work required to redact sensitive information in images. Previously, I have observed users to capture images of their display, print them, redact them with markers or whiteout, and scan them as opposed to using an image editor for this purpose. I can't blame them - many screenshot tools are not designed with this functionality in mind it would seem.

We use Linux on nearly all user endpoints, so it would be sufficient for our purposes to implement this with a global configuration file (e.g. /etc/flameshot/flameshot.ini).

While I am willing to implement such a feature (with the caveat that I am not well acquainted with Qt desktop app best practices), I wanted to first raise the issue for discussion, as there are a few concerns that need to be addressed before an appropriate course of action can be decided:

1. The upload button may already be removed from the toolbar; however, this does not account for the keyboard shortcut, nor the fact that the button configuration is stored as serialized data, as opposed to human readable data (side note: I absolutely hate Qt INI files - what's even the point of being plain text when Qt apps very frequently have INI files almost entirely populated with @Variant and other such data). This makes administrator modification and distribution difficult.
2. There is no current provision for system level configuration, and this feature would force the implementation of such a thing
3. The matter of ensuring that system-level options are not replaced by user-level options is tricky, as it may be desirable in some cases, but undesirable in others - possibly even for the same configuration options, depending on the situation.
4. The matter of doing this on windows. I have not used windows extensively in likely more than a decade and have zero experience building software "the windows way".

As such, input from maintainers is welcome - I'm not interested in maintaining a fork and packaging it in order to maintain a feature that isn't in keeping with upstream's quality standards, and as such I would prefer to produce something that can be accepted into the official repo.

[borgmanJeremy]

I believe this is already possible in version 0.9.0.

1. Configuration > Interface > uncheck image upload
2. The upload hotkey is now disabled, and the upload hotkey is removed from the GUI
3. You will see that the file in ~/.config/flameshot/flameshot has changed (specifically buttons@variant) has been added which is the serialized version of the allowed buttons

[RomanHargrave]

@borgmanJeremy I did touch on that, unfortunately it can be re-enabled by the user, as the configuration file is writable. In our internal tracker the proposed solution is to take ownership of and prevent the user from editing the config file, but something system level would be nice.

[borgmanJeremy]

Ohh ok I understand now. The current issue with that is flameshot constantly updates the .ini file with things like "last selected color". So we can not move the entire ini file without requiring flameshot to run as root which is worse from a security standpoint.

Let me think on it more, I don't really like adding one off features like this but there might be a good compromise.

I understand this is probably outside your control but I don't really understand the corporate logic of allowing a web browser but not allowing something like this.

[hosiet]

It's interesting that flameshot does not have a systemwide config file like something under /etc/flameshot/. Having such file could help enforcing some read-only policies.

(Of course, one will also consider how to implement this on OS other than Linux.)

[RomanHargrave]

Of course there is nothing stopping the user from exfiltrating data via the web browser, but this is less about malicious users and rather about preventing mistakes. Of course, one could simply disable the features, but I have some savvy users that might go and re-enable them with no intended harm as well as an auditing firm to deal with.

[borgmanJeremy]

@hosiet My initial thought was to add a config to /etc but usually files in the users home directory are allowed to override the system settings.

It is really easy to add some #ifdef options to compile flameshot with uploads completely removed, but that would be sort of a fork.

[RomanHargrave]

It is really easy to add some #ifdef options to compile flameshot with uploads completely removed, but that would be sort of a fork.

Exactly my concern. Unfortunately we don't necessarily have the resources to independently maintain and package such a fork - not to mention that I feel doing so would be rude.

[borgmanJeremy]

Do you only require this on windows?

And not rude at all 😁 we actually have a great partnership with Namecheap and they compile and distribute a slightly different version to suit their requirements.

[hosiet]

Override relationship is really defined by the program -- if you design a special field of SystemwideDisableNetwork = 1, you can always enforce that in program logic. It's just whether you would like to write the code or not.

[RomanHargrave]

Actually, really only on Linux. We have about three windows endpoints, but 50+ Linux endpoints. We're not a big shop.

[borgmanJeremy]

Ok only Linux makes it easier. The more I think about it the more I think I should add this. Frankly it makes sense for most enterprise users or people working with sensitive data.

[mmahmoudian]

I use Flameshot for my research and none of my results should be published prior to journal submission.

I think adding a flag to disable the upload would be a good solution. I personally always have the fear of accidentally uploading.

Alternatively (maybe even better solution and easier to implement) we can have the possibility of an additional config file in /etc that can overwrite values in ~/.config. This way Flameshot can first read the one in home folder and then parse the /etc and the settings there automatically get overwritten. The good thing about this is that users can use their distro or our packages files and update normally without needing to compile every single time. The only downside to this is Windows compatibility.

I personally prefer the second one.

[borgmanJeremy]

@mmahmoudian Here is how I picture the design:

1. Default settings are in /etc/flameshot/
2. /etc/flameshot includes a new setting named SystemwideDisableNetwork
3. The local flameshot.ini file works as it does today. The flameshot process never writes to the /etc config
4. The local flameshot.ini file can override any of the global settings except SystemwideDisableNetwork

[RomanHargrave]

@borgmanJeremy this seems like a logical and sane solution

[mmahmoudian]

I just have 1 comment. I don't see what can be system-wide set that needs to be over-powered by local. My rationale is that the /etc config is the ultimate power and critical immutable settings should go there. Everything else can be in local config file. This simple distinction would prevent confusion as there will be no exception to remember.

I'm not implying that my suggestion is the correct way, I'm just saying that as a user, this is more intuitive. Of course you know best as you know the inside gears of Flameshot 😉

[borgmanJeremy]

I'm happy to do it that way too. I'll wait a day or two to implement it to collect other people's feedback but either is good to me.

[kpcee]

I don't think that such a functionality would increase security, as it can be leveraged very easily. Anyone with a little knowledge and enough criminal energy can easily bypass it. The only correct measure would be to disconnect such computers from the internet and also to prevent the use of USB sticks, for example.

As long as a computer is connected to the internet, you can use other programs, be it the browser or pre-installed programs like wget, curl ... with which you can upload images via simple shell scripts (e.g. Bart's Imgur uploader bash script).

It would be better to allow only domains that are important for the business, for this Linux offers hosts.allow and hosts.deny. But these settings can always be bypassed by a VPN or TOR.

You can use the firewall nftables included in the kernel, alternatively you can exclude complete programs from the internet or allow only certain with e.g. opensnitch.

All this would be much safer than adding anything to Flameshot, which would really only prevent accidental uploads or prevent laymen from uploading specifically.

[mmahmoudian]

@kpcee your points are valid regarding security, but as it was mentioned by @RomanHargrave this is just to prevent mistakes rather than security. In my line of work (academia) this is also applicable. I personally want to avoid mistakes and uploading my research results online by mistake. Of course one can argue that it can be disabled in settings and the keybinding can be removed (what I'm doing at the moment), but as it happened before, it is possible that in an update the setting gets turned on by mistake an compromises my safetynet.

[chemsaf3]

+1 on this for any platform too. privacy concious users may also like this. user may accidentally screenshot and upload personal info from their system too, not just company secret

[borgmanJeremy]

I'm not sure how to design this on macOS and windows.

[RomanHargrave]

@borgmanJeremy windows would probably want group policy, which is probably unpleasant to work with depending on how Qt approaches it. i have no idea how system-level configs work on macOS, or if they are even commonplace. I would imagine macOS does still have a concept of system-level configuration via files outside /Users or wherever, but I don't know how often it would be used...

[mmahmoudian]

I think the OSX follows the same logic as Linux considering that the general folder structure and permission system is similar. For Windows though, I have absolutely no idea.

[idontthinksoo]

Whilst imgur upload functionality is in the code and not able to be hard disabled and removed, for example, if it was implemented as an optional plugin we could not install or hard remove.

I WONT EVER BE TOUCHING FLAMESHOT whilst imgur functionality is there.

Data exfiltration risk. The only option is to use Mandatory Access Control on the Linux LSM such as AppArmor to prevent network access for your application.

1. you favour imgur service and,
2. data exfiltration risk

NO THANK YOU.

[mmahmoudian]

@idontthinksoo Considering your tone I have no choice but to list the following:

1. If you check the immediate link above your post you will see that there is a feature request to implement flags to disable all networks communications during compile time.
2. What you wrote is definitely not a constructive criticism and/or suggestions and GitHub issues are not a place for your personal rants and opinions if it is not constructive.
3. Free and Libre OpenSource Software (FLOSS) has many beautiful perks, one of which is that you as a user has the freedom to choose to use the software or not.
4. Another perk of FLOSS is that you can always fork the code and add/remove the parts you want.

Please try to be CONSTRUCTIVE in your posts on Flameshot's GitHub repos.

Thank you for your understanding in advance.

[idontthinksoo]

Your app is now added to all blocklists.

[RomanHargrave]

1760 is a good step - I would add, though, that it might ultimately be nice to adjust these things via configuration file so that distribution-provided packages may be used, unless someone is willing to package the offline version and attempt to get it into distros (which I see as unlikely because it's essentially the same application minus one feature).

[xmeadow]

Windows-admin here: I don't really care if you can set a flag during installation or if it is disabled via group policies, but I think it would be a great idea to make the network-part in flameshot optional. In my company, I don't want to give users the ability to upload anything they take screenshots of on their work PCs to a third party, and of course I don't want potential threat actors to have the ability to abuse network functionality of a screenshot tool. Once #1760 is implemented, nothing will stop me from rollling out flameshot on +6000 users.