[HN Gopher] Use TouchID to Authenticate Sudo on macOS
___________________________________________________________________
Use TouchID to Authenticate Sudo on macOS
Author : DerekBickerton
Score : 184 points
Date : 2022-08-26 18:54 UTC (4 hours ago)
(HTM) web link (it.digitaino.com)
(TXT) w3m dump (it.digitaino.com)
| jarym wrote:
| I wonder why Apple haven't made this a default on TouchID Macs?
| matthewfcarlson wrote:
| I believe it makes ssh not work great since if you ssh into the
| machine and do sudo, there's no way to put your finger on the
| sensor
| [deleted]
| lelandfe wrote:
| I mean, practically - probably not a ton of demand for a
| cooler, better `sudo`
| blowski wrote:
| I see this post pop up often so I think there's demand. But
| Apple only cares about solutions that make money, and this
| one doesn't. With Apple, I'd expect them more to block free
| solutions, and require an iCloud subscription to enable it.
| Jtsummers wrote:
| Is this just anti-Apple nonsense, trolling, or do you
| really believe that Apple would add an iCloud requirement
| to enable auth via fingerprint reader (an authentication
| method that already works for many other things without an
| iCloud subscription)?
| yyyk wrote:
| I tend to be critical of Apple, but the spectre of them
| charging for sudo is absurd. I suspect that the actual
| reason is boring: This is a developer oriented feature and
| these features aren't judged as important as other stuff.
| dhosek wrote:
| Probably because a _lot_ of damage can be done with sudo.
| dmitriid wrote:
| More than with Touch ID/Face ID that are used in a shit ton
| of places?
| gumby wrote:
| I did this when the touch ID macs were first released and very
| quickly disabled it.
|
| Why? Because asking for a password for su / sudo broke the flow
| -- not only did I have to move my right hand from the home row
| (or both, for my watch), but it popped up a modal-like window
| away from where my eyes were. Basically it impinged on my focus.
|
| Nice idea, not so nice in practice.
| impoppy wrote:
| Fun fact: if your laptop has an IR camera, you can also use face
| recognition for that purpose.
| vonseel wrote:
| More details? Is that an included auth mechanism with MacBooks
| or something you can install from GitHub?
| dixie_land wrote:
| After this setup. What happens when you SSH onto your Mac and run
| sudo?
| impoppy wrote:
| It is just an additional authentication mechanism to a list of
| various ones. If the client (COM port terminal, KVM terminal,
| SSH client, bare /dev/tty or any other client you can think of)
| does not support this mechanism, it will go for another one.
|
| UPD: https://en.m.wikipedia.org/wiki/Linux_PAM
| JLCarveth wrote:
| Just tried this. It asks for your password via the terminal as
| usual.
| leonewton253 wrote:
| You have to put it below the first line, like in the example.
| JLCarveth wrote:
| Huh? I know that. I read the article myself. I was
| answering OP who was asking "What happens when you SSH onto
| your Mac and run sudo?".
| kelnos wrote:
| I know PAM gets criticized here and there, sometimes heavily, but
| it's actually a super flexible system. The thing that really
| stands out is that no application actually needs to know about
| all the various authentication methods possible. That file in
| /etc/pam.d/ just corresponds to the app's "service name", and you
| (as the machine administrator) can put in it whatever you want.
| The app just needs to go "Hey PAM, I want to start authentication
| using service 'sudo'", and then PAM will send instructions to the
| app, like "Display the text 'Place your finger on the fingerprint
| scanner'", or "Display the text 'Password:' and then prompt for
| masked input".
|
| It's really quite flexible, and despite its age, still works
| pretty well with current programming paradigms, whether your UI
| is text or graphical or whatever. The one oddity is that when it
| asks you to prompt for some kind of user input, it will actually
| expect you to return the resulting input from the same callback
| function. So if you're using a modern-ish GUI toolkit, you'll
| need to run the PAM stuff off on a different thread that's
| allowed to block while your UI thread is free to do what it needs
| to do. But overall that's just... fine?
| chatmasta wrote:
| The API for "Pluggable Authentication Modules" (PAM) seems to
| be earning its name. It's an ideal adapter layer for adding
| interoperable authentication to any program. And since so many
| programs already consume it, it's a natural target for new
| authentication providers to implement. If a backend can
| serialize its authentication model to users and groups, then it
| can give those lists to a program that consumes them through
| PAM to authenticate users and authorize actions.
|
| Thanks to open standards (really POSIX in this case), even a
| small program can immediately benefit from PAM authentication
| because it will work in any organizational environment,
| regardless of whatever over-engineered backend system (like
| LDAP or Kerberos) or SaaS (like Okta or O365) is providing the
| list of users and groups.
| KMnO4 wrote:
| I was really hoping the article would have explained a bit
| about PAM. Any high school English teacher can Google
| instructions for enabling sudo with Touch ID, but I've come
| to expect HN posts to have a higher pedigree.
| chatmasta wrote:
| Yes, I thought the same while I was googling to ensure my
| comment wouldn't betray the fact that I've never actually
| implemented PAM myself. :D (I've certainly benefitted from
| it though!)
|
| When exploring a technology I like to search GitHub for it,
| since that should surface a healthy sample of code that
| uses it. For instance the "pam" topic looks like a fun
| rabbit hole to click into, with a list of repositories
| demonstrating a wide array of use cases for PAM. [0]
|
| [0] https://github.com/topics/pam?o=desc&s=stars
| ctur wrote:
| Every MacOS update, I do run a sudo command and get the password
| prompt. I cancel, and instead do... sudo cp
| ~/Dropbox/etc-pam.d-sudo /etc/pam.d/sudo
|
| Type the password once and you're done. I've been carrying this
| around for quite a while. No need to edit the file every MacOS,
| just copy it.
|
| But once it did utterly go south when Dropbox's "load files on
| demand" functionality replaced the file with a bunch of zero
| bytes. That wasn't fun to fix. So maybe Dropbox isn't the best
| storage place.
| loeg wrote:
| Everyone does this, right? It's super convenient except that
| macOS nukes the pam.d config file every update.
| tokinonagare wrote:
| No. I only use sudo in "sudo su" once in a while when I need a
| root shell (sometimes not even on the local machine), then does
| everything within that shell. I don't understand people
| bothering themselves with that command. I also find egregious
| tutorials in which each command is prefixed with sudo.
| vbezhenar wrote:
| sudo -i
| jph00 wrote:
| Here's a single line you can run that'll add the needed line to
| the file in the correct place for you: sudo
| perl -pi -e 's/(pam_smartcard.so)/$1\nauth sufficient
| pam_tid.so/' /etc/pam.d/sudo
| DavideNL wrote:
| For some reason this often doesn't work for me; it seems to
| randomly only respond to my Watch to authenticate this, but not
| TouchID...
| inickt wrote:
| Does watch unlock now work natively with pam_tid? I know as of at
| least a few months ago it would only work if you could use touch
| ID, i.e. when the laptop was open. If it was docked, it would
| fall back to password auth.
|
| I wrote a patcher that changed this behavior, it patched pam_tid
| directly on your system and just updates the API Apple calls to
| allow unlocking with watch-only when touch ID is unavailable:
|
| https://github.com/inickt/pam_wtid
|
| Was a fun reverse engineering experience and wrote up some more
| info in the README.
| apetrovic wrote:
| I'm using this to authorize sudo (and other things) with Apple
| Watch:
|
| https://github.com/insidegui/pam-watchid
|
| ... and my /etc/pam.d/sudo needs to be changed like this:
| # sudo: auth account password session auth
| sufficient pam_watchid.so (...)
|
| This needs to be applied after every system update. Apart of
| that, it works really well (I have very dry skin so touch ID
| works for me 50% on a good day)
| makeworld wrote:
| I've also done this on my Framework laptop running Linux, it's
| really convenient. Have it set up for sudo, user login, etc. Just
| added this to various files in /etc/pam.d auth
| sufficient pam_fprintd.so
| danieldk wrote:
| I tried this just over a year ago, but it is quite flakey. IIRC
| because of how PAM works, you have to wait until this PAM
| module times out before you can switch to another form of
| authentication. (E.g. because fingerprint authentication
| fails.)
| dna_polymerase wrote:
| Lol, just learned my laptop has a fingerprint reader.
| kitsunesoba wrote:
| On my ThinkPad X1 Nano, GNOME under Fedora 35 and 36 offer the
| ability to use the fingerprint sensor for login and sudo in the
| Settings app. Pretty nice.
| epistasis wrote:
| Not exactly connected but the same crowd interested in this topic
| may also be interested in this tool to store SSH private keys in
| the Secure Enclave, kind of like what can be done with a YubiKey:
|
| https://github.com/maxgoedjen/secretive
|
| I've been looking for something like this for 3-4 years but only
| found it six months ago (in an HN thread). I use separate keys
| for every use case, and now know every time a key is used for any
| purpose, whether it's connecting to source control or my text
| editor is connecting to a remote VM.
|
| Only thing I haven't figured out is how to do git signatures with
| these sorts of keys, but I haven't debugged it at all.
| trhway6552 wrote:
| I've been using https://github.com/sekey/sekey for years now!
| It handles gpg as well
| maxique wrote:
| I think 1Password's SSH agent does this now, too
| CharlesW wrote:
| I didn't know that was a thing, thank you!
|
| https://blog.1password.com/1password-ssh-agent/
| danieldk wrote:
| But it's not really the same. Having private key material in
| the secure enclave means that it's not extractable (except
| perhaps by state-level attackers with hardware access). With
| an SSH private key in 1Password there are still many possible
| software-level attack vectors (vulnerabilities in 1Password,
| a compromised 1Password update, etc.).
| Axsuul wrote:
| Note that there are some pretty significant caveats to
| Secretive:
|
| - You cannot import your existing SSH keys
|
| - You cannot transfer SSH keys if you get a new machine
| adastra22 wrote:
| That's the whole point, no? Tie identity to the machine
| itself, not a piece of data that can be stolen.
|
| BTW, if you have a key that you copy around to multiple
| machines, you're doing it wrong!
| epistasis wrote:
| Exactly, these are precisely the features I'm looking for.
| They are not caveats, they are the way I want my keys to
| behave.
|
| If there is some sort of use case where I want to be able to
| backup a key, or share it with someone else I can always fall
| back to SSH keys on a hard disk. But those are usually anti-
| patterns.
| vbezhenar wrote:
| Why those things are not built-in to macOS. I don't understand.
| It should not be hard to implement for Apple engineers and it
| could be a good example for corresponding API.
|
| I don't use sudo often enough to warrant system changes, so I
| don't use those programs, but if they would be enabled by
| default, I would gladly use them.
| dmitriid wrote:
| Another pet peeve is: why can you auth with your watch but
| not your phone?
| Jtsummers wrote:
| It would be nice, but the phone would have to be unlocked
| at the same time you try to authenticate on the computer
| for this to work. Part of why it works with the watch is
| that you have to have an unlocked (but pin-lockable) watch
| near the computer. Most of the time when you're wearing the
| watch it will be unlocked (this is the default behavior,
| after unlocking it stays unlocked while worn) whereas the
| phone will relock itself. So it would be useful, if you
| happened to have already unlocked your phone near your
| laptop, but probably not as consistently useful as the
| watch. Most of the time, you'd find yourself unlocking your
| phone to unlock your computer which is not really
| convenient, so you'll just unlock the computer itself.
| dmitriid wrote:
| This would be useful in the case when laptop lid is
| closed. TouchID/FaceID are still very fast
| vouaobrasil wrote:
| It is because Apple will use their own authentication-key
| approach with Apple passkeys, which stores a key pair on a
| person's iPhone.
| wahnfrieden wrote:
| small returns on a small market for prioritizing the work.
| maybe you're unhappy with the profit seeking system
| drdaeman wrote:
| Are software developers really a small market?
|
| There is probably low priority/ignored because most
| developers can easily do this on their own, so it's not
| really worth the hassle.
| leesalminen wrote:
| Some googling shows ~20 million software developers
| around the world. Some googling shows roughly 2 billion
| households globally and 50% of them have a PC in their
| household. So let's say 1 billion PC users.
|
| 20 million / 1 billion = 2%
|
| So yes, it seems like a small market relatively.
| rjzzleep wrote:
| They were a significant portion of getting OSX to the
| masses, but became less and less relevant to Apple over
| time.
| kitsunesoba wrote:
| Secretive is great. I use it on my T2 and M-series Macs and
| feel much better with keys sitting in those machines' secure
| enclaves than I did back when it was just sitting in ~/.ssh/
| for anything to grab.
|
| I just wish there were something as clean as Secretive for
| using generic PC TPMs or YubiKeys in place of a Secure Enclave
| under Windows and Linux. Currently have a Linux laptop halfway
| through setting that up and it's messy in comparison.
| judge2020 wrote:
| For Windows, it seems it's possible[0, see footnote], however
| there are problems like general incompatibilities [1], and
| official support status is " We have this in our backlog. At
| this point it's not prioritized.".
|
| 0: https://github.com/tavrez/openssh-sk-winhello
|
| 0.footnote: "Windows Hello also supports other types of
| authenticators like internal TPM device(if they support
| generating ECDSA or Ed25519 keys, they can be used instead of
| FIDO/U2F security keys)."
|
| 1: https://github.com/tavrez/openssh-sk-winhello/issues
|
| 2: https://github.com/PowerShell/Win32-OpenSSH/issues/1804#is
| su...
| boustrophedon wrote:
| It's actually very easy on linux now: You just use the two
| -sk key types released in Feb 2020
| https://www.openssh.com/txt/release-8.2
|
| `ssh-keygen -t ed25516-sk` or `ecdsa-sk` and then you touch
| your yubikey when unlocking the key, the same time as you
| would type a password.
|
| Question for anyone else reading: Does it make sense to use a
| password with -sk keys? I don't think it would make a
| difference either way.
| frutiger wrote:
| > Does it make sense to use a password with -sk keys? I
| don't think it would make a difference either way.
|
| Only if you want to protect your keys from being used by
| someone that has access to the private key + yubikey (i.e.
| someone physically present).
|
| In other words, the -sk type private key is useless without
| the yubikey as well.
| boustrophedon wrote:
| Physical presence makes sense. I didn't really think it
| through but it's just the same as any other 2FA: you want
| something you know and something you have. Thanks.
| computing wrote:
| To get this to work inside of tmux sessions use this:
| https://github.com/fabianishere/pam_reattach
| r0m4n0 wrote:
| Not to knock on this too hard because it seems cool and useful
| for 98% of people out there but touch id does have an unfixable
| vulnerability. If you are security obsessive, maybe no touchid
| altogether on your mac (I use a token).
|
| https://arstechnica.com/information-technology/2020/10/apple...
| muricula wrote:
| I'm fairly sure that checkm8 doesn't affect apple silicon macs.
| olliej wrote:
| Happily the exploit doesn't exist in any of the arm macs.
|
| That said the checkm8 exploit requires (as far as I'm aware)
| physical access to the target device, which is a fairly
| constrained attack vector for any real world attack. Obviously
| if you are at risk of such attacks though then your risk
| profile is _vastly_ different and the steps you need to take
| are also different.
| DavideNL wrote:
| tldr;
|
| " _But the T2 also contains a vulnerability, known as Checkm8,
| that jailbreakers have already been exploiting in Apple 's A5
| through A11 (2011 to 2017) mobile chipsets. Now Checkra1n, the
| same group that developed the tool for iOS, has released
| support for T2 bypass._"
|
| "Computers that have the Apple T2 Security Chip":
| https://support.apple.com/en-us/HT208862
| jolux wrote:
| What about on apple silicon macs?
| olliej wrote:
| Seems like not (but I was just doing lightweight googling out
| of the same curiosity), the last exploitable generation of AS
| was iPhone X, which I _think_ predates the AS macs. Also as
| far as I understand exploitation would require physical
| access to the target device.
| maxique wrote:
| > Keep in mind that this file is somewhat protected by macOS so
| after each OS update you will need to add the line to the file.
| Other than that, it works perfectly!
|
| TIL, I wondered why every time I did this it would reset after a
| while. Thanks!
| shinzui wrote:
| I use nix-darwin to automate that.
| linsomniac wrote:
| More details please.
| shinzui wrote:
| nix-darwin currently does not support that directly, but
| there is an open PR to fix that. For my dotfiles, I added
| the module from the PR with some slight modifications. You
| can find the code below.
|
| https://github.com/shinzui/dotfiles.nix/blob/master/modules
| /...
| latchkey wrote:
| I've been wanting to write a simple script or app that just
| runs on startup to check for and fix this, but I've been so
| lazy. It is just too easy to edit the file and move on...
| jackson1442 wrote:
| I'm even lazier, stole another commenter's script and just
| have it run on reboot.
|
| Is it idempotent? No, every reboot it adds the line again.
| Doesn't appear to matter though.
| eevilspock wrote:
| I added this to my `.bashrc`: if ! grep -q
| "pam_tid.so" /etc/pam.d/sudo ; then echo "touch ID no
| longer enabled for sudo. Insert the following line as line 2 in
| /etc/pam.d/sudo:" echo " auth sufficient
| pam_tid.so # enables touch id auth for sudo" fi
| can16358p wrote:
| I never understood why this isn't enabled by default in the first
| place.
| eevilspock wrote:
| Previous discussions:
|
| 2021.03.01: https://news.ycombinator.com/item?id=26302139
|
| 72 days ago: https://news.ycombinator.com/item?id=31750560
| rez9x wrote:
| I like that you can do this and appreciate the knowledge, but it
| seems slower than just typing in your password, and kind of
| breaks my flow by removing my hand from the home row.
| vonseel wrote:
| That depends on how long your password is I guess. I much
| prefer Touch ID personally it probably takes about the same
| time as typing my password but there's no chance of a mistake
| or typo. It's pretty seamless in my experience.
| path_to_file wrote:
| In the same vein, I recently made a tool to use TouchID and the
| Secure Enclave to protect arbitrary data and env variables from
| the commandline: https://github.com/pathtofile/toucli
___________________________________________________________________
(page generated 2022-08-26 23:00 UTC)