clipboard integration -- possible security implications

clipboard integration -- possible security implications

[William Hubbs]

All,

There have been a couple of requests to integrate the speakup cut/paste
functionality with the X clipboard so that cutting something to the
speakup clipboard also puts that data on the x clipboard and vice versa
so that you could cut and paste between the console and the gui.

Chris and I were discussing this today on IRC and we think there are
possible security implications.

The first concern is that X is multi user.  I don't know if orca works
this way, but it is possible for multiple users to run X servers on one
computer and have the displays redirected to their own computers.
If we were to modify X so that putting something on an X clipboard
would also put it in speakup's clipboard, there is no way to know what
would be in speakup's clipboard at any point in a multi user situation.

We also thought about exposing the speakup clipboard as a sys file so
you could just access it with xclip and copy it into the X clipboard.
The concern is that in order for this to be useful, it would have to be
either group or world readable so that you didn't have to become root
every time you wanted to copy from the speakup clipboard to the gnome
clipboard.  Since you can store any information, including personal
information, in the clipboard, this opens up a security hole.  Someone
could read the sys file without you knowing about it and they would have
whatever information was in the file when they read it.

Any feedback, comments, etc are welcome.  Please let us know what you
think.

William

Re: clipboard integration -- possible security implications

[Zachary Kline]

Hi William,
I can understand the security implications as you outline them.
Personally, whatever I've needed to copy from a text console has been
easy enough to handle via xclip.  I certainly don't need to do this sort
of thing every day.  It almost seems to me to be more trouble than it's
worth.
Maybe someone with a more frequent need for this sort of integration
could give us a different perspective?
Best,
Zack.

Re: clipboard integration -- possible security implications

[Glenn Ervin]

I have always heard that there is some windows spyware which can hack one's 
clipboard and highjack the data.
For this possibility, I always, after copying my credit card number to be 
pasted in on a web page, I copy some other text to over-write the credit 
card number.
Glenn

----- Original Message ----- 
From: "Zachary Kline" <kline.zachary@gmail.com>
To: "Speakup is a screen review system for Linux." <speakup@braille.uwo.ca>
Sent: Tuesday, October 20, 2009 4:19 PM
Subject: Re: clipboard integration -- possible security implications


Hi William,
I can understand the security implications as you outline them.
Personally, whatever I've needed to copy from a text console has been
easy enough to handle via xclip.  I certainly don't need to do this sort
of thing every day.  It almost seems to me to be more trouble than it's
worth.
Maybe someone with a more frequent need for this sort of integration
could give us a different perspective?
Best,
Zack.
_______________________________________________
Speakup mailing list
Speakup@braille.uwo.ca
http://speech.braille.uwo.ca/mailman/listinfo/speakup




E-mail message checked by Spyware Doctor (6.1.0.447)
Database version: 6.13520
http://www.pctools.com/en/spyware-doctor-antivirus/ 





E-mail message checked by Spyware Doctor (6.1.0.447)
Database version: 6.13520
http://www.pctools.com/en/spyware-doctor-antivirus/

Re: clipboard integration -- possible security implications

[Chris Brannon]

Glenn Erving wrote:
> I have always heard that there is some windows spyware which can hack one's 
> clipboard and highjack the data.
> For this possibility, I always, after copying my credit card number to be 
> pasted in on a web page, I copy some other text to over-write the credit 
> card number.

It's only tangentially related, but I probably wouldn't copy my credit
card number to a clipboard.  Not safe at all.  I can rattle it off from
memory, along with my SSN, bank routing number, checking account number,
sundry passwords, and other confidential miscellanea.

-- Chris

Re: clipboard integration -- possible security implications

[Tony Baechler]

Hi,

Ideally, the clipboard text could be stored in a user's home directory.  
The immediate problem I see is how Speakup is supposed to determine what 
that is.  Am I correct in assuming that there is no way for the kernel 
to know what user is logged in and to find that user's home directory?

The next best thing would be to have a file under /sys which would have 
the path and filename where the text should be stored.  That way, it 
could be owned by root so no other users could read it.  Even if they 
could, they would have to have permission to access the file listed.  
For example, say the sys file is /sys/accessibility/speakup/clip.  In 
that file, I echo the following:

/home/tony/clip

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.

