EndpointSecurity ES_EVENT_TYPE_AUTH_IOKIT_OPEN and IO device data

Hi All,
I'm studying the new AUTH event ES_EVENT_TYPE_AUTH_IOKIT_OPEN introduced in the EndpointSecurity framework on macOS 11.

The event is called correctly when someone tries to open a new IO device, for instance, any USB device.

If the endpoint answers ES_AUTH_RESULT_DENY then the device is correctly stopped.

In message->event I see an event of type es_event_iokit_open_t

Code Block
/**
 * @brief Open a connection to an I/O Kit IOService
 *
 * @field user_client_type A constant specifying the type of connection to be
 *    created, interpreted only by the IOService's family.
 *    This field corresponds to the type argument to IOServiceOpen().
 * @field user_client_class Meta class name of the user client instance.
 *
 * This event is fired when a process calls IOServiceOpen() in order to open
 * a communications channel with an I/O Kit driver. The event does not
 * correspond to driver <-> device communication and is neither providing
 * visibility nor access control into devices being attached.
 */
typedef struct {
uint32_t user_client_type;
es_string_token_t user_client_class;
uint8_t reserved[64];
} es_event_iokit_open_t;


Unfortunately, the header says:
Code Block
 The event does not
 * correspond to driver <-> device communication and is neither providing
 * visibility nor access control into devices being attached.


My question is: How can I get info about the device? for instance:
  • Name

  • Vendor

  • Type

  • etc...

Do I need to use IOKit? In this case, How can I connect the event to the device?

Thanks
My reading of your question is that you want to map the information accompanying the ES_EVENT_TYPE_AUTH_IOKIT_OPEN event (that is, the contents of the es_event_iokit_open_t structure) to an I/O Registry entry. Once you have that, you can use the I/O Registry to find whatever information you need about the device. Is that correct?

If so, I’ve some bad news: There’s no direct way to do this You’re not the first person to run into this roadblock and we already have a bug on file requesting improvements (r. 66280743). However, it wouldn’t hurt for you to file your own enhancement request describing your specific requirements.

Apropos those requirements, if you post more details about your specific requirements here, I may be able to an alternative path you might take.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
kappe_m,

I had the same question back in the summer and got this work-around from an Apple rep:

There is a workaround before the fix is implemented: To implement device access control for mass-storage devices based on e.g. USB serial numbers, ES clients can, before responding to mount events, query the IOKit registry for the service object corresponding to the disk device that is about to be mounted (IOBSDNameMatching). From there they can walk the registry tree to find the responsible USB device and query its properties (IORegistryEntryGetParentEntry, IORegistryEntryCreateCFProperties, IORegistryEntryGetChildIterator etc). Based on that information, they can make a policy decision and allow or deny the ES mount event.

This is for USB mass storage events, not any USB device connection. Using the suggestions offered, I was able to get some proof-of-concept code working.

Hope this helps.
I can add to @mdolan's answer, that the DiskArbitration framework can also be used to collect information for mount-points at mount-time (AUTH_MOUNT etc), in addition to IOKit

roughly...

Code Block
- (NSDictionary *)infoForMountPoint:(NSString *)mountPoint {
CFURLRef mountPointURL = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, (CFStringRef)mountPoint, kCFURLPOSIXPathStyle, YES);
    DADiskRef = DADiskCreateFromVolumePath(kCFAllocatorDefault, _daSession, mountPointURL);
    CFDictionaryRef diskDescription = DADiskCopyDescription(diskRef);
    NSMutableDictionary *mountPointInfo = [NSMutableDictionary dictionaryWithDictionary: CFBridgingRelease( diskDescription )];
        // Add IOKit info we need, if available...

EndpointSecurity ES_EVENT_TYPE_AUTH_IOKIT_OPEN and IO device data
 
 
Q