Unable to set the configuration element enable_transitive_rules using santactl

[built2order]

Using santactl, a root user is able to add a rule to add a binary to a transitive allowlist however these rules are ignored unless EnableTransitiveRules is set to true. Currently this configuration element can only be set using a sync server.

# santactl rule --compiler --identifer 2ZEFAR8TH3:com.jetbrains.rider --signingID
Added rule for (Unknown type): 2ZEFAR8TH3:com.jetbrains.rider.
# santactl rule --export 
{
  "custom_msg" : "",
  "rule_type" : "SIGNINGID",
  "identifer" : "2ZEFAR8TH3:com.jetbrains.rider",
  "custom_url" : "",
  "policy" : "ALLOWLIST_COMPILER"
}

A reasonable person might assume that if a user can use santactl to add a specific binary to the ALLOWLIST_COMPILER policy, they should also be able to enable the feature using santactl.

[mlw]

Looking at code, it seems that this is supported in the main configuration (without a sync server) via the EnableTransitiveRules key. However, it unfortunately does not seem to be documented.

[pmarkowsky]

A reasonable person might assume that if a user can use santactl to add a specific binary to the ALLOWLIST_COMPILER policy, they should also be able to enable the feature using santactl.

So we gate this feature behind a configuration flag because the compiler rule feature is pretty powerful. E.g. if you mark the wrong thing like a browser like Chrome as a compiler then you're allowing anything downloaded from the internet. Depending on your environment and constraints you may not want to even allow this feature as an option.

For standalone installations you can change your application config by adding the <key>EnableTransitiveRules></key><true/> to make this work. After which you can then use santactl to add compiler rules.

@built2order Are you suggesting that the feature should just be enabled by default for standalone installations?

[mlw]

Can you please paste the output from santactl status (feel free to sanitize things like sync server addresses if desired).

I'd also like the output from sudo grep -A1 EnableTransitiveRules /var/db/santa/sync-state.plist

[built2order]

Thanks for your comment. No, not suggesting this should be default, however documentation also didn't suggest that the key could be added to configuration.

I've since added the configuration key to MDM configuration however the feature is still not active.

# profiles show -o stdout | grep EnableTransitiveRules
			EnableTransitiveRules = 1;
# santactl rule --compiler --identifer 2ZEFAR8TH3:com.jetbrains.rider --signingID
Added rule for (Unknown type): 2ZEFAR8TH3:com.jetbrains.rider.
# santactl rule --export 
{
  "custom_msg" : "",
  "rule_type" : "SIGNINGID",
  "identifer" : "2ZEFAR8TH3:com.jetbrains.rider",
  "custom_url" : "",
  "policy" : "ALLOWLIST_COMPILER"
}

A clean build and run of a basic 'hello-world' app using Rider is still blocked.

/Users/test-user/RiderProjects/hello-world/bin/Debug/net8.0/hello-world

Santa

The following application has been blocked from executing because it has not yet been approved.

Path:	/Users/test-user/RiderProjects/hello-world/bin/Debug/net8.0/hello-world
Identifer:	...
Parent:	rider (24988)

Please see additional comments below. Note that all configuration has been applied via MDM or local commands using santactl.

% santactl status
>> Daemon Info

  Mode                      | Monitor
  Log Type                  | filelog
  File Logging              | No
  USB Blocking              | No
  On Start USB Options      | None
  Watchdog CPU Events       | 0  (Peak: 12.15%)
  Watchdog RAM Events       | 0  (Peak: 159.20MB)
>> Cache Info

  Root cache count          | 346
  Non-root cache count      | 9
>> Database Info

  Binary Rules              | 39
  Certificate Rules         | 0
  TeamID Rules              | 11
  SigningID Rules           | 7
  Compiler Rules            | 4
  Transitive Rules          | 0
  Events Pending Upload     | 13
>> Watch Items

  Enabled                   | No
% sudo grep -A1 EnableTransitiveRules /var/db/santa/sync-state.plist
% ls -al /var/db/santa
total 54288
drwxr-xr-x   17 root  wheel      544 22 Jan 20:30 .
drwxr-xr-x  116 root  wheel     3712 22 Jan 21:39 ..
-rw-------    1 root  wheel    86016 22 Jan 11:51 events.db
-rw-------    1 root  wheel    12288 22 Jan 11:09 rules.db
-rw-r--r--    1 root  wheel    12824 22 Jan 11:09 rules.db-journal
-rw-r--r--    1 root  wheel  2848944 22 Jan 21:40 santa.log
-rw-r--r--    1 root  wheel  2709119 22 Jan 20:30 santa.log.0.gz
-rw-r--r--    1 root  wheel  3218950 22 Jan 12:30 santa.log.1.gz
-rw-r--r--    1 root  wheel  2027526 18 Jan 17:36 santa.log.10.gz
-rw-r--r--    1 root  wheel  2190452 22 Jan 10:30 santa.log.2.gz
-rw-r--r--    1 root  wheel  1727944 21 Jan 21:36 santa.log.3.gz
-rw-r--r--    1 root  wheel  1707653 20 Jan 10:43 santa.log.4.gz
-rw-r--r--    1 root  wheel  2821174 19 Jan 12:30 santa.log.5.gz
-rw-r--r--    1 root  wheel  2002698 19 Jan 08:30 santa.log.6.gz
-rw-r--r--    1 root  wheel  1822620 19 Jan 04:30 santa.log.7.gz
-rw-r--r--    1 root  wheel  2971994 18 Jan 22:30 santa.log.8.gz
-rw-r--r--    1 root  wheel  1273053 18 Jan 21:30 santa.log.9.gz

