clipboard integration -- possible security implications

[Tony Baechler]

Hi,

Ah, of course. OK, we need something like mktemp. Can Speakup set 
environment variables? What about restricting it so that it can only 
write the clipboard under /tmp? What I'm thinking is that somehow a 
random filename needs to be generated and somehow the name has to be 
communicated to the user. By writing under /tmp, it avoids the 
/boot/vmlinuz problem that you outline but people could still create 
symlinks, so make it a random file that changes based on the ID of the 
logged in user. Put the name of that file in 
/sys/accessibility/speakup/clip. That creates an extra step for the user 
because they would have to open two files, first to find what the random 
file is and second to open the actual clipboard text, but that should be 
very secure. Obviously, the owner of both files would have to be the 
current user.

If you can write to the environment, you could set a variable with the 
random filename which could be read by any shell script, again such as 
speakupconf or just "set" by itself. It could also be used in a script 
if someone wanted to copy it to a predictable name, in which case 
security would be their problem.

On 10/21/2009 9:02 AM, William Hubbs wrote:
> If another user logs in, they would need to have permission to access
>> files under /home/tony to do any good.  If they wanted to copy text to
>> the clipboard, I would have to login as root and change the above
>> location or they could use something like speakupconf.  That way, no
>> actual text would be stored under /sys at all from the clipboard.
>>      
>
>   This idea leads to another issue.  If your system is compromised, it
>   would be possible for someone to put something in the sys file like:
>
>   /boot/vmlinuz
>
>   and take your system down since the kernel could be directed to
>   overwrite any file in the filesystem.
>