Is your feature request related to a problem? Please describe.
yay runs makepkg's prepare/build/package() as the invoking user, with full read access to $HOME and unrestricted network. A malicious PKGBUILD can read SSH keys, PGP/GPG keys, tokens, browser data, crypto wallets or other secrets/projects/documents in the $HOME directory during build time and send the content over the network before the user decides to install the package.
This behavior can be unintuitive making an accidental enter when reviewing the PKGBUILD and finding an issue result in data being read and sent to an attacker even if the user later chooses not to install the package.
Describe the solution you'd like
An opt-in sandboxed build mode that wraps makepkg build in bubblewrap namespace jail with seccomp similar to how (rua)[https://github.com/vn971/rua] does it:
- build dir mounted read-write, $GNUPGHOME pubrings mounted read only enabling pgp verification. Rest of $HOME hidden behind an empty tmpfs and rest of / read-only. Empty /tmp, /dev and /proc
- seccomp filter hiding pid/ipc/user/uts/cgroup/... namespaces
- Configurable bind-mount allowlist for caches such as cargo, npm, go, enabling more special cases
This change risks breaking some PKGBUILDs, however from the time I used rua, it seemed to be fairly rare and usually for PKGBUILDs that did not follow packaging conventions.
Describe alternatives you've considered
- Implement in yay instead of requiring bubblewrap. This would also be fine, but likely require more work to implement.
- Submit as improvement to makepkg hardening all builds: Issue is that some PKGBUILDs may fail and the feature may need tuning, so an opt in config in yay seems more reasonable.
- using makechrootpkg: Does not address security sandboxing properly
- Wrapping of makepkg on system through wrapper earlier in path: Easy to misconfigure, tools using makepkg could have a different path or use absolute paths skipping entirely.
Additional context
This feature isolates build moving the point in time where a compromised PKGBUILD or build in repo could lead to compromise of the system to install time in pacman rather than when building.
It would also shield users of AUR against build time supply chain attacks i.e. npm build time scripts from dependencies directly compromising data on the system.
I do not consider this a vulnerability in yay as current use should be to always review everything before installing from AUR, however it provides a defence in depth and a more intuitive understanding of when a compromise can occur, i.e. only once a package has started installing and not during build time.
Note that as long as network access is available this feature will not prevent a build script from scanning the network, finding a vulnerable device on the local network and attacking that way. It only shields the data on the users system. As blocking network (offline-mode) is likely to break a lot more packages I opted to not include it in the proposal.
Is your feature request related to a problem? Please describe.
yay runs makepkg's prepare/build/package() as the invoking user, with full read access to $HOME and unrestricted network. A malicious PKGBUILD can read SSH keys, PGP/GPG keys, tokens, browser data, crypto wallets or other secrets/projects/documents in the $HOME directory during build time and send the content over the network before the user decides to install the package.
This behavior can be unintuitive making an accidental enter when reviewing the PKGBUILD and finding an issue result in data being read and sent to an attacker even if the user later chooses not to install the package.
Describe the solution you'd like
An opt-in sandboxed build mode that wraps makepkg build in bubblewrap namespace jail with seccomp similar to how (rua)[https://github.com/vn971/rua] does it:
This change risks breaking some PKGBUILDs, however from the time I used rua, it seemed to be fairly rare and usually for PKGBUILDs that did not follow packaging conventions.
Describe alternatives you've considered
Additional context
This feature isolates build moving the point in time where a compromised PKGBUILD or build in repo could lead to compromise of the system to install time in pacman rather than when building.
It would also shield users of AUR against build time supply chain attacks i.e. npm build time scripts from dependencies directly compromising data on the system.
I do not consider this a vulnerability in yay as current use should be to always review everything before installing from AUR, however it provides a defence in depth and a more intuitive understanding of when a compromise can occur, i.e. only once a package has started installing and not during build time.
Note that as long as network access is available this feature will not prevent a build script from scanning the network, finding a vulnerable device on the local network and attacking that way. It only shields the data on the users system. As blocking network (offline-mode) is likely to break a lot more packages I opted to not include it in the proposal.