[pmarkowsky]

Unfortunately just noticed that we're only reporting if transitive rules are enabled in santactl status if a sync service url is set.

I've filed #1276 to address this.

[mlw]

I ran some basic tests using rustc to compile a simple "hello world" program. Using the eslogger(1) utility to trace how rustc manages binary creation and signing, it appears that ld(1) is actually the last executable to touch the binary and is responsible for creating the final executable.

On Apple Silicon macs at least, all code is required to be signed to execute, even if just adhoc signed. The man page for ld(1) states the following:

     -adhoc_codesign
             Directs the linker to add an ad-hoc codesignature to the output file. The default for Apple Silicon binaries is to be ad-hoc codesigned.

I'm not sure how com.jetbrains.rider works. You'll need to figure out how it manages the build and signing steps and determine what is responsible for creating the final executable. For small, test programs it may just be ld(1). For bigger, more complicated setups with custom signing flows, it may be codesign(1). It is unlikely to be something other than those two things...

Once you determine more about how your toolchain works, you'll need to change your compiler rule to target the appropriate binary as a compiler.

Unfortunately just noticed that we're only reporting if transitive rules are enabled in santactl status if a sync service url is set.

I've filed #1276 to address this.

Also to be clear, while this is a issue with the status output, it is not the cause of the issue you're seeing.

[mlw]

Can we close this issue, or are you still encountering issues that may be Santa related?

[built2order]

I'm still working through documenting the requirements to support multiple compiler environments including Go; Jetbrains X; and Xcode using just MDM and santactl. Frustratingly I've still not yet crack the required commands to deploy this.

As an example, Go binaries are still denied after the following configuration is applied:

# santactl rule --compiler --identifier EQHXZ8M8AV:org.golang.compile --signingID
Added rule for (Unknown type): EQHXZ8M8AV:org.golang.compile.
# santactl rule --compiler --identifier EQHXZ8M8AV:org.golang.link --signingID
Added rule for (Unknown type): EQHXZ8M8AV:org.golang.link.
# santactl rule --compiler --identifier EQHXZ8M8AV:org.golang.asm --signingID
Added rule for (Unknown type): EQHXZ8M8AV:org.golang.asm.
# santactl rule --compiler --identifier EQHXZ8M8AV:org.golang.go --signingID
Added rule for (Unknown type): EQHXZ8M8AV:org.golang.go.

Go binary blocked from launching:

% go build .
% ./hello
zsh: killed     ./hello

Santa

The following application has been blocked from executing because it has not yet been approved.

Path:       /Users/username/source/go/hello
Identifier: ad5d8656080c559743238aca695c5c25ad9f73bc31b618b2cbb518edb0284c78
Parent:     zsh (21708)

[built2order]

Are transitive rules evaluated before scopes?

I can confirm that compiler configuration is correctly set however the output is still blocked.

