Use Touch ID for Sudo on Mac | Hacker News Reader

Use Touch ID for Sudo on Mac

davidwalsh.name

510 pointssyck214 comments

This is amazing -- but every. single. update. disables it again

Why does the sudo file not persist between updates? This case is quite minor for personal computers, but what about companies that log in with yubikeys or smart cards? Do they have to reconfigure after every update too?

I’ve just added this to my .bash_profile:

  enable-sudo-touchid() {
    sudo sed -i -e '1s;^;auth       sufficient     pam_tid.so\n;' /etc/pam.d/sudo
  }

But probably automating the check (if the automated checker has the correct permission) would not be that hard.

The hard part with these kinds of fixes is that they evaluate every time you create a new shell or tab, which for me is very frequently.

It’s already starting to add noticeable latency from all of the various eval statements in there.

Edit: I missed it’s a function def which should be fine speed wise.

That's a function definition, the only overhead will be parsing, not evaluation.

A step further so you don't have to think about enabling it:

  sudo() {
    unset -f sudo
    if [[ "$(uname)" == 'Darwin' ]] && ! grep 'pam_tid.so' /etc/pam.d/sudo --silent; then
      sudo sed -i -e '1s;^;auth       sufficient     pam_tid.so\n;' /etc/pam.d/sudo
    fi
    sudo "$@"
  }

Thanks! That looks good!

Thought on the second thought, I’ll continue to use the more “manual” method for now. As it gives me more control and it would be easier to switch off when touch ID sudo will be supported more officially.

Here's another function in Fish that incorporates the other suggestions offered in this thread.

    function sudo --description "Execute a command as another user."
        if [ (uname) = "Darwin" ]
            set --local needle "^auth\b.*\bpam_\(reattach\|tid\|watchid\)\.so\$"
            if ! grep $needle --silent /etc/pam.d/sudo && \
                [ -f /usr/local/lib/pam/pam_reattach.so* ] && \
                [ -f /usr/local/lib/pam/pam_watchid.so* ]
            command sudo sh -c "
            cat << EOF >/etc/pam.d/sudo
    auth optional pam_reattach.so
    auth sufficient pam_tid.so
    auth sufficient pam_watchid.so
    \$(grep -v '$needle' /etc/pam.d/sudo)
    EOF"; or return $status
            end
        end
        command sudo $argv
    end

Why not run a launchd script on boot that does the update? Does it need to be in the .bashrc?

Does `sudo chflags schg /etc/pam.d/sudo` work?

curl -sL https://gist.githubusercontent.com/RichardBronosky/31660eb4b... | bash

This helps.

This "download random script from internet and execute" thing is a terrible idea, even moreso to put in bash_profile...

Seems secure.

This is a very macOS problem. Why does it reset every preference on updates? The one that kills me is wake-on-lan, that gets turned back on regardless. Hate!

Back in the day I used to tweak my Linux box, win3.1/95, vim, android phone, etc. endlessly.

After awhile they would all become unusable, and I would reinstall everything back to default and try again. Great for leaning, lousy for day to day work.

Resetting things back to a known state can make life lot easier.

In 10 years I can’t recall needing to reset a Mac.

Because it does so itself. It is even worse to have lost settings than having windows rot. At least in Windows rot is the problem, not the fix.

Because, like ChromeOS/CoreOS, modern macOS now does image-based updates.

A macOS update isn’t “whatever was previously on your OS volume, plus arbitrary patch X”; rather it’s “a new, fresh OS disk image, written to a separate APFS volume, with a fixed SHA, with update transfer-size optimized by composing said image partially from files in your current OS, but only in such a way that the volume will still hash the same in the end.”

(In many ways, macOS’s update system now reuses the logic from iOS’s IPSW firmware-update system. You can even now download macOS updates from Apple as IPSW files, and then use Apple Configurator to push them to macOS devices.)

Unlike ChromeOS/CoreOS, after the first-round SHA verification of the volume, macOS will then patch the new OS-base-image volume with certain files from your current OS-base-image volume, if 1. they’re distinct from the ones it expected to be there, and 2. they appear on a whitelist of known-safe files.

If any of this patching happens, the OS volume’s metadata tree will then be re-hashed, and the new hash will be blessed by the volume-signing utility.

(If you’ve seen a “Recovered Files” directory on your desktop after an update, and it’s contained a “foo.system_default” file, that’s a copy of the file that macOS would have composed into the OS volume if it hadn’t found your known-safe customized file to use instead. /etc/shells is a usual trigger.)

Some preference files in /System/Library are known-safe; but others aren’t. It’s a whitelist, and it’s a conservative one.

Preference files in /Library live in the user volume, not the OS volume, and so will never be wiped. This is why most of the “trivial” preferences stick around.

Note that by “known-safe” here, I don’t mean “can’t be customized to malicious ends.” This isn’t a security thing. It’s an ABI stability thing. These files are safe in that they’re known to have the same ABI format between OS versions, and so keeping a customized version of them around won’t confuse newer versions of system daemons.

It’s about the same as if Linux had a set of known-safe DKMS modules that use interfaces that the kernel intentionally doesn’t change between releases, such that the kernel module files composed from those DKMS modules could be reused by the new kernel without requiring decompilation, rather than being tossed out at every single kernel update.

Why cant Apple use their TimeMachine tech to take a snapshot of the prefs on the existing, then do their image based update, then have it automatically apply the prefs from the timemachine mod-integration?

The richest company in the world can't think different?

They know exactly what files were customized in the previous OS-base-image. There’s a reason the whitelist is a whitelist, rather than a blacklist. Just guessing here, but it’s probably something to do with “iteration speed” vs. QA SLAs made to large enterprise customers like IBM.

In my hypothetical, there’s a set of preferences overrides Apple have been forced by contract to guarantee they’ll validate during their QA process, and then allow the OS to retain between updates. For any other file not forced by contract, they don’t bother with that QA process (“takes too long!”), and so default-distrust the ABI-stability of the file, and so don’t let the OS retain it between updates.

What if one file was written by a malicious program?

Ya I think saying it’s not for security is making a lot of assumptions.

You know =what would be cool: If all apps had to register their pref config files into a single dir and that would be tracked and snapshotted - and then you could just have ALL apps look to the same dir for where their configs come from and you could have a single repo for ALL apps on your or ANY system - and then you could walk up to a terminal and plug in your "license key" which said what apps you had access to and what ones you had configs for and you could just run that app with all your input and prefs and mappings etc...

