Provide identity in system network extension

Question

Hi

We are building an macOS application which integrates VPN functions right now. We are using developer ID ceritifcate to sign the app and system network extension and sandbox is enabled.

One issue we are facing now is that we need to establish mTLS connection to server. During this connection, we need to send client certificate to server via provideIdentity() API.

We have the certificate, key and p12 file which are generated in another daemon. But we can not use SecPkcs12Import function to import the p12 file in our system extension due to the sandbox limitation and the different context.

I know that we cannot construct secIdentity object by ourselves. So I am wondering if there is any way that we can get the secIdentity object in system extension?

Is it possible to send secIdentity object between app and system extension?

1.3k

Posted by

willys

Reply

Add a Comment

Answer 1

I knew I’d seen this before. I thought it might’ve been on DevForums but it turns out it was a DTS incident that Matt took.

The sandbox violation you’re seeing confirms that the sandbox has blocked accessing to the System keychain. This makes sense when you think of it as an App Sandbox. Sandboxed apps shouldn’t be able to access the System keychain. The problem comes up when you build an NE sysex, which are sandboxed but don’t have a per-user keychain that they can rely on.

My understanding is that your sysex needs long-term access to this digital identity, right? That is, you want to import it and then have persistent access to it, across restarts of your process and even restarts of the Mac.

If so, your best option is to store the digital identity in the System keychain, using a temporary exception entitlement to grant you access to it. Specifically, add this to your .entitlements file:

<key>com.apple.security.temporary-exception.files.absolute-path.read-write</key>
<array>
  <string>/Library/Keychains/</string>
</array>

IMO the fact that you have to do this is a a bug and I encourage you to file it as such. Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Rumour has it that FB10025450 was fixed in macOS 14 beta. If you have experience with that, please post a reply on this thread.

—
eskimo

Add a Comment

Answer 2

One issue we are facing now is that we need to establish mTLS connection to server.

What API are you using for your TLS connection?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Add a Comment

Answer 3

I am using createTCPConnection(to: endpoint, enableTLS: true, tlsParameters: nil, delegate: self) to create the TCP connection and there is a delegate function public func provideIdentity(for connection: NWTCPConnection, completionHandler completion: @escaping (SecIdentity, [Any]) -> Void).

So I am supposed to send the SecIdentity back to server in the completionHandler.

I have tried to disable the sandbox and SecPKCS12Import works great in the system extension. But I cannot figure it out when sandbox is enabled.

Do you have any suggestions?

Thanks in advance.

Posted by

willys

Add a Comment

Answer 4

I have tried to disable the sandbox and SecPKCS12Import works great in the system extension. But I cannot figure it out when sandbox is enabled.

I definitely remember a bug here sandboxed NE’s are being blocked from accessing the system keychain. I did a quick search and can’t find the details. Do you see a sandbox violation report?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Yes, I got this from console.log

Sandbox: com.sonicwall.So(67423) deny(1) file-write-create /Library/Keychains/System.keychain.sb-bbfba64f-tncBHd Violation: deny(1) file-write-create /Library/Keychains/System.keychain.sb-bbfba64f-tncBHd

CSSM Exception: 100001 UNIX[Operation not permitted]

Do you know if there is any workaround this known bug? Or do you have any other ideas to fix the issue?

—
willys

Add a Comment

Answer 5

I got serveral errors here:

Sandbox: com..(67423) deny(1) file-write-create /Library/Keychains/System.keychain.sb-bbfba64f-tncBHd Violation: deny(1) file-write-create /Library/Keychains/System.keychain.sb-bbfba64f-tncBHd
found a referenced key 0x7FB4639059c0 for key reference 140412741245376 [140412741245376] Error unwrapping private key CSSM Exception: 100001 UNIX[Operation not permitted]
default 16:58:40.772517+0800 com.**** create /Library/Keychains/System.keychain.sb-bbfba64f-fmHziy: Operation not permitted

