Post not yet marked as solved
Hi,I have a launchd daemon that exposes an XPC API. For security reasons, I would like to add checks to certain of my XPC API calls to ensure that the calling process belongs to a session that is attached to the physical console. I thought that I would be able to do this with libbsm, using the auditon API to request the A_GETPINFO_ADDR for the remote process. In the data returned from auditon, I look at the ap_flags member of auditpinfo_addr_t. I was hoping that for remote screen sharing sessions that the AU_SESSION_FLAG_HAS_CONSOLE_ACCESS wouldn't be present but that appears to not be the case. Remote screen sharing sessions appear to have the same session flags as a physical console user.Just so I'm clear, I have User A logged into the physical console and then User B logs in via screen sharing using a different account and doesn't take over the existing session.Is there any way that I can detect this situation?Thanks,Dustin
Post not yet marked as solved
I have an app that adds some items to the keychain. I've noticed recently that when upgrading the app, the system pops up the "allow access to this keychain item" dialog when it attempts to read a keychain item that was added by the previous version. This app is codesigned and passes all codesign diagnostics. Did something change recently that causes this permission request to pop up even though the both versions of the app are signed with the exact same certificate.I will state that the app is not signed with a Developer ID Application certificate but with a valid code signing certificate from a non-Apple CA. Is there some new requirement that a Developer ID Application certificate must be used in order to not see this prompt when an app is upgraded?I dumped the keychain using "security dump-keychain -a" before and after upgrade and the only difference between the item is that the partition_id entry contains an additional cdhash for the new app. From what I understand cdhash will change when there are major changes in the app, which is likely on upgrade.What can I do to prevent this dialog from appearing on app upgrade?
Post not yet marked as solved
I have an app that uses SecCopyCertificateValues and have noticed that the values for certain properties have changed starting in the 10.13.4 betas. For example, if I have a certificate and call SecCopyCertificateValues on it, the public key algorithm attribute kSecOIDX509V1SubjectPublicKeyAlgorithm has a value that is no longer an OID. In previous macOS versions, for RSA encryption, the value would be the RSA OID "1.2.840.113549.1.1.1" but on 10.13.4 betas, the value is now "RSA Encryption".Our code specifically compares the value with the RSA OID to determine if RSA is being used and with this change, that is now broken. Is this a bug or this the expected behavior? Do I need to check for both the OID and the "RSA Encryption" string? If this is expected, is there a list of constants somewhere for what the possible string values are that can be compared?