As a final thought, since probably most systems are single user, it 
probably isn't that big of a deal.  I'm very concerned about security, 
but I'm the only one who uses my Linux boxes, so in my case, I would 
have no problem either being root or changing permissions as necessary.  
I suppose you could have a clip-chmod file which would let root decide 
what permissions to set on the clipboard output.

On 10/20/2009 2:00 PM, William Hubbs wrote:
> We also thought about exposing the speakup clipboard as a sys file so
> you could just access it with xclip and copy it into the X clipboard.
> The concern is that in order for this to be useful, it would have to be
> either group or world readable so that you didn't have to become root
> every time you wanted to copy from the speakup clipboard to the gnome
> clipboard.  Since you can store any information, including personal
> information, in the clipboard, this opens up a security hole.  Someone
> could read the sys file without you knowing about it and they would have
> whatever information was in the file when they read it.
>    

Re: clipboard integration -- possible security implications

[William Hubbs]

Hi Tony,

On Wed, Oct 21, 2009 at 01:39:48AM -0700, Tony Baechler wrote:
> Ideally, the clipboard text could be stored in a user's home directory.  
> The immediate problem I see is how Speakup is supposed to determine what 
> that is.  Am I correct in assuming that there is no way for the kernel 
> to know what user is logged in and to find that user's home directory?

Correct, the kernel has no idea about where home directories are.

> The next best thing would be to have a file under /sys which would have 
> the path and filename where the text should be stored.  That way, it 
> could be owned by root so no other users could read it.  Even if they 
> could, they would have to have permission to access the file listed.  
> For example, say the sys file is /sys/accessibility/speakup/clip.  In 
> that file, I echo the following:
> 
> /home/tony/clip
> 
> 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.

> As a final thought, since probably most systems are single user, it 
> probably isn't that big of a deal.  I'm very concerned about security, 
> but I'm the only one who uses my Linux boxes, so in my case, I would 
> have no problem either being root or changing permissions as necessary.  
> I suppose you could have a clip-chmod file which would let root decide 
> what permissions to set on the clipboard output.
 
 I realize that a number of systems out there are probably single user
 home systems, but I don't feel that we can code assuming that speakup
 will always only be used on home systems.

 William

Re: clipboard integration -- possible security implications

[Gregory Nowak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Oct 21, 2009 at 11:02:41AM -0500, William Hubbs wrote:
>  I realize that a number of systems out there are probably single user
>  home systems, but I don't feel that we can code assuming that speakup
>  will always only be used on home systems.

I would like to add my voice in support of this line of thought. Yes,
most systems out there with speakup probably are single user home
systems. However, I still think it should be borne in mind that
linux-based systems have multiuser abilities by nature, so I
personally wouldn't want to see assumptions made in speakup's
development which rely on the fact that speakup runs on single user
systems only. As a case in point, I mentioned in another thread that I
have a couple user accounts on my system for other folks, and one of
those is a shell account. Though I mostly access this system over ssh,
it does have speakup built into the kernel, so that I could hook up my
bns, and troubleshoot any boot issues. Since I mostly use this system
over ssh, I don't use speakup's cut/paste feature much on it, but
there may be cases where I need to use that feature, where the system
is in a multiuser runlevel, which of course could lead to the
possibility that someone else could have a look at potentially
sensitive content in the clipboard. Just my $0.01 worth.

Greg


- -- 
web site: http://www.romuald.net.eu.org
gpg public key: http://www.romuald.net.eu.org/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

- --
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrfd5UACgkQ7s9z/XlyUyCxlACgsCmTPxcrvYXcGbNSZ5Ld4SRF
K9wAn0+LyjtHp86rEt5f0Ov8ida6Fzet
=7l2I
-----END PGP SIGNATURE-----

Re: clipboard integration -- possible security implications

[Jason White]

Gregory Nowak  <speakup@braille.uwo.ca> wrote:

>I would like to add my voice in support of this line of thought. Yes,
>most systems out there with speakup probably are single user home
>systems. However, I still think it should be borne in mind that
>linux-based systems have multiuser abilities by nature, so I
>personally wouldn't want to see assumptions made in speakup's
>development which rely on the fact that speakup runs on single user
>systems only. 

I agree. Furthermore, flawed designs in relation to security aren't going to
be welcome in distributions or in the mainline kernel. I can't remember what
the issues were, but I do recall that security problems were cited as a reason
for keeping SpeakUp out of Debian kernels for quite a while.

Re: 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.
>    

Re: clipboard integration -- possible security implications

[William Hubbs]

Hi again Tony,

as far as I know, speakup can't write environment variables.  Even if it
did, they would not be accessible to you in your login session since the
environment is different for every session.

How do you define the current user?  It can't be the one who is
logged in since multiple users can be logged in even on a machine that
doesn't have network access (you can log into one vt as root and another
as yourself for example).

