wiki:StrongConfirmation

Strong Confirmation

This is currently just a sketchy outline for a potential project.

Goals

There are occasional situations in dealing with a computer where the programs running on the computer really want to be sure that the user at the console absolutely wants to do something.

For example, if Mary adds her RSA key to her running ssh-agent, but wants the agent to prompt her for its use, she might want the agent to ensure that the prompt is actually responded to directly from the keyboard. Current ssh-agent and ssh-askpass implementations (for example) seem to be vulnerable to confirmation spoofing by stray processes simulating or triggering mouse clicks or keyboard presses in the current X session (see xdotool, for a simple way to do this).

The goal would be to provide a level of assurance that even if the current session had a rogue process in it, the confirmation would not be approved.

Technique

My current thought would be to dedicate something like a Secure attention key (SAK) that would generate a timestamped series of events which would be readable (but not writable) by users in a given group. Then a confirmation prompt would display something to the user, "grab" the X session (to ensure single concurrent access?), and display a prompt and a cancel button. A physical user would be able to trigger the SAK. Otherwise, the only way out of the confirmation prompt would be to cancel the prompt (which could be done through the keyboard).

Implementation questions

What would act as the SAK?

On most modern laptops running GNU/Linux, it wouldn't be tough to find a spare ACPI hotkey to use as a trigger. You could also have a special USB nubbin with a button or something like that, if you don't have a key that you can spare. Dunno what it would take to get the nubbin to work properly, but i've got some idea how to deal with ACPI there.

How would the system process communicate with the user session?

One cheap way would be to have a pool of the last N events displayed as a directory of empty files, with the timestamp on each one marking the relevant time. Then the askpass could either do a busy loop checking for a new file, or it could do some fancy inotify craziness.

It might be easier to just make a named UNIX-domain socket, and emit datagrams to any listeners, if that's possible to do without causing the triggering script to hang if there are no listeners.

Packaging choices

It seems like one way to package this would be as a system "producer" package that simply provides a script to be run by acpid upon receipt of a given trigger (and perhaps a configuration utility to automatically figure out which trigger by letting a user press the key).

Then you'd provide "consumer" packages (ideally, one that Provides: ssh-askpass) which know how to find the socket or directory or whatever and listen in on it.

Alternatives

I don't know that there are any similar implementations like this at this time. The GNOME Keyring Security Philosophy suggests that "Trusted X" might be the way to go for secured prompting. The best description I've found about "Trusted X" so far is this odd page from a Trusted Solaris manual.

Potential drawbacks or concerns

Because the special key would be system-wide, this would have odd effects on true multi-user systems. what if two such prompts showed up for different users with current sessions, for example?

a malicious process in the user's current session could still cancel the confirmation prompt, even if they couldn't confirm it. this leaves open potential for a DoS attack of some flavor, but a malicious process in your current session, running as you has many options available to it which are significantly nastier.

the process asking the question might still somehow be tricked between the askpass invocation and the response. need to track down this window.

This can really only give one bit of information if it's just a special event. So if you wanted to prompt for a password and not just an "OK", you'd see the usual ssh-askpass prompt but it would still lack the "OK" button. The typing would go on on the regular (grabbed) keyboard, but you could only say "OK" by hitting the SAK. This doesn't actually seem so bad, since a malicious process which generates keystrokes can only foul up password entry, and can't come up with a password that it doesn't know in the first place.

If we go the ACPI route, it might be Linux-specific. what about other kernels? The isolated producer/consumer model would let you use the same consumers with any producer that makes sense on a different kernel.

If we go with ACPI events, the security of the model seems to rely on users being unable to trigger or simulate arbitrary ACPI events without physical activity. Is this a reasonable assumption?

Mitigating assumptions

Perhaps we should assume here that the process doing the prompting was started in an uncompromised environment. Without that assumption, it's difficult to see that any of this is useful.

Last modified 8 years ago Last modified on Jul 31, 2009, 5:04:24 PM