[2024-02-16T07:13:16.349Z] I santad: action=EXEC|decision=ALLOW|reason=COMPILER|sha256=5d7cb76180628de4a932b8fe035b27d4438cfc35ee74bb84554d882ff43ddbc9|cert_sha256=0bda2aca4b967fd15bb6840c54de1cc230921efd1a181a6f0fc814ada3ffaa4f|cert_cn=Developer ID Application: Google LLC (EQHXZ8M8AV)|teamid=EQHXZ8M8AV|pid=25226|pidversion=4989875|ppid=25217|uid=502|user=username|gid=20|group=staff|mode=M|path=/usr/local/go/pkg/tool/darwin_arm64/compile|args=/usr/local/go/pkg/tool/darwin_arm64/compile -V=full
[2024-02-16T07:13:16.436Z] I santad: action=EXEC|decision=ALLOW|reason=COMPILER|sha256=5d7cb76180628de4a932b8fe035b27d4438cfc35ee74bb84554d882ff43ddbc9|cert_sha256=0bda2aca4b967fd15bb6840c54de1cc230921efd1a181a6f0fc814ada3ffaa4f|cert_cn=Developer ID Application: Google LLC (EQHXZ8M8AV)|teamid=EQHXZ8M8AV|pid=25225|pidversion=4989871|ppid=25217|uid=502|user=username|gid=20|group=staff|mode=M|path=/usr/local/go/pkg/tool/darwin_arm64/compile|args=/usr/local/go/pkg/tool/darwin_arm64/compile -V=full
[2024-02-16T07:13:16.555Z] I santad: action=EXEC|decision=ALLOW|reason=COMPILER|sha256=5d7cb76180628de4a932b8fe035b27d4438cfc35ee74bb84554d882ff43ddbc9|cert_sha256=0bda2aca4b967fd15bb6840c54de1cc230921efd1a181a6f0fc814ada3ffaa4f|cert_cn=Developer ID Application: Google LLC (EQHXZ8M8AV)|teamid=EQHXZ8M8AV|pid=25229|pidversion=4989880|ppid=25217|uid=502|user=username|gid=20|group=staff|mode=M|path=/usr/local/go/pkg/tool/darwin_arm64/compile|args=/usr/local/go/pkg/tool/darwin_arm64/compile -o /var/folders/8d/q24m82191b393tgwcgv6kc380000gp/T/go-build3391069213/b001/_pkg_.a -trimpath /var/folders/8d/q24m82191b393tgwcgv6kc380000gp/T/go-build3391069213/b001=> -p main -lang=go1.21 -complete -buildid mIC7tFUtazzsdo-cVkYk/mIC7tFUtazzsdo-cVkYk -goversion go1.21.0 -c=4 -shared -nolocalimports -importcfg /var/folders/8d/q24m82191b393tgwcgv6kc380000gp/T/go-build3391069213/b001/importcfg -pack /Users/username/source-go/hello.go
[2024-02-16T07:13:16.612Z] I santad: action=EXEC|decision=ALLOW|reason=COMPILER|sha256=a9fe802f9243949e78b3295748f8b10314baafb932d03ceae7ef962d1aa240b9|cert_sha256=0bda2aca4b967fd15bb6840c54de1cc230921efd1a181a6f0fc814ada3ffaa4f|cert_cn=Developer ID Application: Google LLC (EQHXZ8M8AV)|teamid=EQHXZ8M8AV|pid=25230|pidversion=4989882|ppid=25217|uid=502|user=username|gid=20|group=staff|mode=M|path=/usr/local/go/pkg/tool/darwin_arm64/link|args=/usr/local/go/pkg/tool/darwin_arm64/link -V=full
[2024-02-16T07:13:16.612Z] I santad: action=EXEC|decision=ALLOW|reason=COMPILER|sha256=a9fe802f9243949e78b3295748f8b10314baafb932d03ceae7ef962d1aa240b9|cert_sha256=0bda2aca4b967fd15bb6840c54de1cc230921efd1a181a6f0fc814ada3ffaa4f|cert_cn=Developer ID Application: Google LLC (EQHXZ8M8AV)|teamid=EQHXZ8M8AV|pid=25231|pidversion=4989884|ppid=25217|uid=502|user=username|gid=20|group=staff|mode=M|path=/usr/local/go/pkg/tool/darwin_arm64/link|args=/usr/local/go/pkg/tool/darwin_arm64/link -o /var/folders/8d/q24m82191b393tgwcgv6kc380000gp/T/go-build3391069213/b001/exe/a.out -importcfg /var/folders/8d/q24m82191b393tgwcgv6kc380000gp/T/go-build3391069213/b001/importcfg.link -buildmode=pie -buildid=8x6MoO93oBD-b3xTCRkV/mIC7tFUtazzsdo-cVkYk/6hnszsLHBRl8_Bnm5lqb/8x6MoO93oBD-b3xTCRkV -extld=clang /var/folders/8d/q24m82191b393tgwcgv6kc380000gp/T/go-build3391069213/b001/_pkg_.a
[2024-02-16T07:13:19.595Z] I santad: action=EXEC|decision=DENY|reason=SCOPE|explain=Blocked Path Regex|sha256=8aca6f9263fbd061f0acc2ebc9b2b8872720b2be8cdd8a40a4ca031f43cdc875|pid=25232|pidversion=4989886|ppid=21708|uid=502|user=username|gid=20|group=staff|mode=M|path=/Users/username/source-go/hello|args=./hello

[mlw]

Are transitive rules evaluated before scopes?

Yes.

I can confirm that compiler configuration is correctly set however the output is still blocked.

We know there are some gaps in transitive allowlisting in different toolchains given they all produce binaries differently.

Tracking some very basic Go builds with various events in eslogger(1), this may be related to an issue with how rename events for compilers are tracked.

Are you able to easily enable debug logging in your setup (setting EnableDebugLogging to true)? if so, could you then run something like the following command in the background while attempting your test build:

sudo log stream --level debug --style compact --predicate 'sender == "com.google.santa.daemon"'

I'd like to know if you're hitting this log line, and if so, what the full message is (feel free to redact the path):

santa/Source/santad/SNTCompilerController.mm

Lines 135 to 137 in 7513c75

	LOGD(@"Unable to create SNTFileInfo while attempting to create transitive rule. Event: %d | "
	@"Path: %@ | Error: %@",
	(int)esMsg->event_type, @(targetFile->path.data), error);

[mlw]

Related: #1299

[mlw]

Related: #1327

This shouldn't affect go build, but if you use go run you may encounter similar issues.