proposal: runtime audit hooks

[mwriter]

Proposal Details

Recently, there have been more and more news like
https://socket.dev/blog/11-malicious-go-packages-distribute-obfuscated-remote-payloads
or
https://alexandear.github.io/posts/2025-02-28-malicious-go-programs/
etc
I propose to implement at the api level the ability to monitor and modify a variety of system calls.
Following the example of how it's already done in python
https://docs.python.org/3/library/audit_events.html
But it's done very poorly there, and it would be useful to implement a full-fledged hook subsystem like

audit.Handle(os.RemoveAll, func(path string) error {
    fmt.Println("Path remove request for:", path)
    switch path {
        case "/bin":
            return nil // deny
        case "/tmp/old":
            return os.Rename(path, "/tmp/new") // replace call
        case "/home":
            path = "/tmp/trash" // replace argument
    }
    return os.RemoveAll(path)
})

or

audit.Handle(http.Get, func(url string) (resp *http.Response, err error) {
    fmt.Println("Http get request for:", url)
    switch url {
        case "some.malware.host":
            return nil, nil
        default:
            url = "http://127.0.0.1:8080"
    }
    return http.Get(url)
})

All this can be done anyway if start inject handler code directly in the golang source code, but why spoil it if you can add a separate powerful subsystem.

[seankhliao]

I believe this is generally considered out of scope.
See also #50632

[mwriter]

I believe

And what right do you have to put your faith above technical discussions?
You put your personal preferences above the interests of the community.

See also #50632

There's a completely different question there

[zigo101]

It looks seankhliao thinks he is the new Go leader. :D

[dominikh]

There's a completely different question there

They address the same need and both suffer the same limitation, see #50632 (comment).

It is not the process's job to audit itself.

[mwriter]

It is not the process's job to audit itself.

The process doesn't do anything by itself, the hooks are created by the programmer to monitor events. If the hooks are not added manually, then there will be no additional impact on performance.
This is a completely different approach compared to the one proposed there by writing rules in go.mod by analogy with AndroidManifest.xml.
By the way, Android has a similar system of hooks at runtime for a long time. Even if it's an outside party.
And the idea itself fits perfectly conceptually, whether it's in a language or an operating system.

[mwriter]

And most importantly, anyone can implement this subsystem by injecting their own handlers to the golang source codes. This is the main argument in favor of the easy possibility of implementing such a subsystem.
It was much more difficult to implement this in python. But even there it was done. Albeit very clumsily.

[zigo101]

@seankhliao

Did you hide @mwriter's comment: #75059 (comment)?
It is hard to say that comment is off-topic. It contains relevant explanation.

Please be polite to Go community members.

[ianlancetaylor]

The proposed facility would not be sufficient to prevent malicious packages from doing nefarious things. Go provides too many mechanisms for programs to invoke system calls, such as assembler code and C code. With Go, preventing in-process behavior can only be reliably done out of process, such as by sandboxing. It can't be done in-process.

A more feasible approach for handling malicious packages (other than sandboxing) might be analyzers that verified that imported packages only used certain facilities. Those analyzers could explicitly call out assembler and C code which would have to be examined manually.

[mwriter]

The proposed facility would not be sufficient to prevent malicious packages from doing nefarious things.

But it's not just about security. In python auditing doesn't cover security issues at all either.
It's mainly about the possibility of general monitoring, logging and tracing. First of all, it's about what dynamic execution analysis tools golang provides.
There are still a lot of advantages from such an implementation.
Moreover, it's not difficult to add the simplest implementation, unlike python.

[mwriter]

Those analyzers could explicitly call out assembler and C code which would have to be examined manually.

By the way, the question is in this regard. After all, during golang runtime, is there any way to detect that C or assembler codes are being called?
If there are variants, then can inject hooks on generally switch to such calls and interrupt their execution according to the proposed scenario.
Then in this case, even the most complete security is possible, unlike python. Because standard APIs will be processed in separate hooks, and the transition to doing anything non-standard can simply be blocked in general hook. And as a result, we will get a semblance of a virtual machine at the golang runtime level :)
Or, when compiled, do all the codes turn into a single binary assembler code that cannot be separated by the original type?

[mwriter]

@cugu

The only exceptions here would be the use of C and assembler code which can be detected as well.

Here, you wrote that once. Can you tell in more detail how easy it is to do this in golang?
Maybe you'll be interested in this discussion as a whole.
Because if it's possible to implement checks at the level of individual hooks, then it will be possible to extend to the most complex scenarios at the level of the entire module management, which you suggested.