System Extension (ES client) getxattr

Question

Created Jan ’21

Replies 2

Boosts 0

Participants 2

Hello,

in our system extension we monitor AUTH_OPEN events via the Endpoint Security client. The extension is correctly signed (with hardened runtime) and has full disk access enabled.

For each open event we try to obtain the extended attribute "com.apple.quarantine" using getxattr() and the path name provided in the open event.

The getxattr() call is always returning ENOATTR (93) even for files that have the "com.apple.quarantine" attribute set.

Does obtaining extended attributes not work from a system extension, do we need any special entitlements or is this just a bug?

Note: Big Sur 11.1 - this only shows with SIP enabled, with SIP disabled the attributes can be read correctly.

Frank
Sophos Inc.

Boost

Answer 1

ffenn OP

Jan ’21

tried a different approach by sending an open file handle via XPC to the extension hosting app and then tried to use fgetxattr() on that file handle. This only works with SIP disabled. With SIP enabled, the hosting app also needs full disk access but then reading the extended attributes succeeds.

What are the current security implications by sending file handles via XPC in a SIP-enabled environment from a root system extension to user launched app?

Frank

0

Answer 2

DTS Engineer OP

Apple

Jan ’21

I can’t think of any reason why you’d be seeing this problem, and we ran a test internally and weren’t able to reproduce it. My advice:

Try distilling this down into a small test project. That’ll rule out the possibility that there’s something about your main project that’s causing the issue.
If the test project reproduces the problem, file a bug about it, attaching your test project to that bug. Please post your bug number, just for the record.
If you’d like for someone in DTS to help you with this, feel free to open a DTS tech support incident.

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

0