sudo-touchid icon indicating copy to clipboard operation
sudo-touchid copied to clipboard

Linux port?

Open piranna opened this issue 8 years ago • 13 comments

Neat hack! :-D I know this project is focused on OSX, but would it be possible to port the same idea de Linux sudo command? :-) I don't hace a TouchID enabled machine, but I think it's something could be REALLY useful... :-D

piranna avatar Oct 31 '16 08:10 piranna

Unless you have Linux running on a new MacBook, it would be useless.

kailan avatar Oct 31 '16 09:10 kailan

There are other devices with a thumb sensor...

piranna avatar Oct 31 '16 09:10 piranna

Yeah, but there are existing solutions for sudo with fingerprint readers. This is specifically for TouchID.

kailan avatar Oct 31 '16 09:10 kailan

Oh, didn't know of them, thanks :-)

piranna avatar Oct 31 '16 09:10 piranna

I did a bunch of research about fingerprint readers recently, so I'll just leave this here as this project looks (understandably) popular right now. For anyone who likes security, I made you a wall of text!

  • Touch ID authentication is handled by the Secure Enclave (= a very large pile of crypto) running on a dedicated processor, the T1. At the end of the day, the macOS authentication framework just gives a go/no-go binary response ("yes, okay" or "no, failed"). I'm not sure if there's some authentication happening between macOS and the T1 to make this happen; in any case the controller probably stores the fingerprint data in secure flash storage or something (yay).

    Now, you might be able to get Linux to play ball with the T1. However, it's hard to defend the argument that the sniffing around and level of technical investigation necessary to get Linux support working might compromise security (think 0days). Considering the saga with what happened when the iPhone's Touch ID sensors got disconnected for repair... if the system is ever figured out, it's likely it won't remain figured out for long (eg, next hardware revision = totally different protocols, etc).

  • fprint generally supports almost all the fingerprint readers that are out there, even though it's a couple years old now. It works, too; I just tried it on an old laptop I have here a few days ago, it immediately found the fingerprint reader, and enrollment (in the test GTK app) worked, etc etc. Fun! :)

    CAVEAT EMPTOR.

    Touch ID on the Macbook, iPhone (and hopefully Watch, in future?) are handled by dedicated secure processors, very probably secure memory, and lots of isolation. This makes the go/no-go that comes back very secure. But at the end of the day, the macOS side needs to go if (response_ok) { ... } else { ...}; let's see how long it takes for someone to find the critical cmp and make macOS think a bad read was actually a good one.

    Put another way, a perfect security system would take the digitized, normalized output of the fingerprint reader and use that value directly as eg a dm-crypt passphrase or similar. That means your fingerprint is literally the password, which is the intuitive interpretation... and it would be really awesome if that was actually how it worked, but perhaps unsurprisingly, fingerprint readers seem to generally just do "yup, I know that fingerprint" or "who r u???", and it's the (fragile!) software side that needs to divert off eg unlocking the system or completing the transaction if the fingerprint was bad.

    As I said before, I'm not sure if macOS has some authentication chatter in the verification process besides the basic proprietary protocol being used. Basic Touch ID stuff probably just gives a binary "ok"/"fail" as described above, but the Apple Pay part is likely likely more sophisticated, maybe even with keysigned messages that go straight from Apple's servers into the T1 for verification (via PKI keys burned into secure memory). That would be the right way to do it, and it sounds like they may have achieved that.

    On Linux, the critical cmp that acts upon the fail/ok response is running typically in a root-level process (eg pam_fprintd.so), not squirrelled away in something like SMI (ideal, but impossible) or even the kernel. ¯_(ツ)_/¯

TL;DR: just use your fingerprint to unlock your computer, it's basically just a button at the end of the day because of how fingerprint readers are implemented. Great for making it utterly impractical for someone to keylog your laptop while your back is turned for 5 minutes, but woefully insufficient insecurity for eg unlocking an encrypted disk.

PS. Some fingerprint readers are capable of imaging, which (perhaps obviously) gives you a copy of the fingerprint image/scan (incidentally, the old fingerprint reader I played with only has imaging support via the Windows driver, the data stream to the Windows driver is horribly obfuscated sadly), but that would need to then be normalized via some recognition algorithm. Basically fingerprint readers as implemented on PCs are, like TPM enclaves, paper tigers.

i336 avatar Oct 31 '16 12:10 i336

@i336 A few notes:

• Touch ID stores a one-way hash of your fingerprint, not your fingerprint itself • The issue you mention with booleans is only true if you use the LAContext API. You can instead encrypt a password (or other information) with the Touch ID hash using SecAccessControlCreateWithFlags. You can pass touchIDAny or touchIDCurrentSet depending on which access level you want.

getaaron avatar Oct 31 '16 16:10 getaaron

Oh, interesting!

  • Touch ID stores a one-way hash of your fingerprint, not your fingerprint itself

A hash makes perfect sense: the raw fingerprint data is going to be different (angle, pressure, ambient light, ...) every time, so it needs to be normalized and sanitized somewhat. My fingerprint reader handles this in the most dismal way possible: successful enrollment (swiping 3-4 times) causes the controller to emit a 200 byte binary blob that you're supposed to receive then save to disk, then feed back to the controller at verification time. After thinking about it for a bit I haven't been able to come up with an interesting sounding attack for this mechanism, but I far prefer the fact that Touch ID (presumably?) stores the hash in secure memory. (It does, right?)

  • The issue you mention with booleans is only true if you use the LAContext API. You can instead encrypt a password (or other information) with the Touch ID hash using SecAccessControlCreateWithFlags. You can pass touchIDAny or touchIDCurrentSet depending on which access level you want.

Oh, that's nice. How does that work? Streaming the data through the secure processor, which encrypts/decrypts it without revealing the key?

i336 avatar Nov 01 '16 02:11 i336

Unless you have Linux running on a new MacBook, it would be useless.

That's what I would assume the request is for.

So is there any interest in this, or is it too out-of-scope?

WhyNotHugo avatar Mar 23 '17 14:03 WhyNotHugo

I'd say this is out of scope.

serverwentdown avatar Jun 13 '17 15:06 serverwentdown

Yeah, I did some research since my last comment here, and the hardware for the TouchBar/TouchID isn't even supported on linux yet, so there's no chance of this happening for now (I'm keeping an eye for future's sake anyway, I still have a 2015 model).

WhyNotHugo avatar Jun 13 '17 15:06 WhyNotHugo

Just use PAM. It's already supported and been supported for years. (You can get fprint detection and such with fprintd, which may need a driver for touchid. I swear I read that someone wrote an initial one though.)

akatrevorjay avatar Mar 09 '18 20:03 akatrevorjay

I'm actually confused a little that the osx version of sudo doesn't use pam anymore? They may have continued moving away from it for all auth purposes for all I know at this point (been a few years since I've used it heavily). If it requires a sudo fork due to that, then man, that's a really gross thing to move towards [Apple]

akatrevorjay avatar Mar 09 '18 20:03 akatrevorjay

what about this, fprintd supported only swipe so what if we do instead of swipe we can use touch so it work like macos touch id. but the problem is fprintd support only swipe. although windows support touch fingerprint support.

unknowntounknwon avatar Dec 12 '22 11:12 unknowntounknwon