I actually wrote a white paper on just this in ~2003 or so - and met with several engineers from google and they said it was impossible.

The idea being that you only carried around with you your profile, and you could just come to a dumb terminal, plug in your key, three factor auth - and the terminal would give you access to the apps and resources they had...

(I should write ((again)) a short story on this)

> they said it was impossible

What reasons did they name?

OK, disclaimer - I am going on over a decade since this happened:

There was a phone that came out (nokia??) that had a docking station and you could have a screen on it and a keyboard attachement etc...

I presented this in ~2004-ish as a white paper... (lost to hundreds of machines since, and poor data mgmt over time)

I met with a few engineers friends from google over this idea and they said they didnt think it was possible (which at the time it was not - even though I wrote about it in 2001) - and then there was that phone that came out which allowed you to have a phone docking station and use it as your primary computer.

This was at the same time whilst I was talking to my buddies at Intel about stacked procs - and they were doing 64 cores in ~2004 in test dies... and they worked.

It was in 1998 when I was at Intel that I asked "Why cant we just stack multiple CPUs on top of eachother?" and was laughed at...

I sat right next to Andy Grove, but I only spent all my time in the DRG Game lab testing games on AMD and Celeron procs to get subjective results on game perf.

Anyway... I posed a lot of things that were laughed at, which then became reality later.

I worked with a MIPS proc eng about Slot-Rack-Servers, in 1995 - this was deemed impossible... later we have HPE based systems... His name was Kent... he was one of the chief MIPS designers...

I was saying "lets make 'slots' that we can install a switch, a server, storage or whatever on the backplane..."

Yes - I am not lying - these were just things I imagined in the early-mid-late 90s....

I had a good career - but I cannot take any credit for these taking production due to I didnt ever implement any of these ideas... aside from expressing them earlier than others who were far more capable of executing.

Its just like IFTT - I literally whiteboarded IFTT for a bunch of engineers from Lockheed a few years before that existed... They have built a lot of what you interact daily with (netflix) among others...

My soul flaw - is that I think of something early, I have no ability to bring it to fruition and even though I have exceptional famous engineers as friends, I cant bring my ideas to market...

and then a few years later - things I designed hit the zeitgeist and hit market...

I have, as a consultant, made people MANY billions of dollars - and havent received anything in return.

This was basically the idea behind the Windows registry - a single configuration store. With mostly the same tree structure on Machine and User level, so your local prefs could override machine-level prefs. The 'user' part was portable between machines on a domain. And you have a single API to access or change settings

Opinions may differ on how well it was executed in practice. I'm not sure /etc/ with its hundreds of different file formats and Ansible or Chefs as an 'API' is that much better

> This was basically the idea behind the Windows registry.

