Post

Replies

Boosts

Views

Activity

Reply to I'm trying to use a keychain-access-group and failing
In the current implementation, the GUI app will be the process that creates the secure items. The command line tool will be the process that largely consumes that secure item, but the GUI app needs access to it as well. High level overview. The combination of the two processes is to automate macOS software updates to an MDM management system. (Intune) The GUI app is all about configuring which apps should be monitored and automatically updated for deployment in the management system. It really is just to setup all the metadata required for the automation. The command line tool is what will then run as some scheduled interval to read the setting created by the GUI app and do the task of updating the software deployments. This is all more or less working now when I run the two tools under my user context. I honestly have not gotten to the part where I create the launch daemon and run it in that context. The two items are not really ever interacting directly. The GUI app can currently create a self signed key pair (openssl framework) for use to for authentication to an Entra ID Enterprise application, or consume a secret key (password) that Entra ID app generates. (Microsoft Graph API) That is all working now. Except, I am not currently storing any of that in a secure way. The cert or secret key are currently just store in the file system unsecured. Hence my desire to move this into something secure like the keychain. Maybe I just need to use separate credential for both items? The GUI app creates the secure items for the command line tool to read from the system keychain? (Can a daemon pull from the system keychain?) Then the GUI app uses credentials of the user at launch time to communicate with Entra and Intune? Would something like that work? Does that answer your open questions? Any ideas or direction you could provide will be appreciated. Thanks!
Topic: Privacy & Security SubTopic: General Tags:
Mar ’25
Reply to I'm trying to use a keychain-access-group and failing
I think I'd prefer it to be able to run on a schedule no matter if a user was logged in or not. So it would be a daemon not an agent. What if I change the architecture and turn the daemon into a privileged helper tool and it became the only item that needed the credentials? Can it operate as both a helper tool and a daemon running on a schedule? Then the GUI app puts in requests for things that require the Entra or Intune information via the Graph API to the helper and it passes the data back to the GUI app. Would that simplify the equation?
Topic: Privacy & Security SubTopic: General Tags:
Mar ’25
Reply to I'm trying to use a keychain-access-group and failing
It took me a little bit to wrap my head around the XPC code, but I have the basis of it working now. I started a new project from the ground up. Will re-use a lot of the code from the previous iteration once I get the basic requirements in place. I gave up trying to generate a self signed certificate and RSA private key with the command line. I left that in the GUI, since it was easy to integrate the RSA Framework there. The command line tool can import the generated p12 handed off by the GUI app into the system keychain or a p12 generated somewhere else. Alternately it can also import a secret key handed off from the GUI app to use for the Entra ID authentication. The Entra ID token is retrieved and cached in the daemon for re-use while it is still running. The daemon plist I used this key: <key>EnablePressuredExit</key> <true/> Which seems to work well. I have a heartbeat pinging the daemon every 60 seconds while the GUI app is running to keep the daemon running. Maybe I don't need to do that? Is there a better way? There will be a second plist to launch the daemon on a schedule to do the sync tasks, once I get there in the coding. 😁 That's where I'm at now on this. It's working well so far. Thanks so much for the hand holding at pointers to get me going. Really appreciate it!
Topic: Privacy & Security SubTopic: General Tags:
Mar ’25