General: Apple Platform Security support document Security Overview Cryptography: DevForums tags: Security, Apple CryptoKit Security framework documentation Apple CryptoKit framework documentation Common Crypto man pages — For the full list of pages, run: % man -k 3cc For more information about man pages, see Reading UNIX Manual Pages. On Cryptographic Key Formats DevForums post SecItem attributes for keys DevForums post CryptoCompatibility sample code Keychain: DevForums tags: Security Security > Keychain Items documentation TN3137 On Mac keychain APIs and implementations SecItem Fundamentals DevForums post SecItem Pitfalls and Best Practices DevForums post Investigating hard-to-reproduce keychain problems DevForums post Smart cards and other secure tokens: DevForums tag: CryptoTokenKit CryptoTokenKit framework documentation Mac-specific frameworks: DevForums tags: Security Foundation, Security Interface Security Foundation framework documentation Security Interface framework documentation Related: Networking Resources — This covers high-level network security, including HTTPS and TLS. Network Extension Resources — This covers low-level network security, including VPN and content filters. Code Signing Resources Notarisation Resources Trusted Execution Resources — This includes Gatekeeper. App Sandbox Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I regularly help developers with keychain problems, both here on DevForums and for my Day Job™ in DTS. Many of these problems are caused by a fundamental misunderstanding of how the keychain works. This post is my attempt to explain that. I wrote it primarily so that Future Quinn™ can direct folks here rather than explain everything from scratch (-: If you have questions or comments about any of this, put them in a new thread and apply the Security tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" SecItem: Fundamentals or How I Learned to Stop Worrying and Love the SecItem API The SecItem API seems very simple. After all, it only has four function calls, how hard can it be? In reality, things are not that easy. Various factors contribute to making this API much trickier than it might seem at first glance. This post explains the fundamental underpinnings of the keychain. For information about specific issues, see its companion post, SecItem: Pitfalls and Best Practices. Keychain Documentation Your basic starting point should be Keychain Items. If your code runs on the Mac, also read TN3137 On Mac keychain APIs and implementations. Read the doc comments in ＜Security／SecItem.h＞. In many cases those doc comments contain critical tidbits. When you read keychain documentation [1] and doc comments, keep in mind that statements specific to iOS typically apply to iPadOS, tvOS, and watchOS as well (r. 102786959). Also, they typically apply to macOS when you target the data protection keychain. Conversely, statements specific to macOS may not apply when you target the data protection keychain. [1] Except TN3137, which is very clear about this (-: Caveat Mac Developer macOS supports two different implementations: the original file-based keychain and the iOS-style data protection keychain. If you’re able to use the data protection keychain, do so. It’ll make your life easier. TN3137 On Mac keychain APIs and implementations explains this distinction in depth. The Four Freedoms^H^H^H^H^H^H^H^H Functions The SecItem API contains just four functions: SecItemAdd(_:_:) SecItemCopyMatching(_:_:) SecItemUpdate(_:_:) SecItemDelete(_:) These directly map to standard SQL database operations: SecItemAdd(_:_:) maps to INSERT. SecItemCopyMatching(_:_:) maps to SELECT. SecItemUpdate(_:_:) maps to UPDATE. SecItemDelete(_:) maps to DELETE. You can think of each keychain item class (generic password, certificate, and so on) as a separate SQL table within the database. The rows of that table are the individual keychain items for that class and the columns are the attributes of those items. Note Except for the digital identity class, kSecClassIdentity, where the values are split across the certificate and key tables. See Digital Identities Aren’t Real in SecItem: Pitfalls and Best Practices. This is not an accident. The data protection keychain is actually implemented as an SQLite database. If you’re curious about its structure, examine it on the Mac by pointing your favourite SQLite inspection tool — for example, the sqlite3 command-line tool — at the keychain database in ~／Library／Keychains／UUU／keychain-2.db, where UUU is a UUID. WARNING Do not depend on the location and structure of this file. These have changed in the past and are likely to change again in the future. If you embed knowledge of them into a shipping product, it’s likely that your product will have binary compatibility problems at some point in the future. The only reason I’m mentioning them here is because I find it helpful to poke around in the file to get a better understanding of how the API works. For information about which attributes are supported by each keychain item class — that is, what columns are in each table — see the Note box at the top of Item Attribute Keys and Values. Alternatively, look at the Attribute Key Constants doc comment in ＜Security／SecItem.h＞. Uniqueness A critical part of the keychain model is uniqueness. How does the keychain determine if item A is the same as item B? It turns out that this is class dependent. For each keychain item class there is a set of attributes that form the uniqueness constraint for items of that class. That is, if you try to add item A where all of its attributes are the same as item B, the add fails with errSecDuplicateItem. For more information, see the errSecDuplicateItem page. It has lists of attributes that make up this uniqueness constraint, one for each class. These uniqueness constraints are a major source of confusion, as discussed in the Queries and the Uniqueness Constraints section of SecItem: Pitfalls and Best Practices. Parameter Blocks Understanding The SecItem API is a classic ‘parameter block’ API. All of its inputs are dictionaries, and you have to know which properties to set in each dictionary to achieve your desired result. Likewise for when you read properties in output dictionaries. There are five different property groups: The item class property, kSecClass, determines the class of item you’re operating on: kSecClassGenericPassword, kSecClassCertificate, and so on. The item attribute properties, like kSecAttrAccessGroup, map directly to keychain item attributes. The search properties, like kSecMatchLimit, control how the system runs a query. The return type properties, like kSecReturnAttributes, determine what values the query returns. The value type properties, like kSecValueRef perform multiple duties, as explained below. There are other properties that perform a variety of specific functions. For example, kSecUseDataProtectionKeychain tells macOS to use the data protection keychain instead of the file-based keychain. These properties are hard to describe in general; for the details, see the documentation for each such property. Inputs Each of the four SecItem functions take dictionary input parameters of the same type, CFDictionary, but these dictionaries are not the same. Different dictionaries support different property groups: The first parameter of SecItemAdd(_:_:) is an add dictionary. It supports all property groups except the search properties. The first parameter of SecItemCopyMatching(_:_:) is a query and return dictionary. It supports all property groups. The first parameter of SecItemUpdate(_:_:) is a pure query dictionary. It supports all property groups except the return type properties. Likewise for the only parameter of SecItemDelete(_:). The second parameter of SecItemUpdate(_:_:) is an update dictionary. It supports the item attribute and value type property groups. Outputs Two of the SecItem functions, SecItemAdd(_:_:) and SecItemCopyMatching(_:_:), return values. These output parameters are of type CFTypeRef because the type of value you get back depends on the return type properties you supply in the input dictionary: If you supply a single return type property, except kSecReturnAttributes, you get back a value appropriate for that return type. If you supply multiple return type properties or kSecReturnAttributes, you get back a dictionary. This supports the item attribute and value type property groups. To get a non-attribute value from this dictionary, use the value type property that corresponds to its return type property. For example, if you set kSecReturnPersistentRef in the input dictionary, use kSecValuePersistentRef to get the persistent reference from the output dictionary. In the single item case, the type of value you get back depends on the return type property and the keychain item class: For kSecReturnData you get back the keychain item’s data. This makes most sense for password items, where the data holds the password. It also works for certificate items, where you get back the DER-encoded certificate. Using this for key items is kinda sketchy. If you want to export a key, called SecKeyCopyExternalRepresentation. Using this for digital identity items is nonsensical. For kSecReturnRef you get back an object reference. This only works for keychain item classes that have an object representation, namely certificates, keys, and digital identities. You get back a SecCertificate, a SecKey, or a SecIdentity, respectively. For kSecReturnPersistentRef you get back a data value that holds the persistent reference. Value Type Subtleties There are three properties in the value type property group: kSecValueData kSecValueRef kSecValuePersistentRef Their semantics vary based on the dictionary type. For kSecValueData: In an add dictionary, this is the value of the item to add. For example, when adding a generic password item (kSecClassGenericPassword), the value of this key is a Data value containing the password. This is not supported in a query dictionary. In an update dictionary, this is the new value for the item. For kSecValueRef: In add and query dictionaries, the system infers the class property and attribute properties from the supplied object. For example, if you supply a certificate object (SecCertificate, created using SecCertificateCreateWithData), the system will infer a kSecClass value of kSecClassCertificate and various attribute values, like kSecAttrSerialNumber, from that certificate object. This is not supported in an update dictionary. For kSecValuePersistentRef: For query dictionaries, this uniquely identifies the item to operate on. This is not supported in add and update dictionaries. Revision History 2023-09-12 Fixed various bugs in the revision history. Added a paragraph explaining how to determine which attributes are supported by each keychain item class. 2023-02-22 Made minor editorial changes. 2023-01-28 First posted.

HI! I am developing an application that should utilize ScriptingBridge.framework to interact with another process. Firstly, I created a separate test application for which I have added Apple Events entitlements via "Signing & Capabilities" section in Xcode and updated its Info.plist to have "Privacy - AppleEvents Sending Usage Description". While the test app works fine (I see an automation request popup and the process executes as expected) the main application where I want to integrate this functionality gets closed immediately after reaching the code interacting with Scripting Bridge. On its launch, I see the following error message from tccd in Console: Prompting policy for hardened runtime; service: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing for accessing={TCCDProcess: identifier=<app bundleID>, ..., binary_path=<path to the app's binary>} I had no such issues with the test app. Moreover, I should mention that the bundle I want to have with such functionality is stored in another bundle, both main and inner bundles aren't sandboxed, and the target app has Application is agent (UIElement) key set in Info.plist. Can you suggest any ideas as to why processes behave so differently despite having pretty much the same build configurations?

我们正在创建一个新的 macOS 应用程序，该应用程序需要访问沙盒之外的文件。它需要以静默状态停靠并使用 Electron Builder 应用程序进行打包。我已将相关权限配置为 com.apple.security.memory-exception.files.absolute path.read-only ， 它可以在 mas dev 的本地版本中正常访问。配置参数如下： com.apple.security.temporary-exception.files.absolute-path.read-only /Volumes/NO NAME/ /Volumes/NO NAME 1/ <字符串>/卷/无名称 2/</字符串> </阵列> 但在应用商店审查期间，有人说它不是法律价值。以下为声明原文： 您的应用未正确实现沙盒，或者它包含一个或多个具有无效值的权利。在重新提交新的二进制文件之前，请查看包含的权利和沙盒文档并解决此问题。 com.apple.security.temporary-exception.files.absolute-path.read-only True 如果存在 com.apple.security.memory-exception.files.absolute path.read-only 授权，应用商店会接受它吗？我需要做些什么才能访问它？

I'm using a file descriptor to write into a file. I've encountered a problem where if the underlying file is removed or recreated, the file descriptor becomes unstable. I have no reliable way to confirm if it's writing on the expected file. let url = URL(fileURLWithPath: "/path/") try FileManager.default.removeItem(at: url) FileManager.default.createFile(atPath: url.path, contents: .empty) let filePath = FilePath(url.path) var fileDescriptor = try FileDescriptor.open(filePath, .readWrite) // The file is recreated - may be done from a different process. try FileManager.default.removeItem(at: url) // L9 FileManager.default.createFile(atPath: url.path, contents: .empty) // L10 let dataToWrite = Data([1,1,1,1]) try fileDescriptor.writeAll(dataToWrite) // L13 let dataWritten = try Data(contentsOf: url) print(dataToWrite == dataWritten) // false I would expect L13 to result in an error. Given it doesn't: Is there a way to determine where fileDescriptor is writing? Is there a way to ensure that fileDescriptor is writing the content in the expected filePath?

I have the following situation: My SwiftUI App for macOS is using App Sandbox and is currently configured for read/write access for all the locations selectable in XCode I have added a file selector using a button and NSOpenPanel() to let the user select a folder containing a database file, to which I successfully get permissions using URL.bookmarkData() and URL.startAccessingSecurityScopedResource() I then try to read file paths from the database file and open those but I instantly get a permission error without a permission dialog/prompt appearing In my test I am using paths to files in my iCloud Drive folder I added all file/folder related usage string entries to the Info.plist for testing I think this is weird, since I can paste one of those file:// URLs from the database into a (non-Safari) browser and it shows the native permission dialog/prompt before downloading the file as expected. Is there any usage string that's not shown in the Info.plist Dropdown in XCode that I need to add to my app in order for this to work?

In our macOS daemon process, we are trying to validate a leaf certificate by anchoring intermediate CA cert and evaluating it using SecTrustEvaluateWithError. The leaf certificate contains couple of non-critical MS extensions (1.3.6.1.4.1.311.21.10 and 1.3.6.1.4.1.311.21.7). The macOS API fails to parse these extensions and does not evaluate the cert chain. Below is the error returned: { NSLocalizedDescription = "\U201abc\U201d certificate is not standards compliant"; NSUnderlyingError = "Error Domain=NSOSStatusErrorDomain Code=-67618 \"Certificate 0 \U201abc\U201d has errors: Unable to parse known extension;\" UserInfo={NSLocalizedDescription=Certificate 0 \U201abc\U201d has errors: Unable to parse known extension;}"; } As per RFC2459, a non-critical extension can be ignored by the system: A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension may be ignored if it is not recognized. So, why does macOS not ignore these non-critical extension and returns a failure? OS version is 14.4.1.

I have a project using SecKey. Everything was working fine. But my newest build in TestFlight has crashed iOS 17.4 above. Could you help me to fix this problem? Here is my bug.

this is an email I have sent to Apple with no luck: Dear Apple Developer Support Team, I am writing to seek urgent assistance with a persistent issue I have been encountering with Xcode. For several months now, every time I connect my iPhone to Xcode for development purposes, it automatically overwrites the user data of my apps with an old, seemingly random container. This issue is severely impacting my ability to continue development, as I cannot test new changes effectively. This occurs since a few months in every iOS and Xcode/macOS Version. I tried it with different Apps and Devices. Sometimes the entire Container (Documents) gets read only access so no new data can be created or changed by the user. I frequently used the replace container feature on Xcode so maybe this has something to do with it. This problem persists despite numerous attempts to resolve it on my end. I am at a critical point in my development timeline, and it is crucial for me to resolve this as soon as possible. Could you please advise on the next steps I should take to address this issue? If there are any logs or further information you require, I am more than willing to provide them. Thank you for your attention to this matter. I look forward to your prompt response and hope for a resolution soon. Best regards, Victor Lobe

I'm new to Networking, so forgive me if this is a silly question: In the sample code, Building a custom peer-to-peer protocol, TLS is configured as follows: // Create TLS options using a passcode to derive a pre-shared key. private static func tlsOptions(passcode: String) -> NWProtocolTLS.Options { let tlsOptions = NWProtocolTLS.Options() let authenticationKey = SymmetricKey(data: passcode.data(using: .utf8)!) var authenticationCode = HMAC<SHA256>.authenticationCode(for: "TicTacToe".data(using: .utf8)!, using: authenticationKey) let authenticationDispatchData = withUnsafeBytes(of: &authenticationCode) { (ptr: UnsafeRawBufferPointer) in DispatchData(bytes: ptr) } sec_protocol_options_add_pre_shared_key(tlsOptions.securityProtocolOptions, authenticationDispatchData as __DispatchData, stringToDispatchData("TicTacToe")! as __DispatchData) sec_protocol_options_append_tls_ciphersuite(tlsOptions.securityProtocolOptions, tls_ciphersuite_t(rawValue: TLS_PSK_WITH_AES_128_GCM_SHA256)!) return tlsOptions } The sample code touts the connection as secure ("...uses Bonjour and TLS to establish secure connections between nearby devices"), but to my untrained eye it doesn't seem so. My reasoning is as follows: If I adapt this code as-is, so connections between two instances of my app use SymmetricKeys derived from the four-digit passcode, then wouldn't my encryption be easy to break by an adversary who sends 0000...9999 and records corresponding changes in the encryption, exposing my app to all sorts of attacks? The sample uses the passcode to validate the connection (host user shows client user the passcode, which is manually entered), which is a feature I would like to keep in some form or another, which is why this is causing so many headaches. Generally speaking, is there a way to secure a local peer-to-peer connection over Network.framework that doesn't involve certificates? If certificates are the only way, are there good resources you can recommend?

Could you help me to understand this crash: Thread 22 Crashed: 0 libsystem_kernel.dylib 0x00000001e9ee2974 __pthread_kill + 8 (:-1) 1 libsystem_pthread.dylib 0x00000001fd9650ec pthread_kill + 268 (pthread.c:1717) 2 libsystem_c.dylib 0x00000001a9933c14 __abort + 136 (abort.c:159) 3 libsystem_c.dylib 0x00000001a9933b8c abort + 192 (abort.c:126) 4 libsystem_malloc.dylib 0x00000001b1b5ec68 malloc_vreport + 896 (malloc_printf.c:251) 5 libsystem_malloc.dylib 0x00000001b1b5ef10 malloc_zone_error + 104 (malloc_printf.c:319) 6 libsystem_malloc.dylib 0x00000001b1b54a44 nanov2_guard_corruption_detected + 44 (nanov2_malloc.c:2425) 7 libsystem_malloc.dylib 0x00000001b1b3b6f0 nanov2_allocate_from_block + 352 (nanov2_malloc.c:2543) 8 libsystem_malloc.dylib 0x00000001b1b3b418 nanov2_find_block_and_allocate + 1172 (nanov2_malloc.c:2797) 9 libsystem_malloc.dylib 0x00000001b1b3aeec nanov2_allocate_outlined + 252 (nanov2_malloc.c:2955) 10 CoreFoundation 0x00000001a1980ab8 _CFRuntimeCreateInstance + 448 (CFRuntime.c:791) 11 CoreFoundation 0x00000001a19e0b5c __CFDataInit + 172 (CFData.c:444) 12 Security 0x00000001aa14607c createNormalizedX501Name + 56 (SecCertificate.c:1277) 13 Security 0x00000001aa1458ec SecCertificateParse + 820 (SecCertificate.c:1658) 14 Security 0x00000001aa145594 SecCertificateCreateWithBytes + 124 (SecCertificate.c:1807) 15 libboringssl.dylib 0x00000001d2c9287c boringssl_helper_copy_certificates_from_CRYPTO_BUFFERs + 196 (boringssl_helper.m:148) 16 libboringssl.dylib 0x00000001d2c913ac boringssl_session_set_peer_verification_state_from_session + 160 (boringssl_session.m:446) 17 libboringssl.dylib 0x00000001d2ca09a4 boringssl_context_certificate_verify_callback + 528 (boringssl_context.m:1861) 18 libboringssl.dylib 0x00000001d2ca0618 bssl::ssl_verify_peer_cert(bssl::SSL_HANDSHAKE*) + 372 (handshake.cc:395) 19 libboringssl.dylib 0x00000001d2c8da68 bssl::ssl_client_handshake(bssl::SSL_HANDSHAKE*) + 3112 (handshake_client.cc:1956) 20 libboringssl.dylib 0x00000001d2c7f22c bssl::ssl_run_handshake(bssl::SSL_HANDSHAKE*, bool*) + 376 (handshake.cc:764) 21 libboringssl.dylib 0x00000001d2c8cd90 SSL_do_handshake + 80 (ssl_lib.cc:874) 22 libboringssl.dylib 0x00000001d2c8caec boringssl_session_handshake_continue + 108 (boringssl_session.m:262) 23 libboringssl.dylib 0x00000001d2c743e0 nw_protocol_boringssl_handshake_negotiate + 120 (protocol_boringssl.m:803) 24 libboringssl.dylib 0x00000001d2c715d4 nw_boringssl_read + 3144 (protocol_boringssl.m:700) 25 libboringssl.dylib 0x00000001d2c708e0 nw_protocol_boringssl_input_available + 348 (protocol_boringssl.m:1435) 26 libusrtcp.dylib 0x00000002155f6554 nw_protocol_tcp_wake_read + 396 (protocol_tcp.c:324) 27 libusrtcp.dylib 0x00000002155f504c nw_protocol_tcp_input_flush + 108 (protocol_tcp.c:2034) 28 Network 0x00000001a1ecc2b8 nw_channel_update_input_source(nw_channel*, nw_protocol*, bool) + 7872 (channel.cpp:1483) 29 Network 0x00000001a2824180 invocation function for block in nw_channel_create(nw_context*, unsigned char*, unsigned int, void*, unsigned int, bool, bool, bool*) + 72 (channel.cpp:2545) 30 libdispatch.dylib 0x00000001a987add4 _dispatch_client_callout + 20 (object.m:576) 31 libdispatch.dylib 0x00000001a987e2d8 _dispatch_continuation_pop + 600 (queue.c:321) 32 libdispatch.dylib 0x00000001a98921c8 _dispatch_source_latch_and_call + 420 (source.c:596) 33 libdispatch.dylib 0x00000001a9890d8c _dispatch_source_invoke + 832 (source.c:961) 34 libdispatch.dylib 0x00000001a9884284 _dispatch_workloop_invoke + 1756 (queue.c:4570) 35 libdispatch.dylib 0x00000001a988dcb4 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:6998) 36 libdispatch.dylib 0x00000001a988d528 _dispatch_workloop_worker_thread + 404 (queue.c:6592) 37 libsystem_pthread.dylib 0x00000001fd960f20 _pthread_wqthread + 288 (pthread.c:2665) 38 libsystem_pthread.dylib 0x00000001fd960fc0 start_wqthread + 8 (:-1)

Our product includes a sudo plugin so we can apply user-defined policies to manage privileged access to command line programs. We’ve been getting reports where the plugin sometimes doesn't get invoked and the sudo command falls back to its default behavior. This seems to only be happening intermittently, but when the issue does occur, this message appears in the Console: Library Validation failed: Rejecting '/usr/local/libexec/sudo/<our_plugin>.so' (Team ID: <OURTEAMID>, platform: no) for process 'sudo(<pid>)’ (Team ID: N/A, platform: yes), reason: mapping process is a platform binary, but mapped file is not I recall a previous discussion of this message (that I can’t locate now), which explained that although the host process has library validation disabled, the code flow raises an error anyway, so that the host process can detect it and bypass the validation to load the plugin. It looks like that's what sudo is doing: it has the private entitlement com.apple.private.security.clear-library-validation and makes the appropriate system call when the plugin initially fails to load [1] — but apparently this isn't working reliably for our sudo plugin. We’ve observed that restarting the Mac generally resolves the issue, at least for a while. This resembles the “classic symptom of a code signing oddity” where the signature is cached and the Mach-O image is rewritten rather than replaced (as documented in Updating Mac Software). But our software uses an Installer package for updates as well as initial installation, and the Installer is documented as not having this issue, so I believe the problem lies somewhere else. I’m running out of ideas; are there any other avenues I should investigate? Thanks for any help. [1] This is described in an article called "About com.apple.private.security.clear-library-validation"; I can't link to it directly from the developer forums, but it can easily be found by searching for the title.

Hi, Is this possible? I would like to: Store a biometrically secured key in the Secure Enclave. Do multiple cryptographic operations using that key in a short period of time (say 5 seconds), not all at once. Only do one FaceID for that set. For the time I've only gotten either multiple flashing FaceId requests or the operations failing. Is it possible to set a time limit in which the first FaceID authentication is accepted? Should I do something else? Thanks!

Hello, It is possible to encrypt a mac's hard-drive with Filevault. All home user folders are encrypted with the same encryption key. (This is the same encryption key for the whole hard-drive). This encryption key is encrypted with user password. But i don't understand how it works when there are multiple user accounts. Maybe there is a table: The same encryption key is stored several times (one per user account) ? Is there a way for a user to read the filevault encryption key ? Thanks

when using Xcode15, we found that using Xcode 15 to access keychain may fail. Although using Xcode earlier than 15 may have same question, but the probability is higher on Xcode15. Anyone has the same question and how to fix it?

SecItemCopyMatching crash occurs while iOS creating RSA. Test device is iPhone6s plus. How can I solve this? The crash log is as follows: 0 libobjc.A.dylib 0x0000000198964cf4 objc_msgSend + 20 (:-1) 1 Security 0x0000000189989968 SecTokenItemCreateFromAttributes + 80 (SecItem.m:996) 2 Security 0x00000001898f6db0 SecItemResultCopyPrepared + 2876 (SecItem.m:1195) 3 Security 0x00000001898ea5fc SecItemResultProcess + 376 (SecItem.m:1252) 4 Security 0x00000001898e0168 __SecItemCopyMatching_block_invoke_2 + 324 (SecItem.m:1893) 5 Security 0x00000001898e0a70 __SecItemAuthDoQuery_block_invoke + 524 (SecItem.m:1591) 6 Security 0x00000001898df2c0 SecItemAuthDoQuery + 1204 (SecItem.m:1557) 7 Security 0x00000001898e0614 __SecItemCopyMatching_block_invoke + 104 (SecItem.m:1883) 8 Security 0x00000001898e665c SecOSStatusWith + 48 (SecItem.m:331) 9 Security 0x00000001898e0374 SecItemCopyMatching + 364 (SecItem.m:1882)

Hello, I am trying to enumerate all ways on macOS for launching an application when a user opens a session. Please note i am not looking for a way which requires root or sudo privileges. I have found this: ~/Library/LaunchAgents/ Login Items (in macOS System Settings) But are there others ? Thanks

In our implementation of Platform SSO, we would like to show custom UI in both the beginDeviceRegistration call as well as the beginUserRegistration call. It works fine in the beginDeviceRegistration call when we use presentRegistrationViewController. When we try to apply the same logic in beginUserRegistration, the ViewController's view.window object is nil and thus using it to house our custom UI doesn't work. I'm not sure if this is an implementation flaw on our part or if presentRegistrationViewController is only intended to be used in beginDeviceRegistration. The call is only mentioned in the context of registering devices, which makes us wonder if it is limited to that. Any help would be appreciated!

I created a custom PAM module following this and It works fine with etc/pam.d/sudo but doesn't work with etc/pam.d/authorization and etc/pam.d/login. sudo # sudo: auth account password session auth include sudo_local auth sufficient /usr/local/Cellar/cpam/1.0.0/lib/security/cpam.so auth sufficient pam_smartcard.so auth required pam_opendirectory.so account required pam_permit.so password required pam_deny.so session required pam_permit.so authorization # authorization: auth account auth sufficient /usr/local/Cellar/cpam/1.0.0/lib/security/cpam.so auth optional pam_krb5.so use_first_pass use_kcminit no_auth_ccache auth optional pam_ntlm.so use_first_pass auth sufficient pam_smartcard.so use_first_pass account required pam_opendirectory.so Is it even allowed to add a custom PAM to \etc\pam.d\login or etc\pam.d\authorization ? Is it possible to create a mechanism with custom logic and replace it with<string>builtin:authenticate,privileged</string> in system.login.console authorization right ? Note: I have also tried moving the .so file to /usr/lib/pam but it failed even after disabling SIP.

I am trying to pass smart card PIN from a custom auth plugin with tag kAuthorizationEnvironmentPassword. I added pam_smartcard.so to login stack (\etc\pam.d\login) but the changes do not take place. # login: auth account password session auth sufficient pam_smartcard.so auth optional pam_krb5.so use_kcminit auth optional pam_ntlm.so try_first_pass auth optional pam_mount.so try_first_pass auth required pam_opendirectory.so try_first_pass account required pam_nologin.so account required pam_opendirectory.so password required pam_opendirectory.so session required pam_launchd.so session required pam_uwtmp.so session optional pam_mount.so What could possible be going wrong in this ? Also is there an API to trigger authorization_ctk from a custom auth plugin to work with smart card ?

Hello, It is possible to restrict Documents folder access with TCC. But when an applications shows a standard "file open" dialog, it is possible to access this directory to open a file. macOS allows file access in this case because it is an intentional action from user. So i suppose there is a kind of whitelist for all files path opened through "file open" dialog. I would like to know how i can access this whitelist and how i can remove entries. Thanks

Hello Geeks, After testing our iOS app using MobSF, the report highlighted that the binary has Runpath Search Path (@rpath) set. In certain cases an attacker can abuse this feature to run arbitrary executable for code execution and privilege escalation.

 The Runpath Search Path directs the dynamic linker to search for dynamic libraries (dylibs) in a specified order of paths, similar to how Unix searches for binaries in $PATH. However, this setup introduces a vulnerability wherein an attacker could place a malicious dylib in one of the initial paths, thereby hijacking the legitimate library sought by the linker.

 Despite attempting to manually strip the binary following instructions from https://inesmartins.github.io/mobsf-ipa-binary-analysis-step-by-step/index.html, the same warnings persist in the report. We urgently seek assistance in resolving this issue and eagerly await your response.