Was it? I got the impression that the original (Windows 3.1) registry was a Windows-internal thing—a store of Windows settings, and a set of APIs to read and modify those Windows settings, e.g. COM/OLE class registrations. (See https://devblogs.microsoft.com/oldnewthing/20080117-00/?p=23...)

But then, third-party ISVs found the registry, and exploited it to store their own settings. And Microsoft being Microsoft, they accepted that unilateral design change and continued on with it.

Prior to the registry most settings were in files like WIN.INI, and ISVs put settings there. The registry took this idea, added more structure and an API so simultaneous writes don’t screw up.

With the registry, each vendor puts its stuff under a path like HKEY_LOCAL_MACHINE\Software\VendorName, even Microsoft.

Yep. The INI files were the original ways to store config info...

The registry was the next step. What would be great is an online serve for such - a machine gets booted and it asks for your config unam UUID etc - and then just slurps your snapshot down.

When I first heard about Active Directory (1998?) I thought it would work a bit like this - a distributed Registry.

This is somewhat how user defaults work already.

You already have to reboot into the Recovery environment and disable both System Integrity Protection (with csrutil) and OS root-volume signing (with bputil) in order to even (persistently) modify any of the files in /System now.

Malware can't do that, because there's no way for any executable that runs in the regular OS—and isn't signed by Apple—to get anything to automatically happen over in the Recovery OS.

(That's not to say you can't have persistent malware in macOS; just that it can't persist itself into the OS boot volume. It has to persist into the user volume—which is great, because that means the OS can, on boot, mount the user volume noexec and scan it for malware while running in a known-good base state. That's even without needing to boot into the recovery OS.)

So, other than OS updates, basically the only reason these files get modified is when people modify them manually. And the only people doing that are 1. people developing kernel extensions (or their friends, the Hackintosh community); and 2. enterprises burning low-level configuration changes into OS images for image-based deployment.

And both of those cases involve modifying things that are effectively "underneath the OS API abstraction", and therefore don't have the same ABI guarantees that the OS APIs themselves do. Thus the whitelist.

Thorough explanation, thank you.

Just my opinion here, but I feel like Apple again doesn't really care about power users. 98% of their users won't be making any customizations like this, so they don't care to spend money working on those "edge cases." Their primary mission is to sell devices and apps to average people who aren't tech geeks. And I don't think Apple cares about general purpose computing. I see MacOS getting closer to iOS with every update, and I'm betting that at some point we'll lose filesystem access and sudo access.

Have you ever been FORCED to upgrade/update against your will for a new release whereby you say NO NO NO - then you make the mistake of falling asleep with your phone plugged into the charger to wake to a forced update to your device?

Yeah - fuck apple - and fuck Jonny Ive - they claim to be the masers of all aspects of designs, but really they're they masters of /r/assholedesign

Their hardware is in the top 70th % - but their UX is IMO <25%

(just look at how many clicks you need to do certain tasks, such as bluetooth. They have a slide-up menu to toggle BT and WIFI - but you have to go to desktop->settings->bluetooth->(toggle it on off/refresh)->find the device-> "cant connect" - Toggle BT on both phone and device -> attempt to connect...

But you cant up-swipe hit BT and have it show you the FN menu on screen.

You cant backup and manage all your prefs via icloud - such that you can apply profiles, save profiles, etc from your device to your linked cloud account and say "I always want my privacy to be thus, these are the networks I trust.

Their photos library mgmt is absolute garbage. You have no photo details available to you.

Their albums are garbage.

There are so many interactions that require like 5x more clicks than they should.

Their screens suck.

Their device accessory ecosystem sucks and punishes you for profit with impunity.

They exploit chinese slave labor.

They try to charge you for flaws in the HW provided (recall the balloon battery problem?

I had a macbook pro CATCH FIRE while I was asleep in bed. They said they "recognize that was a safety problem, but because our engineers (after two months of having the machine) determined that at one time the liquid sensor was set off, we cannot replace your machine EVEN THOUGH IT WAS UNDER RECALL FOR THE CLASS OF PROS THAT WERE RECALLED FOR CATCHING FIRE.

FUCK APPLE.

That’s a lot of anger and words over something that, in the grand scheme of things, is so utterly unimportant and almost contemptuously irrelevant.

Things are always a trade-off. There are big positives to keeping the ecosystem on a consistent, new and secure version of iOS. Similar positives apply to MacOS.

The problem I have with your argument, is you assume that my frustration is just over a single device from Apple.

I have literally had every single apple product since the Apple ][e -- aside from their server systems.

I have had every iPhone (even had pre-launch phones from them) since launch up until I stopped at the 6s+ which is the only phone I will ever own from them.

I have a history with apple that is not shallow and I have had ~35 years of judgement against them.

I recall getting into a talk with a fellow engineer at Lockheed where I said "Trust me, Apple will switch to intel procs - and this apple boi almost had a heart attack saying that would NEVER happen...

https://en.wikipedia.org/wiki/Mac_transition_to_Intel_proce ssors

Yeah that happened ~2 years before it actually occured...

(I used to work for intel and have stories about trend prediction there as well...)

So yeah, I'm solid in my position of what I know to have happened...

Maybe the first point or four. The subsequent ones? They actually seem pretty serious.

His macbook catching on fire is pretty darn important

The thing that doesn't make sense here is that macOS discards randomly your settings, but it is also the only OS I use that regularly gets in a fucked up state where settings have to be nuked. I mean, here we are in year 37 of the mac and people are still zapping their PRAMs. The only improvement is you don't have to physically pull out the battery.

In year 37 you can't manually zap the 'PRAM' on Apple Silicon Macs.

True, but I guess 95% of mac users are still on Intel macs, are still being told by "genius" bar frontline support to reset the SMC / zap PRAM for any kind of issue, and this usually works, too. Jury is still out on whether the M1 auto-zapping architecture is better, or will just be more prone to being permanently messed up.

Well, the fact that nobody ever has to zap PRAM on an iOS device means that they’ve probably fixed that (or, since you can’t zap PRAM anymore, people just restore the device instead...)

> but it is also the only OS I use that regularly gets in a fucked up state where settings have to be nuked.

Windows gets into this state fairly quickly, too, but the failures are less dramatic so we just live with it.

At least with Debian, it only happens when I deliberately change stuff! Though the `xorg-server-video-intel` driver breaks features of post-2007 Intel cards, and it's installed by default, so… perhaps it isn't the perfect OS either.

Purely anecdotal, of course, but:

- If macOS is the only OS that you use regularly that gets in a fucked up state, then either you're not using Windows or it's gotten a lot better in the last few years. :) (I mean, it undeniably has gotten better, but I have Windows-using acquaintances who still kvetch about this issue pretty regularly.)

- I've been using Macs since 1999 and I don't think I've had to reset the PRAM to fix a problem since my Titanium MacBook Pro circa 2007. I've had to nuke other settings on occasion, but still generally have markedly fewer problems than I did in my Windows-using days. (Which were more recent than 1999, but still not that recent, so back to the "I'm sure it's better now" disclaimer.)

But, Apple definitely needs to have a better mechanism for managing config file updates than "yeah, we've put a few old config files in subfolders of this 'RecoveredFiles' folder, maybe they're useful, maybe they're not, good luck."

Windows definitely allows you to shoot yourself in the foot, but nowadays those settings are hidden away by non-flashy applications, which has now become synonymous with "advanced user shit I probably shouldn't be touching".

Though the difference is, if something gets royally screwed up on MacOS, at least there's a sane enough way to reset it. On Windows, it often entails a reformat.

And let's not get started on the Windows Updates. They too have the whole "reset settings" problem (e.g. "don't f&!king restart my computer randomly", which gets reset every somewhat major update).

Computing has changed since 2007, so you have to include Android, iOS, iPadOS, ChromeOS, and various flavors of Linux in that lineup to be complete, not just Windows and OS X.

Well, in my admittedly anecdotal experience, Linux has less of a chance of getting FUBARed up by mysterious settings glitches. (I have had a Linux install get spectacularly FUBARed at least once from a broken update process, but usually it's happened through operator error, albeit sometimes aided and abetted by some program's spectacularly bad UX.)

As for the rest, my suspicion is that the newer "mobile generation" OSes both tend to get messed up much less often this way and tend to have much less recourse to the user when they do. That's certainly true for iOS/iPadOS and I suspect it's true for ChromeOS; I suspect Android is probably somewhere between iOS and Linux on that scale.

>Unlike ChromeOS/CoreOS, after the first-round SHA verification of the volume, macOS will then patch the new OS-base-image volume with certain files from your current OS-base-image volume, if 1. they’re distinct from the ones it expected to be there, and 2. they appear on a whitelist of known-safe files.

Red Hat CoreOS (and other Linux systems managed with OSTree, such as Fedora Silverblue) now do something similar by merging the current /etc directory with the "upstream" version.

Debian based systems use dpkg which has the option of confold and confnew. Difference is that the default is to ask the user what to do and unattended upgrades default to confold.

FreeBSD has an analogous mechanism called etcupdate[1]. I think Boot Environments[2] are pretty similar to SilerBlue but I don't know how BEs manage /etc.

[1] https://www.freebsd.org/cgi/man.cgi?query=etcupdate

[2] https://mwl.io/archives/2363

This is an excellent explanation. One last piece to clarify: there is no way to edit the known-safe list, is there? And/or there is no way to add a script after the update process that copies files like this, correct?

The list itself definitely lives in the OS base-image, so there’s a bit of a catch-22 there. (Imagine if it didn’t! That’d be a bit of an easy loophole for malware authors to exploit!)

I haven’t looked into it specifically, but I’m guessing that like many other basically-static system policy property-lists in macOS, the whitelist lives embedded in a Kernel Extension (kext)—probably the kext responsible for update validation. So you’d have to write your own kext to either replace that extension wholesale, or—hopefully—“inject” over just that element of it.

Of course, to run your own Kernel Extensions these days, you have to run your Mac in bputil --enable-kexts mode, which is “reduced security” from Apple’s perspective (reduced compared to the security model of iOS, they mean.)

On the other hand, the Hackintosh crowd have long agreed that it’s better to just “inject” data into the kernel/OS by either memory-patching the kernel during early boot (Clover), or patching the kernel as it’s being composed into a loadable image (OpenCore), rather than actually modifying anything in /System. (This was before modifying /System was even hard; they just didn’t like making a mess!)

I have a strong feeling that that same community that loves their little quality-of-life kext tweaks so very much, is pretty likely to come out with a way to use OpenCore as the boot-loader on real Apple-Silicon Macs, and thus to overlay arbitrary kexts into macOS without actually reducing macOS’s (OS-stage) security policy at all. (Provided you’re okay with the reduction in security of using a third-party bootloader, that is!)

This is great info I've never seen referenced elsewhere. It would be awesome if you would write a blog post explaining this in more detail!

This is a great answer for "how," but not "why."

The file in question is configuration and should not be part of the update image. (Better yet, Apple should surface this functionality somewhere reasonable, like the System Preferences.)

It may be an unintentional side effect, but doing this may prevent some degree of "Win rot", which Macos (and iOS) has also suffered from to a degree in the past. A huge number of mysterious iOS and Macos problems are caused by an accumulation of issues when config files of various types are "upgraded" along with the OS from one version to the next. If you look at all of the minor and major versions that come out in a year, small issues become large issues after being compounded by a couple of dozen updates.

There was an issue with iOS a few years ago that caused higher than normal battery drain when I was managing a department that supported a lot of iOS devices. A lot of users thought they needed a new battery. The battery drain issue was resolved for 100% of our users by doing an "Erase all data" and NOT restoring the backup. This process will still fix an amazing number of weird iOS issues in 2021, especially issues with the device slowing down, getting hot, or draining battery. It works because you end up with default config files that were designed for that version of the OS. If you restore the backup, often it will "restore" the problem you were trying to fix because the iOS restore process puts some OS config files back.

It will be interesting to see if Macos becomes less susceptible to win-rot type issues because of this config file reset behavior, as annoying as it may seem.

Does OS X not have /etc/sudoers.d?

It does, but this is a PAM configuration, so I'm not sure how /etc/sudoers.d would help...

Good point! :)

Apple needs a solution to this.

People getting their pf rules thrown away each time - it is like unlocking your front door each time you run the vacuum cleaner.

Did this work on iTerm?

Yes

It doesn’t (didn’t) play too well with the full screen hotkey windows.

The article will not allow sudo changes on Big Sur - at least, not without changing permissions of the sudo file first:

  1. sudo -Si
  2. chmod 644 /etc/pam.d/sudo
  3. vi /etc/pam.d/sudo
  4. Add the 'Auth         sufficient        pam_tid.so' line
  5. chmod 444 /etc/pam.d/sudo
  6. ...
  7. Profit!

Very handy tip though, thanks!

Or when using vi, just use :wq!

shift Z Z is faster.

Debatable and depends on length of time shortcut has been in use. I can type :wq like a madman. My finger can slide straight from w to q, whereas with double-z, I have to pick my finger up and put it back down. So much movement! What next, you want me to run a marathon?

I guess it's a learned dexterity thing.

:wq = <move finger of right hand to Shift> <depress Shift> <move finger of left hand to ;> <press-release ;> <release Shift and move finger of left hand and press w and q>

ZZ = <move 2nd finger of left hand to Shift> <depress Shift> <move index finger of left hand to z> <press-release z twice>

As someone with mildly poor dexterity (and I don't touch-type with all my fingers, I mostly use my index fingers), the second approach looks somewhat more interesting to test.

Interesting, I will add flexibility too, or maybe hand size. I find it slightly uncomfortable to hit shift and Z simultaneously with solely my left hand, so I hit shift with my right and z with my left. Alternatively, I will simultaneously hit shift + colon with my right, and then do the wq slide as mentioned above. Nice that all hands can be accommodated :)

This is going to save you seconds, every year!

That's all over the place from a touchtype perspective. 2nd finger? That's a pinkie. And you're supposed to use modifier keys from the opposite hand when available.

So it should be <move right pinkie to hold right Shift> <move left pinkie to hit Z twice>.

I honestly didn't know about ZZ, seems very convenient. :wq! on a qwerty forces the pinkie to travel all the way up to the top row, which is hell. On my home keyboard I use a layer for special characters, which helps, but still I guess I'll stick to ZZ from now on.

I’ve typed in :wq! so often I sometimes accidentally type it in when trying to do things like close browser tabs or exit programs.

You are all wrong. The Emacs shortcuts are far superior. /s

Here comes the `:x!` clan

[offtopic] zoinks fam that's some next-level bikeshedding

I don’t get it, the article shows it in 2 steps why the 5 step verbosity??

It seems in Big Sur the file you need to edit is not writable. So you need to make it writable first, edit it, and then change permissions back to read-only.

This doesn't seem to be strictly true - the two-line solution worked exactly as expected for me on 11.2.1. I used nano instead of vi (personal preference), but it worked nonetheless.

Maybe that's the difference. I was using vi, and not nano.

Have confirmed that using 'sudo nano /etc/pam.d/sudo' works fine.

No need for the verbosity when nano works I guess. :S

I usually just `sudo nano` it, works fine

`sudo --edit` also works

Emacs’ tramp mode supports sudo:

emc-sudo () {

local f="$(ec ${1} | gtr '"' '\"')"

emacs -e '(find-file "/sudo::'$f'")'

}

:w!

:wq!

s/vi/visudo/

visudo will lint the resulting file and (should) reject the change if it would break your system.

This isn't modifying the sudoers file, it is modifying the pam file.

Something weird going on, it still asks for password on the command prompt, if I press just Return key then dialog for touch id opens.. after touching it says `Sorry try again` (my touch id works in other places).

On 11.2.1

My bad, should have RTFA. It needs to be the very first line.

As a side note, there's also the wonderful pam_yubiko module that allows you to require touching your yubikey to sudo or login.

Yes, use this on my Linux machine. Works seamlessly.

wow... thanks for that. Didn't know that. Will need to read on that as well...

pam_yubico yes.

You can also use this to secure SSHD on servers by delegating to PAM with keyboard-interactive.

I'm waiting for U2F OpenSSH support to trickle down to stable distros but in the meantime pam_yubico is pretty damn good... not to mention you don't have to worry about terminal support since it relies on the yubikey OTP emulating a keyboard.

Very handy. But you can use your Apple Watch for sudo which is even better: [0]

[0] https://github.com/insidegui/pam-watchid

I agree using your watch is cool. However I think you lose out on the security aspect, an important element that a fingerprint provides all on the same device.

The watch unlocking mechanism only works if it’s in an unlocked state, i.e. you haven’t taken it off your wrist since the last time you entered your PIN. Somebody would have to double-press the side button on your watch while you were wearing it.

I think it’s not that bad, security wise. Your watch unlocks as soon as it leaves your wrist, and the unlock handshake uses the BT hardware to figure out how close your watch is.

I think this isn’t a great UX for other reasons I posted on this discussion. But the security is acceptable to me.

The watch is already used on other parts of the MacOS (anything in System Preferences), I don't think that sudo is much different than allowing kernel extension to run, for example.

>I think you lose out on the security aspect

Can you clarify what you mean by this? I love the idea of unlocking and running admin stuff with my watch but kinda gave up on the idea because I assumed there would be security implications. After thinking about it a little more, though, I haven't really been able to come up with anything that didn't already require physical access to my machine and some way to authenticate (password or fingerprint). Since you have to authenticate your device to authenticate the watch and it un-authenticates any time it's removed, it seems like you don't lose anything security-wise.

I'd love for iPhone and Watch to serve as a second-screen touch id for MacOS. Then I can tuck the laptop (or Mini) away, and not have to type passwords into various systems.

If you have a Touch ID Mac, enabling Touch ID for sudo also enables using an Apple Watch, so you can use either if you like.

If I remember rightly, this only works with the lid open.

That's correct, which typically defeats the point of using it since in that case you still have access to Touch ID. The above link works in both scenarios, and can be used as a fallback for pam_tid.

Ah, I never use clamshell mode so I didn't know that.

You have to take your fingers off the keyboard for this which is a big distractor, worse than using a mouse.

I use this feature for other touch cases (e.g. unlocking 1Password) but would hate it when in the flow.

Admittedly my password is well wired into my fingers.

I want a mouse with Touch ID in the button. Or on the side.

It would be cool if they built it into the touchpad in a future generation. I'm guessing once they can figure out fingerprint through the glass on iPhone they'll do it in the touchpad, too.

I'd have some concerns with this being trigger-able without positive intent to do so if it were in my mouse or trackpad. Having a small interruption can be beneficial for safety.

it could always come in the form of "click on this button," and it reads the fingerprint when you click the button.

I've always wondered why they can't just build a fingerprint sensor into a capacitive touchscreen. After all, a fingerprint sensor IS just a really high density capacitive touch sensor right? Or is that not right?

Google gives me no answers and I assumed it was not fundamentally impossible, just that it was two separate companies with two separate production lines making touchscreens and fingerprint sensors so it was hard in practice due to the realities of supply chains.

Many existing fingerprint sensors, like TouchID, were glass, and I wonder why they can't just make it bigger and put an OLED under that glass (even if it was only dense enough for fingerprints at one spot).

Yet here we are, 4 years after the downgrade too FaceID, and still not a single phone in existence with a capacitive fingerprint sensor in the screen.

Am I wrong about the technology or what?

If you use your little finger RHS print as a reference, perhaps that won't be too bad? On the keyboard it seems fairly reachable.

I haven't tried it myself ...

I did try that but it's a stretch worse that the extrema of Emacs.

The fact it is the last key in the first row makes it easy to find by touch without looking at it. Just like regular touch typing, it becomes habitual/muscle memory.

I haven't used a full size keyboard in so long, I had to think about the print reference. I have lost direct placement of Home/Print Screen/End type button locations in my memory. To be more accurate to the keyboard in question, it is a slight extension past the delete key. The only hazard is if you come up short, you might bring up Siri (depending on touchbar mode) which is an even bigger distraction. </pedanticmode>

> The only hazard is if you come up short, you might bring up Siri

Yeah - that is a deterrent.

Maybe that’s better, if you’re using sudo you should probably think a second before you do what you were going to do. I used to enforce the disclaimer coming up every time after I broke a package one too many times.

This made me realize my usage of sudo has gone down quite a bit. It seems like things mostly get permissions right these days, brew and ports were the main culprits back in the day.

I was thinking the same thing. Since I got my MBP16 I think the only times I’ve typed a password at all have been when the Touch ID session expires or whatever it is that requires reauth.

Having the ability to use Touch ID for sudo is handy. I’ve been using it for a while.

Coupled with `expect` I use it to authenticate through SSH (that is the only feasible option I got to connect to hosts I’ve got limited access). I even wrote about it: https://antonio-ramadas.github.io/blog/2020/10/30/ssh-login-...

Here is the gist of it:

  #!/usr/bin/expect
  
  # Connects via SSH to the host passed as argument
  
  set timeout 60
  set server [lindex $argv 0]
  set username <USERNAME>
  set password [exec sudo cat <PATH_TO_YOUR_PASSWORD_FILE>]
  
  spawn ssh $username@$server
  
  expect { 
   "yes/no" { send "yes\r" ; exp_continue }
   "\*?assword" { send "$password\r" }
  }
  
  interact

Edit: Please remove all permissions from the password file with:

  chmod a-rwx <PATH_TO_PASSWORD_FILE>

I’m also assuming you run this script on an environment you control and trust. Be wary of your password.

Use. SSH. Keys.

Yes, that is my recommendation as well. It is too late to add that to my comment now, but it is worth mentioning what I said should be a last resource solution.

Interesting, I hacked a small pam module together 4 years ago for the first generation of touch id enabled macbooks[0] and I wonder if pam_tid.so was always present and I just missed it. D'oh!

[0] https://github.com/spaghetti-/pam-touchid

You missed it by just a couple of months or so :)

