I am developing a macOS system service (standalone binary running as a LaunchDaemon) that requires the ability to sign data using a private key which will be deployed via MDM.
The Setup:
Deployment: A .mobileconfig pushes a PKCS12 identity to the System Keychain.
Security Requirement: For compliance and security reasons, we cannot set AllowAllAppsAccess to <true/>. The key must remain restricted.
The Goal: I need to use the private key from the identity to be able to sign the data
The Problem:
The Certificate Payload does not support a TrustedApplications or AccessControl array to pre-authorize binary paths.
As a result, when the process tries to use the private key for signing (SecKeyCreateSignature), it prompts the user to allow this operation which creates a disruption and is not desired.
What i've tried so far:
Manually adding my process to the key's ACL in keychain access obviously works and prevents any prompts but this is not an "automatable" solution.
Using security tool in a script to attempt to modify the ACL in an automated way, but that also asks user for password and is not seamless.
The Question:
Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key?
If not, is there a better way to achieve the end goal?
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Every time macOS goes to sleep the processes get suspended which is expected. But during the sleep period, all processes keep coming back and they all get a small execution window where they make some n/w requests. Regardless of what power settings i have. It also does not matter whether my app is a daemon or not
Is there any way that i can disable this so that when system is in sleep, it stays in suspended, no intermittent execution window? I have tried disabling Wake for network access setting but processes still keep getting intermittent execution window.
Is there any way that i can prevent my app from coming back while in sleep. I don't want my app to get execution window, perform some executions and then get suspended not knowing when it will get execution window again?
I have been trying to find a way to be able to sign some data with private key of an identity in login keychain without raising any prompts.
I am able to do this with system keychain (obviously with correct permissions and checks) but not with login keychain. It always ends up asking user for their login password.
Here is how the code looks, roughly,
NSDictionary *query = @{
(__bridge id)kSecClass: (__bridge id)kSecClassIdentity,
(__bridge id)kSecReturnRef: @YES,
(__bridge id)kSecMatchLimit: (__bridge id)kSecMatchLimitAll
};
CFTypeRef result = NULL;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&amp;result);
NSArray *identities = ( NSArray *)result;
SecIdentityRef identity = NULL;
for (id _ident in identities) {
// pick one as required
}
SecKeyRef privateKey = NULL;
OSStatus status = SecIdentityCopyPrivateKey(identity, &amp;privateKey);
NSData *strData = [string dataUsingEncoding:NSUTF8StringEncoding];
unsigned char hash[CC_SHA256_DIGEST_LENGTH];
CC_SHA256(strData.bytes, (CC_LONG)strData.length, hash);
NSData *digestData = [NSData dataWithBytes:hash length:CC_SHA256_DIGEST_LENGTH];
CFErrorRef cfError = NULL;
NSData *signature = (__bridge_transfer NSData *)SecKeyCreateSignature(privateKey,
kSecKeyAlgorithmRSASignatureDigestPKCS1v15SHA256,
(__bridge CFDataRef)digestData,
&amp;cfError);
Above code raises these system logs in console
default 08:44:52.781024+0000 securityd client is valid, proceeding
default 08:44:52.781172+0000 securityd code requirement check failed (-67050), client is not Apple-signed
default 08:44:52.781233+0000 securityd displaying keychain prompt for /Applications/Demo.app(81692)
If the key is in login keychain, is there any way to do SecKeyCreateSignature without raising prompts? What does client is not Apple-signed mean?
PS: Identities are pre-installed either manually or via some device management solution, the application is not installing them.