I need to prevent processes from copying sensitive data to the clipboard on Windows. My approach is to block the copying when a process accesses sensitive data.
The native Windows function SetClipboardViewer only supports monitoring and cannot be used for blocking. If it were used to monitor and empty the clipboard after detecting sensitive data, other processes could still access this data in some cases.
Could you suggest a way to achieve this, including both user-mode and kernel-mode development techniques?
Is this for a DLP solution? I am guessing you may have to actually intercept the writes to the clipboard and stop them. I have not reversed this part so am not sure if it all converges at a unique point inside Windows. You may want to investigate starting with SetClipboardData function (winuser.h) - Win32 apps | Microsoft Learn
By far the biggest task is to determine when you want to intervene in the normal operation of the clipboard and when you don't.
The second important question, is how difficult you want to make it to bypass your scheme. The question is not whether what you develop can be bypassed, but what level of difficultly you can accept
To help answer the first question, I suggest you start with GDI hooks. Even if you just create a simple hook that logs activity while you are trying to copy / paste your 'sensitive' information, it will likely provide a lot of insight as to what actually happens during that sequence.
After that, think about how the clipboard is implemented. The clipboard APIs provide a big clue. Also look at ReadProcessMemory
I guess I will block clipboard access for any process that has opened sensitive data. According to Mr. Tim_Roberts, there's no way to ensure that the data stored in the clipboard is not sensitive.
ReadProcessMemory is almost certainly not used with the clipboard, the system will read the GlobalAlloc memory provided by the client.
Hooking API reading and writing clipboard data of all processes is currently my choice. Is it possible?
Microsoft already did such work.
I'd say hooking is not perfect solution and it will be always natively banned by Microsoft, but little abuse this functionality by enforcing some processed to be in a job?
I'm facing a issue with blocking UWP access to clipboard. It utilizes COM to communicate with the RuntimeBroker process for clipboard access. While a normal process can be blocked using a job with the JOB_OBJECT_UILIMIT_READCLIPBOARD or JOB_OBJECT_UILIMIT_WRITECLIPBOARD flag, UWP can not. Can someone provide me with a suggestion?