That puts us back in a situation where the files you are talking about
have to be only accessible to root and you would have to find another
way to create the random file name you are talking about.

What do you think?

William

On Thu, Oct 22, 2009 at 12:57:43AM -0700, Tony Baechler wrote:
> 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.
> >    
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: clipboard integration -- possible security implications

[Tony Baechler]

Hi,

OK, how does speakupconf work if you're not root? If it can write to sys 
files, perhaps have it write the name of the clipboard file, the same as 
you would to switch synthesizers. That would give ultimate flexibility 
to the user, although the question is still who the current user is. I 
would define the current user as the one who is using Speakup at the 
time that text is copied to the Speakup clipboard.

Another idea would be to require a user to be in a special group, 
similar to only making the CD drive accessible to users in the "audio" 
group. The group would have to manually be created, but it would be a 
simple matter to add all users who should be allowed to read the Speakup 
clipboard to that group. I had to manually add a user to the audio group 
before I could extract a CD. You could also give the option of using an 
already existing group, such as "admin" which is used by sudo.

On 10/22/2009 8:38 AM, William Hubbs wrote:
> How do you define the current user?  It can't be the one who is
> logged in since multiple users can be logged in even on a machine that
> doesn't have network access (you can log into one vt as root and another
> as yourself for example).
>
> That puts us back in a situation where the files you are talking about
> have to be only accessible to root and you would have to find another
> way to create the random file name you are talking about.
>    

Re: clipboard integration -- possible security implications

[Chris Brannon]

> OK, how does speakupconf work if you're not root?

Speakupconf doesn't need to be so discerning.  It just copies data to or
from /sys, regardless of who is running it.
It is a shell script,
and it uses ~/.speakup when running as a non-privileged user.
The assumption is that settings don't contain any sort of sensitive info.

> although the question is still who the current user is. I
> would define the current user as the one who is using Speakup at the 
> time that text is copied to the Speakup clipboard.

That is a perfect definition!  How do you determine who the current user is?
I looked at headers under /usr/src/linux/include yesterday, and there
doesn't seem to be any sort of userid field associated with the C structs
that represent virtual consoles.
I suppose that you could use the number of the virtual console on which
the copy / paste operation is being performed.
Next, you have to figure out how to contact the X server that the current
user is using.

If there is going to be any sort of automatic transfer of data between
Speakup's cut buffer and the X clipboard, then both of those pieces
of info need to be known.  Who requested the copy or paste, and where is
his X server -- assuming that he is running X?

> Another idea would be to require a user to be in a special group, 
> similar to only making the CD drive accessible to users in the "audio" 
> group. The group would have to manually be created

This is a really good idea, for everything under /sys/accessibility/speakup.
The group would be created by the person who packages Speakup for your distro.
The file ownerships need to be set correctly whenever speakup's modules are
loaded.  If you look at "man modprobe.conf", there's a description of
something called "install".  This "install" primitive allows us to run
arbitrary commands whilst loading a module.
The people who package Speakup could probably do all of this today, without
requiring any change to the Speakup code.
This won't solve all the problems related to automatic export / import
of the clipboard, though.

-- Chris

Re: clipboard integration -- possible security implications

[Gaijin]

> > although the question is still who the current user is. I
> > would define the current user as the one who is using Speakup at the 
> > time that text is copied to the Speakup clipboard.

	What about people who want to copy text from one user account to 
another?  I presently enjoy that functionality, and would hate to see it 
restricted.

				Michael

Re: clipboard integration -- possible security implications

[Chris Brannon]

Michael <gaijin@clearwire.net> wrote:
> 	What about people who want to copy text from one user account to 
> another?  I presently enjoy that functionality, and would hate to see it 
> restricted.

We aren't talking about restricting what people can do while they are sitting
at the console.  If you have two user accounts logged in at the console,
copy and paste between them all you like.
In fact, that would be fairly difficult to restrict.

