>>>>> "Mark" == Mark Jackson <[EMAIL PROTECTED]> writes:
<snip>
Mark> In a networked environment running X, an app will sometimes be running
Mark> remotely on a server but displaying
Mark> on the client. In order for a reader at a client machine to be accessed
Mark> by the remote application, the resource
Mark> manager would have to be network aware in some way. My initial gut
Mark> feeling is that a daemon or inetd service
Mark> would be a nice way to do this...
Mark> For command line applications (ssh comes to mind) that might want to use
Mark> the card reader, the interface would
Mark> be better handled through the tty associated with the shell.
The ssh-agent(1) will do authentication in the negotiating phase of ssh
contacting sshd. The intelligence to use ssh-agent is in ssh (the local
application). Authentication is being forwarded for later connections over the
intermediary ssh's. Therefore, all applications concerned know about the
special tty stuff needed for authentication. A generic 'command line
interface' to the reader over tty would be broken at the first program that
doesn't understand the special tty stuff. So I don't think we should try to
use tty's here; if a remote application needs to do have access to the
smartcard, it should have something running on its behalf on the local
machine. An "authentication forwarder" would be easy to write using some
API. The problem is: we probably don't want to give access to perhaps
sensitive information to anybody who can connect to this forwarder (we have to
authenticate the origin of the request, but if we have a secure+confirmed
channel to the app already, what is the forwarder needed for?)
X: we could have an X11 input extension (similar to drawing tablets, joysticks
etc.) so the local X11 server (which would have access to the local reader)
may use the device for the remote application. Again, remote process
authentication is a problem (and MIT_MAGIC_COOKIE auth or xhost is *low*
security, especially if somebody is not trying to read 50% of your keystrokes or lock
your display, but wants to use your credit card directly..)
Mark> So the resource manager should be versatile enough to handle both local
Mark> apps and remote apps whether they
Mark> are command-line based or graphical (X).
Mark> If the resource manager was in the kernel, the above would still apply
Mark> at the service provider level...
Right. However, I believe that a resource manager with only local entry points
is still needed. Any kind of connectivity by net opens up a lot of attack
possibilities; if really needed, these could be put into some userland
process.
Jan
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
