compiler rule with golang about santa

[ElysiaMae]

go build main.go

./main

The above commands work fine, but not execute dlv dap --listen=127.0.0.1:53789 --log-dest=3 from project in VSCode or execute the go run main.go command

[mlw]

Transitive rules are tricky to get right, and often involves understanding more about how the specific toolchains in use are generating files to ensure appropriate rules can be created.

One thing that has changed since transitive allowlisting was first introduced is the fact that most every binary is now signed, and on Apple Silicon based macs this is a requirement. We can use this to help make configuring compiler rules a bit easier.

Since code signing is the last operation to be performed on a binary, we can instead create compiler rules targeted at binaries responsible for code signing. On macOS, this is most often ld(1) and codesign(1). Can you try creating compiler rules targeting these binaries instead (com.apple.ld and com.apple.security.codesign)?

[ElysiaMae]

Thanks for your answer, I just executed the following command:

sudo santactl rule --compiler --path /usr/bin/ld
sudo santactl rule --compiler --path /usr/bin/codesign

sudo santactl rule --compiler --path /Applications/Xcode.app/Contents/MacOS/Xcode
sudo santactl rule --compiler --path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld

➜ santactl fileinfo /usr/bin/codesign --key "Rule"
Allowed (Compiler)

➜ santactl fileinfo /usr/bin/ld --key "Rule"
Allowed (Compiler)

I'm not sure if the com.apple.ld you're referring to is /usr/bin/ld, I added /usr/bin/ld to the Compiler and it didn't solve the problem.

➜ go run main.go
signal: killed

Santa

This application has been blocked from executing.

Path:       /private/var/folders/13/_wt62zh167dd_m1mdzt6lxzw0000gn/T/go-build649072316/b001/exe/main
Identifier: 929ed1d6baee11bc80d1868f55b1f9517e9e239e86c210a0f8c3a054d03bf1d8
Parent:     go (26488)

In the meantime, the following command does not produce any output:

/usr/bin/log --predicate 'sender=="com.google.santa.daemon"

Thanks again for your help.

[mlw]

I'm not very familiar with the Go toolchain, but I've spent some time playing around with it and using eslogger(1) to track activities such as file creations, modifications, and when the resultant binary is executed (such as under go run).

After chatting with some other folks on the project, I think we may understand a bit better about what's going on.

My previous comment seems to not apply very well to the Go toolchain. They appear to not use standard tooling and instead decided to reimplement signing themselves for some unknown reason (https://pkg.go.dev/cmd/internal/codesign). This appears to track with eslogger(1) output. This unfortunately means that we cannot use the code signing utilities as stand-ins for compiler rules.

What I observed was that the original compiler rule set you had is largely correct - though I don't believe the rules for the compile and asm tools do much. Additionally, the rule for link is unfortunately not working as we'd like - more on this later.

In my tests, I made a simple "hello world" go file named asdfasdf.go for easy greping. In one terminal, ran the following (with various event sets for whatever was interesting for a given run):

sudo eslogger exec mmap open close rename create | grep "asdfasdf"

In the other terminal, I ran various Go tools such as:

go run asdfasdf.go
go build asdfasdf.go

In both the go build and go run cases, the Go toolchain creates a temporary file, on which various tools are run (compile, asm, and link) to construct the final, signed (at least on Apple Silicon macs) binary.

In the go build case, this resultant binary is then moved to the current working directory from which the original command was executed.

In the go run case, the resultant temporary binary is directly executed.

When a process executes that matches a compiler rule, Santa will monitor various operations of that process in order to create transitive rules. One such operation is rename(2). When tracing with eslogger(1) while performing a go build, one of the last steps performed as mentioned above is moving the temporary file in its final form to the current directory. This is done by the main Go binary (org.golang.org). When this happens, Santa creates a binary rule for that file. Since that file is already signed and will no longer be modified, it's hash is correct and will not change. When you execute this file, the transitive rule is already in place and things work as expected.

For go run however, there is a problem. Signing operations are performed by the link tool (org.golang.link). The set of operations that Santa monitors for tracking compiler operations are all asynchronous. Because go run immediately executes the binary, it appears that there is a race condition between when Santa processes the event (in this case "close-modified" or "close-was-mapped-wrtiable") which will generate the rule, and the binary being executed. When the EXEC event happens, this is authorized on a separate event stream within Santa. If the transitive rule hasn't yet been created (e.g. because the event stream tracking compiler operations hasn't processed that event yet), then the execution will be denied.

Further, the Go toolchain appears to perform file modifications on mapped files, complicating things a bit. Santa currently doesn't track munmap(2) operations. However, Go toolchain appears to do things in a slightly non-idiomatic way and doesn't close the file immediately after mmap(2)ing. This at least allows Santa to see the file in the final form after a close(2) operation. However, we should still likely begin tracking munmap(2) as well.

What this means: The transitive allowlisting feature does not currently support toolchains that feature operations like go run (or cargo run) - things that create and immediately execute these executables.

The workaround is to produce the intermediate binary (e.g. via go build) and then to execute that. We'll need to think about a longer term approach here to better support toolchains that have these sorts of operations.

[ElysiaMae]

Thanks for your help, I think there has been a phase about use Santa in lockdown mode with golang. I look forward to a better Santa.

Hopefully the above discussion will help people.