I'm extending a C++ library to gather some data from the keychain, I have a prototype code written in Swift that works just fine: import Security; import Foundation; let query: [String: Any] = [ kSecClass as String: kSecClassCertificate, kSecReturnData as String: true, kSecMatchLimit as String: kSecMatchLimitAll ] var items: CFTypeRef?; let status = SecItemCopyMatching(query as CFDictionary, &items); However trying to do the same in C++ crashes: #include <security/SecItem.h> int main() { static const void* keys[] = { kSecClass, kSecMatchLimit, kSecReturnData, }; static const void* values[] = { kSecClassCertificate, kSecMatchLimitOne, kCFBooleanTrue, }; static_assert(sizeof(keys) == sizeof(values), "Key-value lengths mismatch for query dictionary constructor!"); CFDictionaryRef query = CFDictionaryCreate(kCFAllocatorDefault, keys, values, sizeof(keys), nullptr, nullptr); SecItemCopyMatching(query, nullptr); return 0; } With the backtrace of: Thread 1 Queue : com.apple.main-thread (serial) #0 0x0000000191a7f1b8 in objc_retain () #1 0x0000000191ed9e0c in -[__NSDictionaryM __setObject:forKey:] () #2 0x0000000191f3ae28 in __CFDictionaryApplyFunction_block_invoke () #3 0x0000000191effbb0 in CFBasicHashApply () #4 0x0000000191ef2ccc in CFDictionaryApplyFunction () #5 0x0000000194cdafc4 in SecCFDictionaryCOWGetMutable () #6 0x0000000194cdf3e8 in SecItemCopyMatching_ios () #7 0x0000000194e79754 in SecItemCopyMatching () #8 0x0000000100003f68 in main at /Users/kkurek/whatever/whatever/main.cpp:15 #9 0x0000000191acf154 in start () I don't have much experience with MacOS so I'm not sure how to analyze this situation. I have tried running with sanitizers enabled but somehow the crash doesn't occur at all when running with them.

When I tried to launch my application from non-gui process (from launch daemon) NSworkspace openApplicationAtURL failed if I tried to run it when my device on the login screen. Everything is working if someone logged in, but on the login screen I have the error The application “TestApp” could not be launched because a miscellaneous error occurred. with code 256 NSWorkspace* workspace = [NSWorkspace sharedWorkspace]; NSWorkspaceOpenConfiguration* config = [NSWorkspaceOpenConfiguration configuration]; config.createsNewApplicationInstance = YES; config.activates = NO; config.promptsUserIfNeeded = NO; config.addsToRecentItems = NO; [workspace openApplicationAtURL: appURL configuration: config completionHandler:^(NSRunningApplication *app, NSError *error) { }]; Sometimes after the third try it works, sometimes not at all. I try to use "open" command, it works on MacOS Sequoia, but not working for operating systems below, I see this error The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600002998120 {Error Domain=OSLaunchdErrorDomain Code=125 "Domain does not support specified action" UserInfo={NSLocalizedFailureReason=Domain does not support specified action}}} All these problems occur only on the login screen. I'm developing screen share utility, so I need somehow to launch my application on the login screen. Could someone please help me understand what is recommended way to launch application on the login screen?

Since the introduction of the siblings / and /System/Volumes/Data architecture, some very basic, critical commands seems to have a broken behaviour ( cp, rsync, tar, cpio…). As an example, ditto which was introduced more than 10 years ago to integrate correctly all the peculiarity of HFS Apple filesystem as compared to the UFS Unix filesystem is not behaving correctly. For example, from man ditto: --rsrc Preserve resource forks and HFS meta-data. ditto will store this data in Carbon-compatible ._ AppleDouble files on filesystems that do not natively support resource forks. As of Mac OS X 10.4, --rsrc is default behavior. [...] --extattr Preserve extended attributes (requires --rsrc). As of Mac OS X 10.5, --extattr is the default. and nonetheless: # ls -@delO /private/var/db/ConfigurationProfiles/Store drwx------@ 5 root wheel datavault 160 Jan 20 2024 /private/var/db/ConfigurationProfiles/Store                            ********* com.apple.rootless 28 *************************** # mkdir tmp # ditto /private/var/db/ConfigurationProfiles tmp ditto: /Users/alice/Security/Admin/Apple/APFS/tmp/Settings: Operation not permitted ditto: /Users/alice/Security/Admin/Apple/APFS/tmp/Store: Operation not permitted # ls -@delO tmp/Store drwx------ 5 root wheel - 160 Aug 8 13:55 tmp/Store                            * # The extended attribute on copied directory Store is empty, the file flags are missing, not preserved as documented and as usual behaviour of ditto was since a long time ( macOS 10.5 ). cp, rsync, tar, cpio exhibit the same misbehaviour. But I was using ditto to be sure to avoid any incompatibility with the Apple FS propriaitary modifications. As a consequence, all backup scripts and applications are failing more or less silently, and provide corrupted copies of files or directories. ( I was here investigating why one of my security backup shell script was making corrupted backups, and only on macOS ). How to recover the standard behaviour --extattr working on modern macOS?