This discussion is about integrating Speakup's clipboard with the X
clipboard, so that the Gnome folks can copy and paste between console and
GUI.  I don't believe that it can be done in a secure way.

-- Chris

Re: clipboard integration -- possible security implications

[William Hubbs]

On Fri, Oct 23, 2009 at 06:55:35AM -0500, Chris Brannon wrote:
> > although the question is still who the current user is. I
> > would define the current user as the one who is using Speakup at the 
> > time that text is copied to the Speakup clipboard.
> 
> That is a perfect definition!  How do you determine who the current user is?
> I looked at headers under /usr/src/linux/include yesterday, and there
> doesn't seem to be any sort of userid field associated with the C structs
> that represent virtual consoles.

Right, I don't believe the kernel has anything to do with managing
users/groups/logins/logouts other than enforcing permissions.  It
manages the virtual terminals, but it doesn't seem to know or care who
is using them.

> I suppose that you could use the number of the virtual console on which
> the copy / paste operation is being performed.

Even if you know this, I don't know of a way you can tell from the
kernel who is logged onto that virtual terminal.

> Next, you have to figure out how to contact the X server that the current
> user is using.
> 
> If there is going to be any sort of automatic transfer of data between
> Speakup's cut buffer and the X clipboard, then both of those pieces
> of info need to be known.  Who requested the copy or paste, and where is
> his X server -- assuming that he is running X?
 
 The only way I can think of to get the user's X server (assuming you
 know who the user is), would be to get into his environment and check
 the DISPLAY environment variable he has set.  But, I have no idea how
 this could be done.

> > Another idea would be to require a user to be in a special group, 
> > similar to only making the CD drive accessible to users in the "audio" 
> > group. The group would have to manually be created
> 
> This is a really good idea, for everything under /sys/accessibility/speakup.
> The group would be created by the person who packages Speakup for your distro.
> The file ownerships need to be set correctly whenever speakup's modules are
> loaded.  If you look at "man modprobe.conf", there's a description of
> something called "install".  This "install" primitive allows us to run
> arbitrary commands whilst loading a module.
> The people who package Speakup could probably do all of this today, without
> requiring any change to the Speakup code.
> This won't solve all the problems related to automatic export / import
> of the clipboard, though.
 
 Right, securing speakup's /sys files, in general, is a completely
 separate subject imho.  I do agree though that this would be best
 handled in user space without doing anything to the speakup code.

William

Re: clipboard integration -- possible security implications

[Tony Baechler]

Why?  What if I want the Speakup clipboard to go in a file on disk but I 
don't want it in X?  If in X, why not open it in a text editor?  I agree 
that the most convenient would be to copy it directly to the X 
clipboard, but I can think of cases where one would want a permanent 
copy in a file for use later.  Just one example might be in cases where 
the machine needs to be rebooted (like a kernel upgrade) and a command 
needs to be run after the reboot which was copied into the clipboard.  
Another example is if I want to copy something within Speakup, logout 
and access it via ssh.  That's why I like my idea of requiring users to 
be in a special group.  I don't often change Speakup settings with ssh 
but I do sometimes.  I think that in order for the Speakup clipboard to 
automatically go to X, a separate utility would have to be written.  I'm 
not a programmer and I have no idea how that would be done.

On 10/23/2009 4:55 AM, Chris Brannon wrote:
> Next, you have to figure out how to contact the X server that the current
> user is using.
>
> If there is going to be any sort of automatic transfer of data between
> Speakup's cut buffer and the X clipboard, then both of those pieces
> of info need to be known.  Who requested the copy or paste, and where is
> his X server -- assuming that he is running X?
>    

Re: clipboard integration -- possible security implications

[Tony Baechler]

Ah, but it wouldn't be if my idea about requiring group membership is 
implemented.  Just make sure that all users who are allowed to access 
the Speakup clipboard text are in a special group, like the "speakup" 
group.  Granted that it's an extra step initially but it only takes a 
command and a few seconds to add a user to a group.

On 10/23/2009 8:38 AM, Gaijin wrote:
>>> although the question is still who the current user is. I
>>> would define the current user as the one who is using Speakup at the
>>> time that text is copied to the Speakup clipboard.
>>>        
> 	What about people who want to copy text from one user account to
> another?  I presently enjoy that functionality, and would hate to see it
> restricted.
>    

