@eskimo, what is your opinion regarding code validation technique suggested in https://speakerdeck.com/vashchenko/job-s-bless-us-privileged-operations-on-macos?slide=54 (from Objective by the Sea v3.0)

In 2017 you said that verifying using PID is fine, but there were a number of CVEs reported since then.Do you still hold by:> Fortunately, process ID wrapping problems aren’t a real threat in this context because, if you create an XPC connection per process, you can do your checking based on the process ID of that process. If the process dies, the connection goes away and you’ll end up rechecking the process ID on the new connection.

> the XPC team pointed out that there is a possible vulnerability with the first message for a given connectionDo you suggest that OS verifies validity of an xpc connection of each message only after the preceding message got processed by the user?If that's the case, it appears that while only the second and further messages should be allowed to perform security-sensitive tasks, all messages need to be verified. Otherwise the attack seems to be possible assuming that malicious process is warped after Nth message connection is vetted by the OS but before it's verified by the user.

When you wrote:> the XPC team pointed out that there is a possible vulnerability with the first message for a given connection.did you mean an attack that happens due to a time window between the OS vertting an XPC message and user's code seeing it? I.e. when by the time user's code attempts to verify its XPC peer by PID, it is some other process, not the one that originally sent the message.If my understanding is correct, then it's an important implementation detail. Otherwise how else can you prevent user's code in the XPC service from receiving multiple messages from the malicious process?

Could you elaborate what is implied by> has been processedIs it processed by the time user's callback is entered or exited?> Once the first message has been processed, the connection is established such that my “if the process terminates, the connection goes with it” logic kicks in.Isn't it possible for an originating process to die and wrap while XPC service is still within user's callback for the 2nd message?

While the OS ensures that the second message can only be sent by the same process that sent the first message, it alone is not enough for user's code in the XPC service.Thus it seems important for user's code in the XPC service to:1. When handling the first message capture process's identity (in terms of requirements, version, code signature etc) and avoid performing any priviliged actions. In other words let the first message be a handshake.2. When handling all consequent messages use the identity captured in [1] for permissions check before performing any priviliged actionsAt least it appears to be enough if permissions checks are run against code signature and backed-in data (such as requirements) which is also reflected by the signature.Is my understanding more-or-less in line with what you have suggested above?

Answering my own question: `out` tells the compiler that current value of the retainable object pointer is of no importance to the receiver which allows to elide some retain / release calls. The usecase documented above is actually the only usecase in Apple Clang 11.0.0

I'm hitting, possibly, a related bug with Xcode 11.3.1: in my case swift libraries are not included. After checking the build log I found that CopySwiftLibs is executed with a bunch of --scan-executable and --scan-dir arguments. But this arguments miss the necessary path, in particular path to XPC services.I checked release notes for newer versions of Xcode but have not found that issue being listed. Is there a known workaround?

As a workaround I explicitly set ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES to NO in the main app and added the following Run Script phase:/usr/bin/xcrun swift-stdlib-tool \--copy \--verbose \--sign ${EXPANDED_CODE_SIGN_IDENTITY} \--scan-folder ${TARGET_BUILD_DIR}/${CONTENTS_FOLDER_PATH} \--platform macosx \--toolchain ${DT_TOOLCHAIN_DIR} \--destination ${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH} \--strip-bitcode \--strip-bitcode-tool ${DT_TOOLCHAIN_DIR}/usr/bin/bitcode_stripwith a single output file:${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}/libswiftCore.dylib

Quinn,My apologies by I seem to miss something obvious here. In this reply you suggested two paths:1. Use a private API to acquire the audit token of an XPC connection2. Use PID but rely on that 2nd and forth messages are guaranteed to come from the same connectionWhile [1] is quite clear I'm completly puzzled by [2].Which of the following do you suggest:1. Run peer validation pased on code object created from a PID associated with the connection upon receiving the first message, then, if successful, mark that connection authenticated and perform priviliged work starting with the 2nd message2. Same as [1] but re-validate the peer for each message3. Something else---The scenario I have in mind is:1. Malicious process starts, sends 2 messages2. The system does whaterver it does, processes the messages and enques them for delivery to user's code3. Malicious process through other means (e.g. timing?) figures out that its messages were enqued for delivery and initiates wrapping4. Legitimate process takes its places5. Enqueued messages finally reach user's code. User acquires PID, gets code object of the Legitimate process and responds to the messages. Since both message are already enqueued user has no chance (aside from using private API to get auditToken) to recognize malicious intent.To avoid the attack, as I understand, the OS must not bulk process messages. Instead it should process them one by one, only picking the next message after user's code is done with the previous one.In the scenario above it would force the peer to be around up until the moment the 2nd message was passed to user's code. Thus preventing the wrap.Please guide me!