pam_modules-159.50.4/modules/pam_tid/pam_tid.c appeared in macOS 10.12.4 https://opensource.apple.com/release/macos-10124.html

And macOS 10.12.4 was posted on Mar 27, 2017, according to https://support.apple.com/kb/DL1911

Every update requires you to redo this. It's so repetitive that I keep a copy of what I want `/etc/sudo` to look like in my homedir and, whenever I get the prompt for a sudo attempt, I instead sudo to cp the file. Then I go on my way with what I was originally intending.has recently sudo'd.

Rote but effective.

Why not run a script on boot that does the update? Does it need to be in the .bashrc?

If you run things under tmux, you'll also need this: https://github.com/fabianishere/pam_reattach

Ah, thanks! Was wondering why it wasn't working in tmux.

Does anybody know if there's a solution for keychain password copy too? I have a very complicated vpn password that I change often (so I don't remember it), but each day, when connecting to the vpn, I have to open keychain and type my user password to get the vpn password. I couldn't find a way to use touch id for that.

Out of curiousity why do you change a complex password regularly? Is this something your evilCorp policy forces you to do, or something you do out of habit because of something you read on the internet, or even rote habit from something picked up at previous evilCorp policies?

The evilItDepartmentPolicy forces me, but I would do it by my own will (less often) too, if not forced. I have acces on a lot of sensitive places and I don’t want to risk it.

