Endpoint Security and the system functionality

I am playing with endpoint security. I trying to implement block/allow user to read/write files on a USB media drive. I made my ep utility as launchctl daemon. I found that some applications couldn't start until I mute those processes for ep_client.
Moreover, some system processes couldn't start until I mute messages from them. And even more, if my utility autoruns on system start, the clock on the top right corner of the screen may be absent. The Terminal app couldn't restore its state, it hangs on start.
Actually, I came to that, my EP daemon should listen to very few processes. Those processes that can read/write files on USB media, and do it by user request. Or under user control.
When KAUTH was not deprecated, I did it right in the kernel extension: if the vnode path is NOT on a removable drive, return DEFER at the beginning of callback.
My question is:
What processes are pure system?
What system processes can read/write files for user or under user control?
Does, for example, /usr/libexec/nsurlsessiond can download a file for user to the USB media?

Accepted Reply

What I did found about this issue:

The key of described issue is in the answering for ES_EVENT_TYPE_AUTH_OPEN event.

How ep_client should answer:

  • If allow all open operations: ep_client should answer with 0xffffffff flag. es_respond_flags_result(aClient, _esMessage, 0xffffffff, aCacheFlag);
  • if deny all open operations: 0x0
  • if deny only read: 0xffffffff & ~FREAD
  • if deny only write: 0xffffffff & ~FWRITE
  • if deny only read and write but allow others:
                    int32_t flags = 0xffffffff;
                    flags = flags & ~FWRITE;
                    flags = flags & ~FREAD;
                    es_respond_flags_result(aClient, _esMessage, flags, aCacheFlag);

Answering in other ways may cause to undefined system behavior, such as described above.

Replies

How can I ecologically prevent user to read/write from USB drive?

If I deny access to one processes, and allow to other it may brake system consistency.

I found that open and save panel is also driven by separate process.

What I did found about this issue:

The key of described issue is in the answering for ES_EVENT_TYPE_AUTH_OPEN event.

How ep_client should answer:

  • If allow all open operations: ep_client should answer with 0xffffffff flag. es_respond_flags_result(aClient, _esMessage, 0xffffffff, aCacheFlag);
  • if deny all open operations: 0x0
  • if deny only read: 0xffffffff & ~FREAD
  • if deny only write: 0xffffffff & ~FWRITE
  • if deny only read and write but allow others:
                    int32_t flags = 0xffffffff;
                    flags = flags & ~FWRITE;
                    flags = flags & ~FREAD;
                    es_respond_flags_result(aClient, _esMessage, flags, aCacheFlag);

Answering in other ways may cause to undefined system behavior, such as described above.