Re: clipboard integration -- possible security implications

[Chris Brannon]

Tony Baechler <tony@baechler.net> wrote:
> but I can think of cases where one would want a permanent 
> copy in a file for use later.  Just one example might be in cases where 
> the machine needs to be rebooted (like a kernel upgrade) and a command 
> needs to be run after the reboot which was copied into the clipboard.  

Here's one way to do that.

* Make a selection.
* Cut.
* execute cat > stuff.txt
* Paste.
* Hit ctrl-d to indicate end-of-file.
* Voila!

-- Chris

Re: clipboard integration -- possible security implications

[Steve Holmes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

And to add to this suggestion, while in that same shell, you could
pipe the pasted contents into xclip in much the same way and then you
have it in the X clipboard also.  

I like the idea of the select group to hold all speakup settings.
This would improve security issues in general, I think.  I like the
concept of using /sys/accessibility/speakup/clip or whatever to hold a
file name that could then be used and owned by a specific user but I
also understand the downside to this as was pointed out earlier in
this thread.  

I wonder if tiing this business to virtual consoles wouldn't be a bad
idea.  I mean, think about it.  First off, speakup would never be used
by a remote user like over ssh; at least I can't imagine such a case.
As I think about it right now, I would think that could be an
excellent way to secure this aspect.  If the speakup cut/paste feature
is accessing the resource, any other users currently using the system
are mostlikely not on the virtual consoles and would probably have no
idea it was in use.

I think the big question is how to get this speakup buffer over to the
X clipboard.  Xclip is an excellent program to do the job but this
requires the shell AFAIK and the speakup clipboard could be piped into
xclip somehow.

On Sat, Oct 24, 2009 at 09:51:20AM -0500, Chris Brannon wrote:
> Tony Baechler <tony@baechler.net> wrote:
> > but I can think of cases where one would want a permanent 
> > copy in a file for use later.  Just one example might be in cases where 
> > the machine needs to be rebooted (like a kernel upgrade) and a command 
> > needs to be run after the reboot which was copied into the clipboard.  
> 
> Here's one way to do that.
> 
> * Make a selection.
> * Cut.
> * execute cat > stuff.txt
> * Paste.
> * Hit ctrl-d to indicate end-of-file.
> * Voila!
> 
> -- Chris
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREDAAYFAkr47aUACgkQWSjv55S0LfFfiQCgi4ijXy5/nsABrMZJdG8alwbx
+H4An3lNYQHV0z45Sm9VNqOvC+y1ye+n
=xvMx
-----END PGP SIGNATURE-----

Re: clipboard integration -- possible security implications

[Tony Baechler]

I do sometimes use Speakup via ssh.  Sometimes I want to make sure my 
hardware synthesizer is working.  I often build new Speakup modules via 
ssh for convenience.  When I was playing with virtual machines and 
DOSemu, I tried sending output through Speakup.  I'm actually wondering 
if there could be a potential security issue with a remote user flooding 
a hardware synth buffer by sending massive amounts of text to it.  I 
have verified that I can make my synth talk from across the room with 
ssh, so presumably there would definitely be a security issue in that a 
user could send unwanted and/or annoying messages to your synth when you 
aren't expecting it.  In the case of the DECtalk, they could send text 
without a closing bracket and potentially cause loss of speech.

On 11/9/2009 8:35 PM, Steve Holmes wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> And to add to this suggestion, while in that same shell, you could
> pipe the pasted contents into xclip in much the same way and then you
> have it in the X clipboard also.
>
> I like the idea of the select group to hold all speakup settings.
> This would improve security issues in general, I think.  I like the
> concept of using /sys/accessibility/speakup/clip or whatever to hold a
> file name that could then be used and owned by a specific user but I
> also understand the downside to this as was pointed out earlier in
> this thread.
>
> I wonder if tiing this business to virtual consoles wouldn't be a bad
> idea.  I mean, think about it.  First off, speakup would never be used
> by a remote user like over ssh; at least I can't imagine such a case.
> As I think about it right now, I would think that could be an
> excellent way to secure this aspect.  If the speakup cut/paste feature
> is accessing the resource, any other users currently using the system
> are mostlikely not on the virtual consoles and would probably have no
> idea it was in use.
>