I am trying to develop a custom plugin. Below is my auth plugin plist. However, the mechanism marked as privileged is not being triggered by macOS. If I remove the privilege, it gets called. Any pointers on this? TestPlugin:MyLogin and TestPlugin:MyUser,privileged are my custom plugins. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>evaluate-mechanisms</string> <key>comment</key> <string>Login mechanism based rule. Not for general use, yet.</string> <key>created</key> <real>728811899.153513</real> <key>mechanisms</key> <array> <string>builtin:prelogin</string> <string>TestPlugin:MyLogin</string> <string>TestPlugin:MyUser,privileged</string> <string>builtin:login-begin</string> <string>builtin:reset-password,privileged</string> <string>loginwindow:FDESupport,privileged</string> <string>builtin:forward-login,privileged</string> <string>builtin:auto-login,privileged</string> <string>builtin:authenticate,privileged</string> <string>PKINITMechanism:auth,privileged</string> <string>builtin:login-success</string> <string>loginwindow:success</string> <string>HomeDirMechanism:login,privileged</string> <string>HomeDirMechanism:status</string> <string>MCXMechanism:login</string> <string>CryptoTokenKit:login</string> <string>PSSOAuthPlugin:login-auth</string> <string>loginwindow:done</string> </array> <key>modified</key> <real>740052960.218761</real> <key>shared</key> <true/> <key>tries</key> <integer>10000</integer> <key>version</key> <integer>10</integer> </dict> </plist>

We've got a non-sandboxed app with a built-in daemon that does some root-privileged things for us on occasion. We're using the newest SMAppService APIs, using NSXPCConnections for communications, and generally things work as expected. The daemon is set up to terminate when the parent app terminates. Our app also has (and uses the daemon for) a self-update feature. Once the new app is downloaded, the daemon takes over, replaces the app in-place, terminates the old app and launches the new one. However, after this update, the daemon no longer works. Any other build & launch of the app will silently fail when trying to talk to the daemon. The XPC connection can be constructed as usual, no errors, the process goes along like it should app-side, but the daemon never actually launches and never responds. I can imagine there could be a few rules being broken here with the self-update and the built-in daemon, but what would they be and how can we work within the rules?

I am working with a compiler that produces native binaries, It's really meant for servers so it's not integrated with Xcode or the Xcode build system. As such the output binaries get the default ad-hoc signatures the linker makes. After (re)compiling such a binary, there is a delay whilst running it. This is because macOS notices it's an unknown binary and goes off to ask notarization servers/Xprotect if it's known malware. Fine, I understand the need for this and why it happens. From the logs it's clear that macOS is now tracking the "provenance" of binaries. This means where they came from. This raises the question of whether it could know that my local dev binaries are coming from this compiler, if it was in turn properly signed and notarized. And if so, whether there is some security policy I could set to say "if binary X produces binary Y, then trust Y". Yes I know this would be a security exploit if it were done that way by default, but I am willing to take the risk of special malware that compiles itself first using this special compiler that isn't installed by default then runs the output, as presumably any such malware would be so targeted Xprotect/notarization wouldn't know about it anyway. The provenance mechanism is some internal security thing and isn't documented, but I'm curious if anyone knows more about it and whether it's usable for this? Or alternatively if there's a way to stop macOS doing these slow checks for certain binaries e.g. under specific paths?