@kaunteya that is not correct. Internally it may be either a NSLayoutGuide or an NSView. The Any? "hack" is necessary since there is no protocol to express *anchor properties. But in practice it will be an NSLayoutGuide most of the time unless you customize window's content view or play with its view hierarchy.

The SO_NET_SERVICE_TYPE option and its siblings StreamNetworkServiceType, NSStreamNetworkServiceType, kCFStreamNetworkServiceType configure Layer 1/2 QoS priority. In case of Wi-Fi they set 802.11 User Priority (UP). Whether it actually gets set in the actually transmitted frame depends on whether the OS trusts your application. AFAIK for iOS/iPadOS this feature has to be enabled via MDM for a generic app. Apps made by Apple and some other vendors, like Cisco, are trusted without this permissions. What happens next depends on your network equipment (routers, switches, APs etc) and its configuration. Some may translate received 802.11 UP into DSCP according to some mapping (either via RFC8325 or by whatever policy conceived by network admins). Additionally, you can set Layer 3 QoS via the DSCP (RFC 2474) field of an IP frame either by setting IP_TOS directly or setting the IP_HDRINCL socket option and supplying custom IP header. Don't get confused by option's name (TOS): it's exactly the same bits of the IP header. Treat it as DSCP. See the '-K' and '-z' options in ping.c from Apple opensource for usage examples.

FWIW, proposals on iPhone with iOS 15.2.1: Phase 1: ID:ENCR/PRF/D-H IKE:AES-CBC-256/SHA2-256/MODP-2048 IKE:AES-CBC-256/SHA1/MODP-2048 IKE:AES-CBC-256/MD5/MODP-2048 IKE:AES-CBC-256/SHA2-512/MODP-2048 IKE:AES-CBC-256/SHA1/MODP-1024 IKE:AES-CBC-256/MD5/MODP-1024 IKE:AES-CBC-128/SHA1/MODP-1024 IKE:AES-CBC-128/MD5/MODP-1024 IKE:3DES-CBC/SHA1/MODP-1024 IKE:3DES-CBC/MD5/MODP-1024 IKE:DES-CBC/SHA1/MODP-1024 IKE:DES-CBC/MD5/MODP-1024 Phase 2: ID:ENCR/PRF IKE:AES-CBC-256/SHA2-256 IKE:AES-CBC-256/SHA1 IKE:AES-CBC-256/MD5 IKE:AES-CBC-128/SHA2-256 IKE:AES-CBC-128/SHA1 IKE:AES-CBC-128/MD5 IKE:3DES/SHA2-256 IKE:3DES/SHA1 IKE:3DES/MD5

It uses the older SMLoginItemSetEnabled.

Okay, I seem to get to the bottom of this. One detail that I missed is that I run homebrew installation process as a non-admin user and group: $ dscl . -read /Users/brew dsAttrTypeNative:IsHidden: 1 PrimaryGroupID: 801 RealName: Homebrew RecordName: brew RecordType: dsRecTypeStandard:Users UniqueID: 801 UserShell: /usr/bin/false $ dscl . -read /Groups/brew GroupMembership: brew PrimaryGroupID: 801 RealName: Homebrew RecordName: brew RecordType: dsRecTypeStandard:Groups When Homebrew installs the app, I end up with a bundle owned by brew:brew. Launching the app with login user will display the warning only once, but the quarantine attribute will remain with unchanged value regardless of how many times I restart it. However, if I chown the app to the login user before the launch, I will get the warning again (even if I already got one when it was owned by other user) but this time attribute's value will get cleared. Do you think I should file a bug?