permissions on tea-installed executables trigger corporate security monitoring

[amclin]

The use of xattr com.apple.quarantine to set permissions on tea-installed executables sets off reports with my company's global security operations center.

https://github.com/teaxyz/cli/blob/main/src/prefab/install.ts#L100

I ran the example command: tea +gnu.org/wget wget -qO- tea.xyz/white-paper

And promptly got a warning from my global security team about permissions escalation:

File name: find
File path: /usr/bin/find
Command line: find /Users/amclin/.tea/openssl.org/v1.1.118 -xattrname com.apple.quarantine -perm -0200 -exec xattr -d com.apple.quarantine {} ;

They are using CrowdStrike to monitor this, but I have no direct way of testing allow/deny lists with them or CrowdStrike.

I am unclear if the flag happened because of the use of -d com.apple.quarantine, elevating the permission level to 0200, or the masking of the command within find, but I suspect it is likely the removal of the com.apple.quarantine flag that set it off as I've never run into this alert from normal manual usage of chmod or by manually authorizing executables via the control panel's security settings.

[jhheider]

This should (hopefully) be resolved by https://github.com/teaxyz/pantry.core/issues/21. I will check back with you once that's implemented, @amclin .

[mxcl]

The Apple signing won’t unset quarantine. However I'm confused why we are getting quarantined things anyway. The quarantine bit is not (to much knowledge) set by the kernel, it is set by user-land apps like Safari (which is why using cURL has always bypassed GateKeeper).

We added the remove-quarantine-attr because we seemingly needed it for deno at one point and I can’t recall precisely why (JiT something something @jhheider?)

[jhheider]

We added the remove-quarantine-attr because we seemingly needed it for deno at one point and I can’t recall precisely why (JiT something something @jhheider?)

At the time, I was under the impression that the self-signed binaries were triggering gatekeeper. So... properly signed ones hopefully won't need this? Maybe?

The relevant code shows what we thought we accomplished at the time: https://github.com/teaxyz/cli/blob/07dd6d773fad801618449e7263342b0943401dc1/src/prefab/install.ts#L106-L123

[jhheider]

Thinking about this slightly deeper, the files are technically created by tar, which we certainly call out of the host OS[citation needed?]. So, perhaps that is setting/not setting something we'd rather it do? I wonder if using gnu.org/tar in place of the default tar is better.

[magnusviri]

This comment doesn't help what you guys are working on much, but I thought you might want to know (and maybe I've already mentioned this on Discord?). I have RandomWhere installed and running and it regularly notifies me that tea is locking files whenever I install something. In fact, I wonder if this might have something to do with my kernel panics...

[jhheider]

Anything outside of $TEA_PREFIX ever show up? We do have two calls to Deno.flock(), one in prefab/install.ts and one in hooks/useSync.ts.

[mxcl]

I have RandomWhere installed and running and it regularly notifies me that tea is locking files

we use Deno’s flock to lock files during install to prevent a “double-install” problem (since we encourage you to run multiple teas simultaneously this is pretty likely to happen at some point due to the size of the OSS dependency graph).

However, we could probably use some other system (we just want an atomic locking mechanism) which doesn't trigger such security warnings.

[mxcl]

Kinda weird that changing the quarantine bit does this since anything you download with a browser requires this (though Finder (?) does it)

[mxcl]

@magnusviri any clue why RansomWhere is bothered about us locking files? This is a pretty common thing for tools to do. We're not encrypting them, we're just placing a filesystem lock on them to allow us to prevent double writes from separate tea procs.