Kinda close - I use Hammerspoon to setup a hotkey that runs security(1) via popen to retrieve and paste passwords into some apps.

    /usr/bin/security find-internet-password -wgs mydomain.com

It requires the keychain to be unlocked, which can be handled with touch ID, and you can have it confirm with a "are you sure" dialog box every time.

If you really wanted to be prompted for a fingerprint basically every time, you could probably use a separate keychain that locks after 1 minute of inactivity.

You can use your power button as a shortcut to autofill it from 1password or another password manager:

https://docs.sweeting.me/s/power-button-password-manager-sho...

> Since you expect to be be typing in a command line, moving your finger to touch the key is probably not very efficient.

Why is this not very efficient? Isn't moving my finger to touch the key equivalent to a single key stroke? How is a single key stroke less efficient then many key strokes?

Admittedly I've never used Mac's implementation but I could see a slowdown if it takes longer for the fingerprint to register that it takes to type your password (which is probably the fastest combination of characters you can type)

If you're touch iding everything you normally password for, you can afford to have a less fast to type password.

From my experience it's much faster. Just the tiny fraction of a second that it takes me to look at my caps lock key to verify that it's not on takes longer than my fingerprint scan and at that point I haven't even typed a single letter yet :)

Also it's arguably not the fastest combination of characters I can type, because my password is not "test1234" and I don't get much opportunity to type it at all anymore since everything can be unlocked via TouchID except the terminal, or so I thought at least :)

> Just the tiny fraction of a second that it takes me to look at my caps lock key to verify that it's not on

I always just re-assign the caps-lock key to CTRL.

CTRL when used as a modifier, escape on its own

> it takes longer for the fingerprint to register than it takes to type your password

You mean the black void where there’s no feedback on how many characters you typed? I always have to write my password a couple of times to get it right.

Normally I can type my password faster than pretty much any other activity. But on my MBP (with the terrible keyboard) I never know if all of my keypresses registered (or if some of them were duplicated).

I think it depends a lot on how long your password is, as well.

What type of work or activity on macOS requires sudo repeatedly enough that it needs to be automated in this way? I mainly need sudo for the occasional dmesg or for adjusting routes after activating my VPN for work.

Not that I install new software all that often, but macports requires sudo for quite a lot of operations.

Similarly for WSL2 using Windows Hello:

https://github.com/nullpo-head/WSL-Hello-sudo

I just have a setuid root sudo binary (compiled from sudo-touchid: https://github.com/mattrajca/sudo-touchid) in my home folder ~/bin. This has worked a treat across OS updates, without hacking PAM stuff. It’s extremely convenient and has probably saved me cumulative hours in typing out my long password :)

Was pleasantly surprised when Gnome on latest Fedora enabled this out of the box simply because the fingerprint reader on my laptop was supported.

BTW if any of you accidentally corrupted the file like me, this fixed things for me https://superuser.com/questions/1368246/accidentally-added-a...

Author admits 'probably not very efficient', but still a great SHORT article to consider something interesting. Thanks

I'm not sure about the "not efficient" part either. My password is 10+ characters, random alphanumeric with special characters. I sometimes mistype it. Whereas I'm yet to make a mistake tapping my finger on the finger print reader.

My current passphrase for work is 55 characters, so yeah, I could definitely see using this hack if I had to use sudo often.

(I'll probably shorten it soon, but it's a slightly mangled lyric from a popular song, so it's easy enough to remember.)

Add this to your .bash_profile so that you always have Touch ID and Apple Watch support for sudo: https://gist.github.com/carlosonunez/5b67afb9fd720bef6385e94...

Touch ID is awesome, but I semi-regularly use the APFS snapshot rollback feature and it erases my finger prints.

Does anyone know why this happens? I was very happy when I found out APFS is CoW but it kind of sucks that restoring an old snapshot apparently erases the secure enclave in my M1 chip.

The system will notice changes and disable certain features. I noticed my Apple Pay stopped working after a restore and there are additional settings that can turn off Apple Pay. Such as allowing boot from an external drive.

More than likely because that's a security risk. If it didn't do this, an attacker could likely roll back your machine to before you had Touch ID set up and then roll it forward again to access your data, now without a Touch ID restriction.

You can also use the Touch ID / power button as a shortcut to autofill a 1Password password:

https://docs.sweeting.me/s/power-button-password-manager-sho...

Original source / credit for this is probably: https://twitter.com/cabel/status/931292107372838912

What happens when your Mac has multiple user accounts, some are admins and some are not, but all have Touch ID set up? Would that inadvertently give sudo power to users who shouldn't have it?

(I don't have a Touch ID Mac to find out.)

No, it's bound to the user requesting sudo access.

Really surprising that Apple didn't include this by default.

For my accounts I usually just allow sudo to work without prompting for password by using the NOPASSWD configuration option. This saves a lot of time if you need to use sudo frequently (in my case I use it for system upgrades).

Unless I'm missing something, the security cost of this should be negligible, especially if you're in the habit of locking your computer screen when you're not using it (and this typically happens by default after a few minutes even if you forget). And if you're relying on the sudo password prompt to protect you against untrusted scripts, I'd argue you have bigger problems.

This is absolutely terrible advice!

Can you explain why? I'm genuinely curious in case I've missed something!

I'm guessing they meant because malware can now run commands as root without prompting for a password, however I'd argue that if you have malware running as your user in the first place then that will likely be more damaging to you than it getting root and modifying your system, as it will be able to access browser session cookies, personal documents, etc.

Personally I don't have passwordless sudo but I'm also curious as to what the attack vector might be here if you were to enable it.

If a virus/malware was running on your system as your user, it now has root access to your machine by doing nothing more than accessing the shell.

The virus/malware could change your $PATH or create an alias for some command that normally prompts you for your password (even sudo itself) and trick you into revealing your password to the malware. Maybe even install a keylogger depending on your OS.

Basically, if you have malware running as your own user, I'd be surprised if it couldn't find a way to trick you into typing your password to invoke sudo. Even then, it can probably do quite a bit of damage without sudo.

So then the only scenario a sudo password could possibly save me from is when I have malware already running as my user (and it's unlikely that it would help anyway due to the tricks I just mentioned). Of course everyone should do what they think is best, but personally if I were in this scenario it's pretty much game over anyway, so it's not something I'm going to worry about.

You also need to remove the line below, otherwise, you'll be asked to authenticate twice using both methods:

  auth       sufficient     pam_smartcard.so

Only if you currently have a smartcard configured. If not, you won't be.

I wish there was a way to use the regular password dialog to sudo on older macs, and persist that credential just like the touch ID pam module does.

Why?! What is the threat that you are protecting from? If someone has enough access to be able to run sudo on your Mac they already own you.

You might need to make the file writable before editing it:

  sudo chmod +w /etc/pam.d/sudo

Next step: SSH automatically paste password from Keychain/OnePass/LastPass after Touch ID.

Don't use passwords in SSH login at all and add your private passphrases to the keychain to unlock the key. The keychain can be unlocked with touch id

How does SSH knows my password is **** ??!

Use sekey: https://github.com/sekey/sekey

Doesn't seem to work with iTerm

Do you have "Allow sessions to survive logging out and logging back in" enabled in the advanced preferences?

You still have to provide a password. Fingerprints are not passwords. They are usernames.

huh? fingerprints are not 'usernames' (you don't just provide a 'username' for an applepay authorization for example).

and yes, adding this in you do _not_ have to type out your sudo password and can grant permissions using only touch id.

Technically you are correct and I used to complain about this myself for years. But it seems like at least for consumers they’re often content to have authentication equal authorization so I feel like mostly this battle has been lost in the consumer space.

This is correct only in the instance that a biometric is stored on the host.

In TouchID, the biometric is stored only in the secure enclave, and is used to generate a private key signature, which serves as the password.

Additionally, it's always possible to reset TouchID to an unauthenticated state, where it will refuse a fingerprint read until the password is typed in.

There's no sense cargo-culting this bit of conventional wisdom without understanding where it comes from, and what sort of attacks it is meant to prevent.

Make sure you put it at the top, added it to the end... caught me out. (It asks for both)

I thought a fingerprint is to be used like a username and not as password?

A password can be stolen by looking over someone's shoulder, a fingerprint can MAYBE be stolen with advanced technology and high-resolution photos of the person's fingers

Doesn't look very difficult to me: https://arstechnica.com/gadgets/2013/09/chaos-computer-club-...

And the fingerprints -- you leave them on your devices.

Does anyone know if similar can similar be done for Keychain access?

This won't be as easy, but I just never thought about it: what about creating a Face ID for sudo on Mac?

You'd need a sensor for it…

Obligatory reminder: Don't run your text editor as root. Instead, try sudo -e /etc/pam.d/sudo.

no, No, no, noooo, please, God. Nooooooooooo.

Biometric are non-revocable.

Yes, it's terrible. Every time I walk through passport control and the person validates my identity through a biometric check by looking at my face and looking at my passport I cringe and tell them that it's terrible and they should instead let me type a password.

for things that you own, not for government-owned biometric.

What exactly is the point of sudo/UAC these days of single-user machines? I think https://xkcd.com/1200 put it well. Anything running as an unelevated user account can access my browser sessions where it can steal my passwords, emails, other other private info. It can turn on my microphone and camera. It can read all of my documents. Those are the things I care about protecting, not whatever special things root can do like install drivers and create virtual network interfaces.

And with every macOS update you should do it again and again. Just another not useful tip.

its not like you update everyday, once a month seems like a fair trade if it’s convenient.

I disagree that it's not useful—I have a really long password and suck at typing, so being able to mash the fingerprint sensor is really helpful.

But yes, it is very frustrating that every time there's a system update you have to redo it.

Or just use Puppet to manage your macOS installation which makes things a lot easier ;)

Puppet on every minor update?

As the author says, “Since you expect to be be typing in a command line, moving your finger to touch the key is probably not very efficient.”

I was excited to set this up when the first fingerprint sensor macs came out. Within a couple of days I’d switched it off. It is quite inconvenient and especially bad if you use an external keyboard.

It still strikes me as weird that Apple went with Touch ID vs Face ID on the Mac. Computer form factors in general, and particularly notebooks and AIOs, should be perfect for Face ID: the user is always at a good distance, in the right position, looking at it, and as you say will frequently have their hands otherwise occupied actually controlling the system. For that matter a Face ID+iPhone-quality camera thing for Macs that could attach to an external monitor would be a pretty useful value-add, and it would equalize things across all Macs meaning it could be depended on more. It's remained really perplexing that year after year when Apple left Touch ID far behind on iOS they haven't installed Face ID where it'd be even better. I assume this is mainly another one of many symptoms of Apple just not being able to multitask very well and the Mac not really getting that much concerted attention.

I suspect the main reason is that the face-id camera module is too thick and they'd need to increase the thickness of the display casing. If there's on thing the Mac designers will never allow it's a thicker laptop.

Based on iFixit's iPhone 12 teardown and thus the most recent version of the module, I think they might be able to get it into the screen without much compromise. An important consideration here is that it's not just about the Face ID bit, it's about the better camera bit. While it was important even earlier, this past year has made videoconferencing and other remote work rocket up in priorities, and Macs suck pretty badly by modern standards in terms of camera quality. It's a big, by definition both very visible and very social feature (because everyone else in the conference can see how good/bad you look). I think that might be a motivation for Apple that Face ID by itself wouldn't have.

However that aside, thickness concerns don't apply a single bit to the iMac or to a standalone (Mac only) module (or even integration in Apple's ultra fancy display), so that objection doesn't cover the spectrum of Macs.

The current thickness of the MacBook lid (my 16") is <3.5mm, and the faceID module is >3.5mm. Given that you need glass and metal in that 3.5mm as well as the faceID module, you're talking about significantly changing the dimensions of the MacBooks to do this with today's faceID module.

I look forward to the day they do get it fit in there though (hoping that the Silicon redesign allows for it)!

> It's a big, by definition both very visible and very social feature

But you only see yourself as a thumbnail so the feedback is quite lossy.

I feel like it’s only a matter of time

Less likely to accidentally fool you into tapping the finger sensor vs fool you into showing your face to the camera

Not sure how "fooling" comes into play. Only trusted applications can request to use Touch ID/Face ID in the first place. It's not like there's a way for a random application to just say "Scan your face and let me take over your machine"

Exploits do happen, and to me it sounds reasonable that a web page gets local unprivileged code execution -> sudo (which is a trusted application) -> my face was already in front of the camera -> root.

I guess this could be circumvented with a "click OK if you agree to get face ID" dialog or similar. Anyway, you need to figure out a way to deal with the "key" always being in the lock if you're using face id on a laptop.

One point is that the touch prompt is “out of band”: it shows up in its own window. Some other app could open that request while you’re looking elsewhere then yiu type sudo, look up, see it (without focus), so click it and then put your finger on the sensor. When your sudo remains blocked you see the other, click I, and proceed under the assumption it was a glitch.

Sounds complicated but is actually quite plausible. And worse under face I’d as it would be more seamless. iOS is different as the user interface is largely single task (slightly less under ipad) and background tasks that need face ID need a notification and explicit selection to get it

Could say the same thing about iOS, and this is a silly UX complaint anyway. Apple could easily offer or require some purposeful interaction using mouse/keyboard along with Face ID and it'd still be a nicer UX.

> It still strikes me as weird that Apple went with Touch ID vs Face ID on the Mac

BTW the face system is so automatic on the phone that I don't think I'd want it for much beyond login. The flow-breaking reminders when installing apps and the explicit requirement of typing sudo are good ways to require deliberate intent for dependent risks. Login, App Store purchases and the like would be OK by me if controlled by face.

All that being said: the Mac camera remains astonishingly terrible (see a recent HN front pager about how bad webcams are in general). Not just low resolution but poor white balance etc. I am not sure it's been upgraded in the last decade.

There is much speculation as to why (no room in the lid, which is plausible); I feel like for some reason this is an issue on which they simply don't care for some reason as they make a lot of fuss about the changes in speaker and microphone. Perhaps it simply is good enough, based on the innumerable Zoom calls I've been on.

Face ID needs more than a better camera, it also needs an IR channel. I do expect that when they finally do get around to upgrading the camera system they will jump ahead to something like the iphone front facing system.

Using biometrics instead of a secret-based authentication is always a bad idea.

Secrets can be changed easily when they get compromissed, your figerprints/iris/whatever cannot.

https://www.csoonline.com/article/3330695/6-reasons-biometri...

How often has your mother given money to someone else who pretended to be you? Because parents identify their children through biometric authentication. They look at you and can in a matter of split seconds verify that you are actually you. Biometric authentication is the oldest and most sophisticated form of authentication. I can enter my work place and nobody asks me to type in a password at the door because the staff can immediately identify my identity by simply validating my face with their own eyes. It's incredible, trust me.

Your mother doesn't view you through a 0.3MP camera in a dimly lit room with no flash when deciding if the person in front of her is her child.

Further, if I take a high resolution photo of you, and then go to your mom and ask for money by presenting her the picture, she won't accept that picture as proof that I am you (although she may suspect I'm blackmailing or otherwise threatening you). This, moreso than qualms about the resolution/quality of the sensor is the GP's point. If the sensors are accurate, that specific set of bits that is translated as your fingerprint will not change. If someone knows those bits, it's extremely likely they can convince the sensor they are you. From our example, once I have your picture, I can tell your mother I'm you--and she'll believe me!

So your qualm is low quality biometric scanning, not biometrics itself? So we agree that biometrics are the most secure form of authentication and we are only debating on the quality of the technology, which we know is getting better day by day, yeah?

> Further, if I take a high resolution photo of you, and then go to your mom and ask for money by presenting her the picture, she won't accept that picture as proof that I am you (although she may suspect I'm blackmailing or otherwise threatening you). This, moreso than qualms about the resolution/quality of the sensor is the GP's point. If the sensors are accurate, that specific set of bits that is translated as your fingerprint will not change. If someone knows those bits, it's extremely likely they can convince the sensor they are you. From our example, once I have your picture, I can tell your mother I'm you--and she'll believe me!

You skipped the second paragraph, so I helpfully requoted it.

It rather sounds to me like you have run out of arguments.

On the other hand, you can't type your fingerprint into a random link that you receive in your email.

I think modern devices that use biometrics to unlock a secret key are different from the old-school case of biometric authentication. If someone is storing a picture of your fingerprint, then of course they can replay that to impersonate you. But that's not what TouchID is doing -- it's just a chip that will only give up the private key if it detects your fingerprint. You have to have physical access to that chip, and a finger analog that will fool the chip into giving up the secret key, and then you can use that key to compromise things. But if you detect that, you just revoke the key, get a new device, and are good to go.

I don't have a great analysis for sudo. You want root on MacOS to do something like install a long-term compromise. Your regular user account already has your GMail session cookie and bank information, so sudo isn't really good for anything else; if you leave your unlocked laptop around somewhere, your Internet life is over. But if someone physically steals your finger so they can gain access to sudo and install a keylogger or something, you already know you're compromised -- your laptop and finger are gone, so you know something's up, defeating the purpose of a long-term compromise.

This attack can't be done remotely; if someone sshs to your laptop and wants to sudo, they can't just take a picture of your fingerprint and upload it... they have to physically touch the sensor on your laptop.

Overall, I think biometrics like TouchID / FaceID / U2F / WebAuthn are strictly better than passwords. They are super convenient. They can be revoked. They can't be phished. That's a huge win over passwords.

> is always a bad idea.

Making sweeping generalizations about something as complex as information security is always a bad idea.

Reply on news.ycombinator.com