default 16:58:40.772562+0800 com.**** UNIX error exception: 1 debug 16:58:40.773690+0800 com.**** 0 Security 0x00007ff82042b0b7 Security::CommonError::LogBacktrace() + 181 debug 16:58:40.773725+0800 com.**** 1 Security 0x00007ff82042b3fe Security::UnixError::UnixError(int, bool) + 314 debug 16:58:40.773741+0800 com.**** 2 Security 0x00007ff82042b454 Security::UnixError::throwMe(int) + 36 debug 16:58:40.773756+0800 com.**** 3 Security 0x00007ff8203770be Security::AtomicTempFile::create(unsigned short) + 870 debug 16:58:40.773767+0800 com.**** 4 Security 0x00007ff82037a8b9 Security::DbModifier::modifyDatabase() + 369 debug 16:58:40.773783+0800 com.**** 5 Security 0x00007ff820379273 Security::AppleDatabase::dataInsert(Security::DbContext&, unsigned int, cssm_db_record_attribute_data const*, Security::CssmData const*) + 109 debug 16:58:40.773799+0800 com.**** 6 Security 0x00007ff8202f32f7 Security::DatabaseSession::DataInsert(long, unsigned int, cssm_db_record_attribute_data const*, Security::CssmData const*, cssm_db_unique_record*&) + 117 debug 16:58:40.773813+0800 com.**** 7 Security 0x00007ff8202f27e8 cssm_DataInsert(cssm_dl_db_handle, unsigned int, cssm_db_record_attribute_data const*, cssm_data const*, cssm_db_unique_record**) + 131 debug 16:58:40.773824+0800 com.**** 8 Security 0x00007ff82036f0c3 CSSM_DL_DataInsert + 172 debug 16:58:40.773838+0800 com.**** 9 Security 0x00007ff8202d43bb SSDatabaseImpl::ssInsert(unsigned int, cssm_db_record_attribute_data const*, cssm_data const*) + 233 debug 16:58:40.773936+0800 com.**** 10 Security 0x00007ff8202d159b SSCSPDLSession::makeReferenceKey(SSCSPSession&, unsigned int, Security::CssmKey&, SSDatabase&, unsigned int, Security::CssmData const*) + 2125 debug 16:58:40.773977+0800 com.**** 11 Security 0x00007ff8202cac97 SSCSPSession::UnwrapKey(unsigned long long, Security::Context const&, Security::CssmKey const*, Security::CssmKey const&, unsigned int, unsigned int, Security::CssmData const*, cssm_resource_control_context const*, Security::CssmKey&, Security::CssmData&, unsigned long long) + 477 debug 16:58:40.774008+0800 com.**** 12 Security 0x00007ff8202cb9c7 non-virtual thunk to SSCSPSession::UnwrapKey(unsigned long long, Security::Context const&, Security::CssmKey const*, Security::CssmKey const&, unsigned int, unsigned int, Security::CssmData const*, cssm_resource_control_context const*, Security::CssmKey&, Security::CssmData&, unsigned long long) + 41 debug 16:58:40.774027+0800 com.**** 13 Security 0x00007ff8202f099b cssm_UnwrapKey(long, unsigned long long, cssm_context const*, cssm_key const*, cssm_key const*, unsigned int, unsigned int, cssm_data const*, cssm_resource_control_context const*, cssm_key*, cssm_data*, unsigned long long) + 232 debug 16:58:40.774068+0800 com.**** 14 Security 0x00007ff820373f56 CSSM_UnwrapKey + 242 debug 16:58:40.774104+0800 com.**** 15 Security 0x00007ff8203ff1a9 P12Coder::safeContentsParse(cssm_data const&, SecNssCoder&) + 3469 debug 16:58:40.774128+0800 com.**** 16 Security 0x00007ff8203b1e0a impExpPkcs12Import + 1994 debug 16:58:40.774149+0800 com.**** 17 Security 0x00007ff8203ae9d6 SecKeychainItemImport + 3216 debug 16:58:40.774171+0800 com.**** 18 Security 0x00007ff8203aef00 SecPKCS12Import + 315

Do you have any workaround or other solutions?

Posted by

willys

Add a Comment

Answer 6

I knew I’d seen this before. I thought it might’ve been on DevForums but it turns out it was a DTS incident that Matt took.

The sandbox violation you’re seeing confirms that the sandbox has blocked accessing to the System keychain. This makes sense when you think of it as an App Sandbox. Sandboxed apps shouldn’t be able to access the System keychain. The problem comes up when you build an NE sysex, which are sandboxed but don’t have a per-user keychain that they can rely on.

My understanding is that your sysex needs long-term access to this digital identity, right? That is, you want to import it and then have persistent access to it, across restarts of your process and even restarts of the Mac.

If so, your best option is to store the digital identity in the System keychain, using a temporary exception entitlement to grant you access to it. Specifically, add this to your .entitlements file:

<key>com.apple.security.temporary-exception.files.absolute-path.read-write</key>
<array>
  <string>/Library/Keychains/</string>
</array>

IMO the fact that you have to do this is a a bug and I encourage you to file it as such. Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by

eskimo

Rumour has it that FB10025450 was fixed in macOS 14 beta. If you have experience with that, please post a reply on this thread.

—
eskimo

Add a Comment

Answer 7

Hi @eskimo,

Thanks for your advice and I will have a try with your suggestion.

I have filed a bug and the information is described as below:

FB10025450 (Keychain is not accessiable from system network extension via SecPKCS12Import function)

Posted by

willys

Thanks for the bug report!

—
eskimo

Add a Comment

Answer 8

Hi @eskimo,

After I add the entitlement, everything works great.

Thanks very much for your help.

Posted by

willys

Yay!

—
eskimo

Add a Comment

Provide identity in system network extension

Accepted Reply

Replies