Compiler rules not allowing specified compiler binary to run?

[p-harrison]

Hey,

Not sure if this is a bug or my misunderstanding, but here goes.

I had a rule like this pushed to devices which was allowing XCode to run -

    {
      "creation_time": 1692697150,
      "custom_msg": "",
      "identifier": "59GAB85EFG:com.apple.dt.Xcode",
      "policy": "ALLOWLIST_COMPILER",
      "rule_type": "SIGNINGID"
    },

We do a small bit of macOS development so I wanted to test out Compiler/Transitive rules. So I edited the rule above as follows and did a clean sync to all devices -

    {
      "creation_time": 1692697150,
      "custom_msg": "",
      "identifier": "59GAB85EFG:com.apple.dt.Xcode",
      "policy": "ALLOWLIST_COMPILER",
      "rule_type": "SIGNINGID"
    },

We started to get reports of Santa popups for XCode and running fileinfo against it showed it as "BLOCKED (UNKNOWN)". 'santactl status' and PreFlight was showing 3 compiler rules on the devices, so the rule was being received and added to the database. I edited the rule again, to change the policy to "ALLOWLIST" and XCode started to work again.

We're running Santa 2023.7.

Cheers!

[pmarkowsky]

Compiler rules currently only with with hashes.

The idea here is that you're approving a specific version of a compiler.

[p-harrison]

OK great thanks, I had an inkling you might say that! I'll update the documentation later.

I wonder if the Santa client should reject rules where the Policy is "ALLOWLIST_COMPILER" and the Type is anything other than "BINARY"? Or better yet maybe it could allow use of other types to permit a compiler, for those of us willing to accept the additional risk?

[pmarkowsky]

Documentation is fixed in #1172

[pmarkowsky]

I wonder if the Santa client should reject rules where the Policy is "ALLOWLIST_COMPILER" and the Type is anything other than "BINARY"? Or better yet maybe it could allow use of other types to permit a compiler, for those of us willing to accept the additional risk?

Admittedly the feature was originally designed before signing ID rules existed. It may be a good time to revisit if we want to keep compiler rules to a BINARY rules. I know other folks in the community would probably be interested in marking the go toolchain as a compiler via signing ID rules so they don't have to update their rules for every release.

[mlw]

It may be a good time to revisit if we want to keep compiler rules to a BINARY rules. I know other folks in the community would probably be interested in marking the go toolchain as a compiler via signing ID rules

Agreed. FWIW I don't see a good reason to not handle compiler signing ID rules. It wasn't done initially just keep the overall effort a little smaller and more focused. But expanding it shouldn't be too much of a hassle.

Not that it was asked for, but I don't think certificate or team ID rules would be good candidates for compiler rule types as they're too broad.

[pmarkowsky]

Not that it was asked for, but I don't think certificate or team ID rules would be good candidates for compiler rule types as they're too broad.

I agree. Team ID and Certificate rules are a bit too broad. Additionally if we implement #954. You'd sort of have a loose proxy for a given compiler version.

[pmarkowsky]

We've now made Signing ID rules work with transitive allowlisting. I'm going to close this issue. Please feel free to reopen if there's more to address.