I'd already noticed that before but since I was on an admin account didn't think much of it.. I'd say that's a bug, like the App Store one
-
-
-
I've noticed a number of issues on both Windows and OSX/macOS that stem from always running as a non-admin user. I always though that "don't run as admin" was a standard infosec piece of advice, but based on what I've seen I doubt that it's a strategy that is widely used.
- 3 more replies
New conversation -
-
-
Thanks. To me, that's a little misleading. If the padlock says "Click the lock to make changes", I'd think that anything that changes the system (such as the action taken as the result of clicking the "Apply" button) would require that the padlock be open.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Is your comment about the padlock behavior based on personal experience? Or is there a reference somewhere that lists which things require it and which ignore it?
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Erm that would be a LPE for trivial root if right, you should dtrace that app and see how it calls loading the kext into memory, maybe there is a trivial exploit lurking there.
-
Just to be clear, the kernel module was attempted to be loaded *with* admin privileges (normal VirtualBox installer run as admin, in the case of the screenshots). It's just the approval part that appears to not require any privileges. Q: Should approval require admin privileges?
- 1 more reply
New conversation -
-
-
Yes, I believe so. User approval for kexts is new - I think the decision to not require admin credentials is a decision that reduces friction. It's still better than it was, and it still takes admin privs to write and load the kext in the first place.
-
You can load a kext as a normal user if it's in /System but SIP stops anyone but Apple writing things there (even as root). Outside /System, kextload needs to be invoked as root. The 'Allow' button is just extra security on top to provide user approval based on the signature.
End of conversation
New conversation -
-
-
Yes; known. This is an upgrade in security from previous behaviors. Kernel Extensions (kexts) are now specifically signed, and are now specifically enabled by the user or by policy, after (admin) install of kit: https://derflounder.wordpress.com/2017/08/24/kernel-extensions-and-macos-high-sierra/ … Code signing https://developer.apple.com/library/content/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html …
-
So… Admin install to get the kernel extension (kext) in the right spot for the load, and now with kext-specific signing, and with user approval for the kext load. For MDM-based folks, changes to thrnprovisioning path security are underway. Traceable to a kext private key.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.