Show HN: A fork of sudo with Touch ID support
github.com
github.com
The `LocalAuthentication` framework this project mentions sounds like an OS X equivalent of PAM — an OS level account auth framework. I wonder why/if the `sudo` on OS X doesn't use it.
Edit: grammar
There are some slight usability issues with using custom PAM config. E.g. if you want to unlock the lock screen without password using the Yubikey, you still need to press enter.
"While not useful in practice, you can use this to verify that the LocalAuthentication code does in fact work."
Almost seems like the author just wrote it to test the LocalAuthentication framework in the real world.
> While I am using this as a fun experiment on my personal computer, your security needs may vary.
So yes, this is a toy system. Cool concept, but not something you probably want around in production/secure environment, which I assume most people would know not to do.
Is it the most innovative concept ever? No, but it looks like it's been executed very well. I think developers will like this macbook.
Meanwhile, the other 90% of users will probably love it when their IDE, profiler, every browser's developer tools, etc. can display context-appropriate labels so they don't need to remember what F8 does in the current mode of the current application.
The touch bar is a regression.
Do you need a button like this on your keyboard? No, you could set up a new Vim bind. But this is more dynamic; what if the test re-run buttons were only visible after having modified a file, and replaced with a deploy or commit button if tests succeed?
If you're vigorously opposed to it, don't buy a Mac. But some people can definitely see use in it. It's like your function row, but with visibly context-aware functions.
I don't want a "second display"; I want dynamic, context-aware buttons. Focusing on the fact that it's "another display" misses all the benefits of it not being static hardware buttons.
The buttons on your keyboard are already context aware. All this does is make them difficult/impossible to touch type (I touch type my F-keys), forces me to look away from my display to perform operations, and removes the good tactile feedback you get from a keypress.
I agree, though, that the lack of feedback was a mistake.
>But this is more dynamic; what if the test re-run buttons were only visible after having modified a file, and replaced with a deploy or commit button if tests succeed?
More dynamic in that you have to look away from your work to trigger a re-run? Or more dynamic in that its completely worthless if you use an external display and external keyboard? Or more dynamic in that it's another avenue for show-stopping macOS bugs?
For example, in Emacs (and I'm assuming most IDEs) I can map a function key to run my tests and have a status bar entry saying how many passed or failed. It's the exact functionality in your screenshot, no touch bar required.
At best the touch bar is a nice gimmick, and it's not adding anything you can't already do, and the trade off is the function keys. They could have just as easily left the function keys alone and added the touch bar above.
The standard "function keys can do anything" response is getting old.
The "I need to pick colors and scrub video" response is getting old. Nobody does that stuff often enough for it to be a good trade off.
That "function keys can do anything" is, in my opinion, the exact reason they had to go. They're scary for the typical user. What is F7? You may know, but it's not obvious in any way. That some of them cause destructive actions (e.g. Alt+F4 on Windows) makes it worse - they're scary to many users. And even when after figuring out what some of them do, one is stuck wondering "was that F8? Or F9? Oh! It was F10" (which, includes the worry that a wrong guess could cause problems).
Though, I cannot believe they shipped it without the haptic feedback to make it clear that a button was actually clicked.
^ Also, none of that, to me, includes Esc. Esc seems clear enough in its intent, and I hold no ill-will toward the Esc key.
Haptic feedback would be interesting..
I'm surprised they didn't include it given how much they've been pushing it on iOS, as well as on the touchpad of Macs.
Then make the whole screen touch enabled and bypass the silly, tiny screen gimmick.
Also, that still requires the actual controls to be on-screen somewhere. With the touch bar, you can opt to not have those controls (e.g. a toolbar in an IDE, or a palette in a visual tool like photoshop) shown on the main display if they're available when contextually relevant, on the touch bar.
This bar is all the bad stuff about a touchscreen (limited/no tactile feedback, reduced ability to rely on muscle memory) plus the bad stuff about keyboards (primarily that they are not where your eyes are naturally). There are a few tiny niche uses cases that will be nice, like video scrubbing, but 90% of the time it's just going to be functionality that is more difficult to use than it was previously.
Don't mistake your opinion for a fact.
I'm pretty sure I hate the current situation with F-Keys at least as much as you claim to hate multi-touch interfaces.
If you truly use F-Keys by touch (i.e. without looking) forcing the touch bar into F-Key mode should get you pretty close to what you had anyway.
The F-Keys don't have the little identifying lumps (on mine these are on F & J), so you simply have to know where they are by muscle memory. The only difference is you're tapping like a track-pad tap (as opposed to trackpad click).
It's really a very well laid out keyboard design. The worst thing about laptop keyboards is that they are all so non-standard, and every manufacturer does their own special-snowflake thing, so that it is almost impossible to touch-type on an unfamiliar machine.
It is a nice gimmick. Is there anything wrong with an improvement, even if it's a little one?
It is a gimmick, but in my opinion it's not an improvement, it's counterproductive.
I'm probably not the target market I suppose, my keyboard's keycaps are blank: http://www.daskeyboard.com/daskeyboard-4-ultimate/
DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=evil.dylib my_sudo rekt
This won't work on SIP protected binaries (n.b. system binaries), but might still work on other binaries while SIP is enabled. It's mostly moot however as many developers have SIP disabled.
https://developer.apple.com/library/content/documentation/Se...
If they integrated this down to the built in sudo/su that would be even more amazing, but I imagine that's much less likely.
I was talking about "X needs your password to Y", e.g. unlocking sys preferences panels, keychain stuff, etc.
Now, you don't usually type the username when you run sudo, do you? That's because most of the time, the username can be gleaned from context. For example, "Which user is this process running under?".
So, if TouchID's purpose was just to supply identification and not any verification that the identification is legit, that would be pretty pointless.
I know that in practice apple does use it to auth.
I am probably in a minority.
That seems like the best of both worlds there.
"He used $10 of ingredients you could buy, and whipped up his gummy fingers in the equivalent of a home kitchen. And he defeated eleven different commercial fingerprint readers, with both optical and capacitive sensors, and some with "live finger detection" features."
That article's a little old now and the tech may well have improved since but I wouldn't put too much faith in fingerprint readers. (Also: other attack vectors exist).
If they'll move to the new optical sensors the the refracted IR ones can sense the flow of blood in the veins of your finger.
So I agree with zwp (not sure why he was downvoted):
I wouldn't put too much faith in fingerprint readers.
There are plenty of people still using 4 digit passcode (especially simple ones like 0000 or 1234) which is easy to 'steal' by watching somebody unlock their phone before pickpocketing them.
Now some of the above issues aren't specifically in play with this particular app: It's locally owned/controlled hardware only. Also, as you say most of us aren't international spies (though I do find that getting a bit close to 'I have nothing to hide').
There is a missing link in the trust chain though, which is attestation of that secure enclave (how do we know it is a legitimate and uncompromised one?) However, privacy preserving attestation mechanisms such as DAA [1] require somewhat expensive crypto.
[1] https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation
If you are afraid that some one will cut off your finger to unlock your computer don't use the touchID, that said if some one is willing to do that to unlock it i wouldn't want to imagine what they'll do to you to get the password.
;)
I don't buy this story or their "sources" at all. A zoomed in photo is enough to create a accurate 3d model? Really?
I might be naive at times, but this time I'm calling BS.
And I'd have to agree, fingerprints are a terrible substitute for a passphrase.
[1] http://blog.dustinkirkland.com/2013/10/fingerprints-are-user...
The bigger issue I see is that 'rrmm' is an identity I assumed. I have many different identities. I only have one set of finger prints. (Fingerprinting to unlock a local store of keys would fix some of this problem, but I am fond of plausible deniablity in identification).
If a biometric sensor can be tricked by a body part that is no longer attached to the body, that's a serious issue. But AFAIK at least modern sensors try to verify if it's still alive and then there's also the biological effect that a body part quickly changes its properties if it is no longer supported by the body.
The biggest danger in that is probably criminals who don't know that it is likely that a detached body parts stops functioning.
Something like:
osascript -e "do shell script \"$*\" with administrator privileges"
I don't think the system would have much problem with that since profile is explicitly for interactive user sessions.
Would be awesome to TouchID restart Upstart things on remotes, which is not really feasible. One can dream, though :)
Most specially, in an office environment it can be done from a mouse, a keyboard, a glass of water, etc.
There are some videos in YouTube showing how it can be done.
Also, I like how you can compliment the feature yet still insult its creator in single sentence.
"I am not a security expert."
No.
(Privilege separation is great, but running things as your main account is approximately equal to running them as root.)
>>There might os level files that only root can edit or delete
Nailed it. >>I can reinstall the os anytime if I should ever mess it up
Not everyone has the luxury or time to do this. Why break it in the first place? >>All the value is in my data.
? Cool story.If you were running your web browser as root, and a malicious website used a vulnerability to drop some malware on your system, then it would have complete power to do what it liked without needing to escalate privilege using another vulnerability.
If you want an example of something that could cause lasting damage, it's probably pretty easy to put your Apple product into a non-booting state by fiddling with NVRAM or PRAM settings as root. I'm not familiar with them off the top of my head, though.
This limits the impact of a misconfigured service, a compromised service, or just a plain malicious service... or users of such services.
Then, it doesn't necessarily have to be malicious, you can also harm your system by accident. I have done it many times.