On Jul 31, 2009, at 12:35 PM, Thomas Harning wrote:
Ahh...
For some reason I thought that only the current GUI user could
access a given Tokend. Is there a way to find out the current
caller into a Tokend... or are Tokend's always "global"? My guess
is that if there's not a way to find out a current caller...
there's also no way to simply 'lock out' other users from accessing
a token instance either...
You are mistaken; the smart card subsystem gives potential access to
all processes on the system, not just the current front graphics user.
Yes, a tokend is always "global". Think of a tokend as serving "the
system", not any given user.
PIN control (and other access control machinery) is managed,
transparently, *per security session*. For example, if you insert a
card, enter the PIN, then fast-user-switch out and let someone else
log in, they will need to re-enter the PIN to use the card, but if
they do they can. (There is some trickery happening behind the scenes
for this. Your tokend does not actually notice the sharing.)
In particular, it *is* possible to use smart cards on a system that
has no user logged in at all. Of course the PIN needs to come from
somewhere (a file, remote connection, whatever). But once the PIN is
provided, system daemons can use the card subject to whatever access
controls the tokend imposes on behalf of its card. (This is rather
handy for things like build machines trying to create code signatures,
for example.)
Since there is significant caching and sharing going on between tokend
and the rest of the system, it's also not a great idea to assume that
"the front user" is directly responsible for a given tokend request.
As an extension to this...
How does securityd prevent remote users from accessing a smartcard
on the local machine?
It doesn't. If you ssh into a system with a smart card inserted, and
explicitly provide the PIN over that ssh connection (using "security
unlock" or similar programs), then that ssh session can use the card
just fine. Recall that each ssh login constitutes a separate security
session, and thus PIN status does not carry over from the graphic
session or between ssh sessions. Also, no dialogs will show up asking
for the PIN, obviously. This is *exactly* the same situation as using
an ordinary keychain.
One caveat: a tokend *may* vend ACLs that require interactive PIN
provision (i.e. it won't accept a PIN provided programmatically and is
only satisfied with a PIN prompted directly from the graphic session
user). That implicitly locks out remote users because they can't get
those prompt dialogs.
In general, if you think of smart cards as a peculiar form of
removable keychain, you'll be predicting the system's behavior pretty
well. That's how the whole thing is designed.
Cheers
-- perry
---------------------------------------------------------------------------
Perry The Cynic email@hidden
To a blind optimist, an optimistic realist must seem like an Accursed
Cynic.
---------------------------------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
