Is there a way to restrict packages installation via brew?Getting Started

[Mariushrek]

Output of brew config

N/A

Output of brew doctor

N/A

Description of issue

Hey,

I'm looking for an option to restrict packages installation via brew (let's say whitelisted packages). Does brew allow me to do something like that? If so - how do I achieve this?

Thanks,
Mariusz

[SMillerDev]

https://docs.brew.sh/Manpage#environment has some options:
HOMEBREW_ALLOWED_TAPS , HOMEBREW_FORBIDDEN_CASKS, HOMEBREW_FORBIDDEN_LICENSES

[lhaeger]

There is no whitelist option, despite being requested regularly. You can use the blacklists instead and script transforming your whitelists into blacklists with something like:

#!/bin/zsh

echo -n "Reading list of all formulae from Homebrew..."
brew search --formulae /.+/ | tee brew_form_all | wc -l

echo -n "Reading whitelisted formulae..."
cat brew_form_whitelist | wc -l 

echo -n "Calculating dependencies for formulae..."
brew deps --union --formulae --os macos $(<brew_form_whitelist) | tee brew_form_dependencies | wc -l

echo -n "Generate formulae blacklist..."
grep -vxF -f brew_form_whitelist -f brew_form_dependencies brew_form_all | sort -u | tee brew_form_blacklist | wc -l
tr '\n' ' ' < brew_form_blacklist > brew_form_blacklist_env

echo -n "Reading list of all casks from Homebrew..."
brew search --casks /.+/ | tee brew_cask_all | wc -l

echo -n "Reading whitelisted casks..."
cat brew_cask_whitelist | wc -l 

echo -n "Generate casks blacklist..."
grep -vxF -f brew_cask_whitelist brew_cask_all | sort -u | tee brew_cask_blacklist | wc -l
tr '\n' ' ' < brew_cask_blacklist > brew_cask_blacklist_env

export BREW_FORBIDDEN_FORMULAE=$(<brew_form_blacklist_env)
export BREW_FORBIDDEN_CASKS=$(<brew_cask_blacklist_env)

Obviously this has to be repeated regularly to include newly added kegs that are not whitelisted. Annoying but the best there is so far...

[gromgit]

@Mariushrek, I'm curious: what problem are you trying to solve, that "restrict Homebrew package installation" is the correct solution? Perhaps what you're trying to achieve can be done in a different way.

[jasonmccsmith]

Greatly appreciate the thoughtful reply, and after some mulling this over for quite a while, personally I'd opt for allowing casks, with the understanding that you are allowing the cask, complete with all dependencies. The allowing of the dependencies is explicitly implied (oh god, that's going to haunt me) by allowing the cask. If I say "Sure you can bring your laptop" I'm not going to tell you to leave every other key from the keyboard behind. Presumably those using the allowlist are going through the necessary analysis to determine if the entire dependency tree should be allowed. (If not, well... they'll learn.)

One as yet unspoken assumption in that case is that setting the hypothetical HOMEBREW_ALLOWED_CASKS env var implicitly blocks everything not in the allowed list. Nothing is allowed except what is in that list, so placing a cask in that list is deliberately allowing the entirety of the cask to be installed. (This is the behavior that I think would be most quarrelsome. Why an automatic block by default? In my mind, to best mirror that by default all is allowed until HOMEBREW_FORBIDDEN_* are set.)

Now, the fun bit in that scenario is if a cask is allowed, but it's possible to add one or more of its dependencies to HOMEBREW_FORBIDDEN_CASKS. Given that default is now to block, why would you want to do that? Well, say, a zero-day CVE is found in a dependency, but instead of working backwards to determine if any of the allowed casks rely on it, you can just block that dependency immediately. (Assuming that /etc/homebrew/brew.env is under centralized control, yadda yadda.) Gives some time to address correctly. Yes, that breaks the symmetry outlined with the defaults above, so perhaps that's a step too far. Again, useful, but some consistency in life would be nice.

If that case were to be permitted, provide the user with copious info to return to IT with and escalate the issue. :D

I definitely understand that homebrew is not designed to operate in the way I'm wanting, but it feels so close, and while the private tap may work, yeah... hairy. A lot of questions there about cloning core formulae over so that core is never referenced if possible, whether HOMEBREW_ALLOWED_TAPS appends the taps to the core default, or replaces it so that core is inaccessible, etc.

I'm fairly certain that the specific IT team in question would not be willing to take that on, and instead be satisfied with declaring homebrew programma non grata.

This would be so much simpler in practice.

In theory. ¯_(ツ)_/¯

Where to slot in the functionality looks clear, considering a run at implementing the base case above just to spark discussion.

[p-linnane]

A few things worth addressing:

On HOMEBREW_ALLOWED_TAPS: it's additive, not replacement. Official taps (homebrew/core, homebrew/cask) are always allowed. To truly isolate to a private tap you'd need to combine it with forbidden rules for everything in core you don't want, which is roughly what @lhaeger's script above automates.

On "allowing a cask implicitly allows all its deps": the dep tree isn't static. A cask your security team audited last month can gain a new transitive dep next week because upstream added one. Under implicit-allow, that new dep walks in unaudited. Silent supply-chain trust extension is a hard sell to anyone above the team setting the policy.

On your CVE scenario: HOMEBREW_FORBIDDEN_FORMULAE already cascades through deps. Forbid libfoo and anything depending on it is blocked. Already covered.

On implementation: my honest read as a maintainer is that appetite for control-plane features like this has historically been low. You can try opening an issue on Homebrew/brew, but I wouldn't write any code for this yet.

The private tap really is the supported path, hairy or not. If IT ends up declaring brew unsupported, that's also a valid outcome. Not every tool has to fit every environment.

[jasonmccsmith]

Fabulous, thanks for the clarifications, you just saved me an evening of testing the private tap.

Well noted on the dep tree, they're already running scans of installed packages and tracking inner dependencies against CVEs. (Quite robust, honestly.) For most environments, your point is likely to be the outcome.

Unfortunately, there's little in the way of replacement for homebrew on macOS for the cases they're tripping over. You guys are just too good.

I'll modify @lhaeger's script (thanks!) and propose it first with a private tap. That may be the fastest path to an acceptable solution that keeps their projects on target.

[SMillerDev]

Just because it wasn't brought up yet. https://workbrew.com/ might also help here

[jasonmccsmith]

nod Yup, that would likely be a good option, but there's no appetite there for spending money on this. Thanks for pointing it out though.