Hello,
I know that EndpointSecurity doesn't support network events, save for some events related to Unix pipes.
In WWDC 2020 #10159 Apple says that:
Those of you who have already worked with the EndpointSecurity framework have likely noticed that we do not provide events related to networking operations. This is intentional as these are better covered by the NetworkExtension framework.
Could you please give me a short and high-level hint how I can use NetworkExtension to provide connect, disconnect events to a monitoring app, that tries to log those events in a database? I would like to receive the remote IP and remote port + local port.
From what I've researched, In NetworkExtension documentation it's stated that it's possible to create a "content filter", which would probably be a good source of information; the problem is that because of the privacy requirements, the "content filter" can't send back any information about user data, because it's separated in a restrictive sandbox. So I'm not sure the "content filter" would even be possible to be used as a source of network events. Other types of categories inside NetworkExtension doesn't seem to be a good match for my use case.
Is it possible to use NetworkExtension to get information about network events (connect/disconnect), like EndpointSecurity does for i.e. processes (process start/process end)?
Hello,
3 questions regarding Endpoint Security Framework:
Does ESF support tracing the dup2(2) function? There is the ES_EVENT_TYPE_NOTIFY_DUP event, but it seems that it only reports dup(2), not dup2(2)?
Does ESF support tracing the dup(2), and close(2) calls, if the file descriptor passed to these functions refer to a pipe handle instead of a file handle? If not, do you have any plans of extending the support for pipes as well?
Could the es_event_dup_t structure support reporting which file handle has been duplicated into which value (source file descriptor value, and target file descriptor value)? Currently this structure only supports the "target" file object, without any information which file descriptor has been cloned into which file descriptor, which is not helpful at all. For example, if we open file A and we get fd1, then open the same file A and we get fd2, then perform dup(fd1), then with ESF it seems that it's impossible to tell if we've duplicated fd1 or fd2. Also this model doesn't support dup2(2) usage at all.
Post not yet marked as solved
Hello, we have an app (a service) that contains an auto-update feature. This auto-update feature allows to update certain components, packaged as dylib files: 1 component = 1 dylib file. Those dylib files are written in a way that the app can unload the old versions and load new versions without restarting itself. So, when the user clicks "update", the app will download new dylibs from the company server, it will unload old dylibs, load new ones, and will start using new dylibs immediately. The dylibs are digitally signed with the same digital sign that was used to sign all the executables in the app.
I'm wondering how to solve the notarization problem for this case. Since notarization is a process that results in acquiring a "staple id" that should be placed inside the Contents/CodeResources file, does that mean that it's impossible to distribute "*****" MachO files that are not a part of any bundle? Because those "*****" MachO files do not have any place that allows to embed a "staple id". Do I understand it correctly?
Is there a method of embedding a "staple id" any other way than inside the Contents/CodeResources file?
What would be a suggested solution to the "auto-update feature that downloads signed dylib files" problem? Should we wrap dylibs into bundles, and download bundles instead of the "*****" dylibs? (since bundles can be stapled).
Kernel tells me that my dylib has an invalid digital sign, but for 100% it's a proper digital sign. Is this a bug, or a feature?
Minimal 100% reproducible example:
loader.cpp:
#include <cstdio>
#include <iostream>
#include <dlfcn.h>
int main() {
void* handle = dlopen("libtest.dylib", RTLD_NOW);
perror("dlopen");
return handle == nullptr;
}
test1.cpp:
#include <cstdio>
#include <iostream>
__attribute__((constructor)) void initfunc() {
std::cout << "hello from dylib1\n";
}
test2.cpp:
#include <cstdio>
#include <iostream>
__attribute__((constructor)) void initfunc() {
std::cout << "hello from dylib2\n";
}
Makefile:
all: libtest1.dylib libtest2.dylib loader
libtest1.dylib: test1.cpp
c++ -shared test1.cpp -o libtest1.dylib
libtest2.dylib: test2.cpp
c++ -shared test2.cpp -o libtest2.dylib
loader: loader.cpp
c++ loader.cpp -o loader
CMakeLists.txt instead of Makefile:
cmake_minimum_required(VERSION 3.5)
project(crash_test)
add_executable(loader loader.cpp)
add_library(test1 SHARED test1.cpp)
add_library(test2 SHARED test2.cpp)
Store all files into one directory and compile the binaries either by using make or cmake.
Reproduction scenario (100%):
Run Make or CMake to compile the source files,
Copy libtest1.dylib to libtest.dylib:
$ cp libtest1.dylib libtest.dylib
Run ./loader
Observe proper runtime without errors:
$ ./loader
hello from dylib1
dlopen: Undefined error: 0
Copy libtest2.dylib to libtest.dylib:
$ cp libtest2.dylib libtest.dylib
Run ./loader
Observe crash:
$ ./loader
[1] 96122 killed ./loader
Remove libtest.dylib
Repeat step 5: Copy libtest2.dylib to libtest.dylib:
$ cp libtest2.dylib libtest.dylib
Run ./loader and observe everything is OK:
$ ./loader
hello from dylib2
dlopen: Undefined error: 0
Is this a bug or a feature?
It seems to me that something is caching codesign information based on file inode. Replacing files seem to retain old inode while storing new data inside previously existing inode. Shouldn't replacing the file invalidate this cache, wherever it is?
Is this documented somewhere? Maybe macOS requires me to always remove dylibs before reusing their names? I couldn't see any documentation about that.
System information
I'm observing this on various macOS machines, on real machines and virtualized using Virtualization.framework. Currently I'm using this macOS version:
$ sw_vers
ProductName: macOS
ProductVersion: 12.6
BuildVersion: 21G115
MistyFog.