I know how to set up a parental gate to keep a child user away from a web portal for parents or guardians. But is it even OK with Apple (or just in general) to open a browser from inside a kids app? I can think of two ways to do this: Launch a browser with UIApplication.shared.open(). This takes the user (presumably an adult) out of the app. Will Apple object to this? Use an in-app browser with WKWebView. (Wrapped in UIViewRepresentable because I'm using SwiftUI.) Option 2 has some problems with Google SSO, which is a requirement for me. Some details in stackoverflow 2016 and stackoverflow 2019 and gitHub. I can't figure out how to apply the solutions in those posts to the SwiftUI architecture or even the UIViewRepresentable.

my macOS process is crashing when i keep my mac sleep for about 1 hour. Under Crash Reports, Console app shows two type of file. .diag type .ips type ips file doesn't shows exact line of crash as you can see below sample. Thread 67 Crashed: 0 libsystem_kernel.dylib 0x19a4aea60 __pthread_kill + 8 1 libsystem_pthread.dylib 0x19a4e6c20 pthread_kill + 288 2 libsystem_c.dylib 0x19a3f3a30 abort + 180 3 libsystem_malloc.dylib 0x19a303dc4 malloc_vreport + 896 4 libsystem_malloc.dylib 0x19a307430 malloc_report + 64 5 libsystem_malloc.dylib 0x19a321494 find_zone_and_free + 528 6 Firewall.so 0x103c8a744 TunnelSendQueue::ResumeSend() + 460 resource.diag file sgowing warning about exceeding limit of 150 wakeups per second over 300 seconds. attached here. reasource_consumptions_W36RNW09G.wakeups_resource_diag.txt is this something macOS stopping app because of some resource consumptions?

Hello, Regarding authorization plugins, I am trying to display a user interface in the fast user switching (fus) scenario. I have implemented the SFAuthorizationPluginView class that theoretically would help me show a user interface in this context. doing tests, I see that my plugin window is displayed behind the fus background screen. This window in screen lock scenario is displayed correctly. Is there any limitation in fus that prevents displaying a UI above the background screen where the user enters the password? I show how I have system.login.fus configured(My plugin is MyTestPlugin): ... mechanisms <string>builtin:smartcard-sniffer,privileged</string> <string>loginwindow:login</string> <string>builtin:reset-password,privileged</string> <string>builtin:auto-login,privileged</string> <string>builtin:authenticate-nocred,privileged</string> <string>MyTestPlugin:invoke</string> <string>loginwindow:success</string> <string>loginwindow:done</string> I have tried placing my puglin in a different order compared to other mechanisms and it did not get the window to display above the background screen. Another option I've tried is to place my plugin on top of loginwindow:login. In this case, my plugin interface is displayed correctly but I do not have username information. Is there a way to obtain this information? All the best.

I am working on a Swift app which does a TLS connection to a server. I want to set an identity, which the server will validate. I'm given a pkcs12 file. The cert is not trusted locally on my system, but the server can validate it. First, I didn't need to import the cert - I just want to create an identity that I can use with my connection. I don't think that's possible, so I do this: var importStatus = SecPKCS12Import(pkcs12Data as CFData, importOptions as CFDictionary, &importArray) The first time I call this, it's successful. I have come to extract the identity (and certificate) from the importArray returned, but in my case, even though I get an errSecSuccess return status, the importArray is empty. So first question: why would it be empty? ( if the code is run again, I get an errSecDuplicateItem - I don't need to store it in the keychain but I guess I'm being forced to) When I imported, I used a UUID as my identifier - I set it in the options: let importOptions: [String: Any] = [ kSecImportExportPassphrase as String: password, kSecImportItemLabel as String: identifier ] So I try to retrieve the identity from the keychain: let identityQuery = [ kSecClass: kSecClassIdentity, kSecReturnRef: true, kSecAttrLabel: identifier ] as NSDictionary var identityItem: CFTypeRef? let status = SecItemCopyMatching(identityQuery as CFDictionary, &identityItem) where I pass the UUID as identifier, but I actually get back my apple identity, not the certificate. However, if I pass in the certificate's CN, (hard-coded for my testing) I get the right identity back. So my second question: am I doing something wrong? If i pass an ItemLabel on import, can I retrieve the certificate using that same label? So for me to get this working, I need to know the CN of my cert, or I need the ItemLabel to work so that I can just retrieve using a UUID. To determine the CN of my cert, the only apple API I found is this: SecCertificateCopyCommonName which requires the cert to be in .der format, rather than .pkcs12. So I have a bit of a chicken and egg problem. So my last question - is there a way to extract the CN from the pkcs12 file, or to convert the Data from .pkcs12 to .der? Thanks!