You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm running the Trivy Pipeline extension on a self-hosted agent that per our customer's requirements has been hardened to CIS Benchmark Level 1 - part of this specification will mount the tmpfs with the no execute bit set. This means that the Trivy Extension when run in Binary mode fails to run as it moves the file to /tmp and executes a chmod +x on it.
Would it be possible to allow the tmp path to be set manually or use the /agent/_work/temp path instead?
For now I have been able to hack around the problem by remounting the /tmp directory, and then reverting the change after executing Trivy.
sudo mount -o remount,exec /tmp
<execute trivy extension here>
sudo mount -o remount,noexec /tmp
Note: we are not able to run using the docker image (our preferred option) due to encountering the same issue specified in issues #3 and #19. The work around for these issues was given as running in binary mode.
The text was updated successfully, but these errors were encountered:
MrBasset
changed the title
Unable to use binary on CIS hardened image
Unable to use binary on CIS hardened Pipeline Agent
Aug 8, 2023
Hi,
I'm running the Trivy Pipeline extension on a self-hosted agent that per our customer's requirements has been hardened to CIS Benchmark Level 1 - part of this specification will mount the tmpfs with the no execute bit set. This means that the Trivy Extension when run in Binary mode fails to run as it moves the file to /tmp and executes a
chmod +x
on it.Would it be possible to allow the tmp path to be set manually or use the
/agent/_work/temp
path instead?For now I have been able to hack around the problem by remounting the
/tmp
directory, and then reverting the change after executing Trivy.Note: we are not able to run using the docker image (our preferred option) due to encountering the same issue specified in issues #3 and #19. The work around for these issues was given as running in binary mode.
The text was updated successfully, but these errors were encountered: