Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use Touch ID for Sudo on Mac

davidwalsh.name

Post reply on HN
Print view View original

201–210 of 221 posts

Re: Use Touch ID for Sudo on Mac

#201

Post by PureParadigm »

azon wrote: post #197
PureParadigm wrote: post #187

Earlier quoted context omitted.

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

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.

Re: Use Touch ID for Sudo on Mac

#202

Post by girishso »

bitlevel wrote: post #8

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!

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

Re: Use Touch ID for Sudo on Mac

#203

Post by girishso »

girishso wrote: post #202
bitlevel wrote: post #8

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!

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.

Re: Use Touch ID for Sudo on Mac

#204

Post by loeg »

derefr wrote: post #106
jeffbee wrote: post #98

Earlier quoted context omitted.

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!

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 sa…

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.)

Re: Use Touch ID for Sudo on Mac

#205

Post by loeg »

curt15 wrote: post #124
derefr wrote: post #106

Earlier quoted context omitted.

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 sa…

>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 b…

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

Re: Use Touch ID for Sudo on Mac

#206

Post by fragmede »

chipotle_coyote wrote: post #188
jeffbee wrote: post #122

Earlier quoted context omitted.

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.

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 t…

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.

Re: Use Touch ID for Sudo on Mac

#207

Post by bboreham »

derefr wrote: post #182
unilynx wrote: post #174

Earlier quoted context omitted.

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 o…

> 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…

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.

Re: Use Touch ID for Sudo on Mac

#208

Post by okl »

TheRealSteel wrote: post #198
okl wrote: post #169

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.

Re: Use Touch ID for Sudo on Mac

#209

Post by saagarjha »

samstave wrote: post #135
Demigod33 wrote: post #115

Earlier quoted context omitted.

What if one file was written by a malicious program?

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 an…

This is somewhat how user defaults work already.
Post reply on HN