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…
Use Touch ID for Sudo on Mac
211–220 of 221 posts
Re: Use Touch ID for Sudo on Mac
#212Having 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 timeou…
Use. SSH. Keys.
Re: Use Touch ID for Sudo on Mac
#213Earlier 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…
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!)
Re: Use Touch ID for Sudo on Mac
#214Earlier quoted context omitted.
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.
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.
Re: Use Touch ID for Sudo on Mac
#215Earlier quoted context omitted.
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.
Re: Use Touch ID for Sudo on Mac
#216Having 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 timeou…
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.
Re: Use Touch ID for Sudo on Mac
#217This 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?
Did this work on iTerm?
It doesn’t (didn’t) play too well with the full screen hotkey windows.
Re: Use Touch ID for Sudo on Mac
#218The 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!
I usually just `sudo nano` it, works fine
Emacs’ tramp mode supports sudo:
emc-sudo () {
local f="$(ec ${1} | gtr '"' '\"')"
emacs -e '(find-file "/sudo::'$f'")'
}
Re: Use Touch ID for Sudo on Mac
#219Earlier quoted context omitted.
> 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.
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.
Re: Use Touch ID for Sudo on Mac
#220Earlier quoted context omitted.
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.