List of system privileges

I found an error in console

Can you post the full log entry?

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

Here it is:
error 12:27:00.717255+0200 Sandbox: my.app.bundle.id(31524) System Policy: deny(1) system-privilege 10006 kernel

Looks like it pops-up every time a NetworkExtension tries to write to log file.

Where are you seeing this? Is it new in macOS 11?

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

Catalina 10.15.7 (19H114)
Xcode Version 12.4 (12D4e)

Sandboxed app with sandboxed NetworkExtension (Packet tunnel). App can write logs to file inside its container without problems. When Extension tries to write to file, system-privilege 10006 appears in logs.

PS. Is there any possibility to stop Console app from removing older logs? Messages appear so fast that it is difficult to find anything useful before they disappear. And creating sysdiagnose reports everytime, takes too much time.

Is there any possibility to stop Console app from removing older logs?

I don’t think so. However…

And creating sysdiagnose reports everytime, takes too much time.

Quite. Unless I need the full sysdiagnose log I usually just run log collect. It’s pretty fast.

Alternatively, if there are specific things you want to watch for, you can run log stream with a predicate to look for those specific things.

Finally, macOS has a fully functional OSLog framework that you can use to build custom logging tools.

---

Compare this:

While debugging I found an error in console, that states that app was
denied system-priviledge 1006.

to this:

When Extension tries to write to file, system-privilege 10006 appears
in logs.

There’s a different number of zeroes here. Annoyingly, both 1006 and 10006 are valid values. Per xnu/bsd/sys/priv.h in the Darwin open source:

• 1006 is PRIV_PROC_TRACE_INSPECT

• 10006 is PRIV_NET_PRIVILEGED_NECP_MATCH

Neither look super relevant to the file system. What API are you using to write to your file? And what error does it return?

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

Ohh, I'm so sorry! I missed one zero :(
It is #define PRIV_NET_PRIVILEGED_NECP_MATCH 10006 /* Privilege verified by Network Extension policies */. And the problem is in Network Extension indeed.
Maybe it is not because of writing to file, that was just my hypothesis. Any ideas on what can be the cause?

And thanks a lot for log commands, that's actually enough for me, and works much faster!

Maybe it is not because of writing to file, that was just my
hypothesis. Any ideas on what can be the cause?

In this context NECP is the kernel’s network interface access control subsystem. Beyond that, I don’t have a lot of insight. Is there an actual problem here? If so, what are its symptoms?

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

Yes, there are few actually. One of them is that sandboxed system extensions (network extension) can't write log to file. Another is that the same extension can't read from keychain. But I'm not sure it is related to this error, as it (10006 error) actually went away lately.

One of them is that sandboxed system extensions (network extension)
can't write log to file. Another is that the same extension can't read
from keychain.

Neither of these are likely to be related to the 10006 privilege.

---

With regards your log file issue, what error do you get back from the API that fails? An error of EPERM (1) likely means that the write was blocked by the sandbox and thus you’d expect to find another sandbox violation report about it. If the error is something else, it’s likely that you have a general file system problem.

---

With regards the keychain, that issue is complex. Some questions:

• Are you building your NE provider as an appex or a sysex?

• Are you using the iOS-style database keychain? Or the traditional macOS file-based keychain?

• What operation is failing? And with what error code.

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

It's a System Extension using NEPacketTunnelProvider (sandboxed, with incoming and outgoing connections enabled).

Not sure about the style of keychain usage. Here is the code:

Code Block swift
var query = [String: Any]()
setScope(query: &query, context: context)
query[kSecClass as String] = kSecClassGenericPassword
query[kSecAttrAccount as String] = username
query[kSecAttrAccessible as String] = kSecAttrAccessibleAfterFirstUnlock
query[kSecValueData as String] = password.data(using: .utf8)
let status = SecItemAdd(query as CFDictionary, nil)

Status returns 100001.

Logs contain:

Code Block 
create /Library/Keychains/System.keychain.sb-ec3c9eec-Efos0S: Operation not permitted
Sandbox: my.app.bundle(19770) deny(1) file-write-create /Library/Keychains/System.keychain.sb-ec3c9eec-Efos0S
UNIX error exception: 1
CSSM Exception: 100001 UNIX[Operation not permitted]
CSSM Exception: 100001 UNIX[Operation not permitted]

What is interesting is that it is possible to open the keychain (SecKeychainOpen returns 0), but when trying to write to it, it fails with the same 100001 code.

Code Block swift
            let path = "~/Library/Keychains/login.keychain-db"
            var keychain: SecKeychain?
            var status = SecKeychainOpen(path, &keychain)
            log.warning("SecKeychainOpen \(status)")
            let addErr = SecItemAdd([
                    kSecClass: kSecClassGenericPassword,
                    kSecAttrService: "aTestTestTest",
                    kSecAttrAccount: "mrgumby",
                    kSecUseKeychain: keychain,
                    kSecValueData: "opendoor".data(using: .utf8)!
                    ] as NSDictionary, nil)
            if addErr != errSecSuccess {
                log.warning("Keychain SecItemAdd failed, error: \(addErr)")
            } else {
                log.warning("Keychain success")
            }

result:

Code Block 
SecKeychainOpen 0
Keychain SecItemAdd failed, error: 100001

Adding

Code Block 
<key>com.apple.security.temporary-exception.files.home-relative-path.read-write</key>
	<array>
		<string>/Library/Keychains/login.keychain-db</string>
	</array>

To extension entitlements doesn't help.

Status returns 100001.

This is effectively EPERM. See QA1499 Security Framework Error Codes.

What is interesting is that it is possible to open the keychain
(SecKeychainOpen returns 0)

You are, alas, wildly off in the weeds here )-: Two things:

• ~/Library/Keychains is not equivalent to /Library/Keychains, even when you’re running as root. Remember that the root home directory is /var/root.

• Most APIs that work in terms of paths, like SecKeychainOpen, do not expand ~. That’s the function of the shell — this is obvious when you think about it, otherwise these APIs wouldn’t be able to access a file called ~, which would be a super weird restriction. Anyway, so by passing ~/Library/Keychains/login.keychain-db to SecKeychainOpen means you end up accessing a file called ***/~/Library/Keychains/login.keychain-db, where *** is the current working directory, which is not the droid you’re looking for.

Not sure about the style of keychain usage. Here is the code:

Your code suggests that you’re confused (-: As it stands it’ll use the file-based keychain. However, you’ve specified a property, kSecAttrAccessible, that only makes sense available with the iOS-style keychain.

Honestly, I think your life would be easier if you switched to the iOS-style keychain. This means adding kSecUseDataProtectionKeychain to all your parameter dictionaries.

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

Thanks for explanation!

Regarding styles: The first code snippet is the one I was trying to use first. It indeed comes from iOS NetworkExtension which works perfectly.
The second code snippet I took from this forum and added it directly to NetworkExtensions handleAppMessage just for tests. Then added selection of keychain with a hope that temporary-exception entitlement would help.

After adding kSecUseDataProtectionKeychain: true both return the same error code: -25291 (errSecNotAvailable?).

Whatever I try, I can't find a way to write to keychain. So the question is: is it really possible to write to any keychain from a sandboxed System Network Extension?

is it really possible to write to any keychain from a sandboxed System
Network Extension?

I can’t see any obstacle to doing this with the iOS-style keychain. Unfortunately I don’t have time to dig into this further here on DevForums. I recommend that you open a DTS tech support incident so that I, or Matt, can allocate the time to help you properly.

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