github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #6726] profile request: gradle #3346

New issue

Closed

opened 2026-05-05 09:55:51 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 09:55:51 -06:00

Owner

Originally created by @gcb on GitHub (Apr 30, 2025).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6726

starting this outside of the main profile request issue, because i am not sure how to address gradle.

it is the most egregious entry point for a supply chain attack. and to make it worse, the common usage starts with ./gradlew which kinda can bypass anything since it starts unsandboxed.

Anyone have any ideas how to wrap this one in a practical way?

i see that scripts tries to fork either:

$JAVA_HOME/jre/sh/java
$JAVA_HOME/bin/java
maybe more?

Originally created by @gcb on GitHub (Apr 30, 2025). Original GitHub issue: https://github.com/netblue30/firejail/issues/6726 starting this outside of the main profile request issue, because i am not sure how to address gradle. it is the most egregious entry point for a supply chain attack. and to make it worse, the common usage starts with `./gradlew` which kinda can bypass anything since it starts unsandboxed. Anyone have any ideas how to wrap this one in a practical way? i see that scripts tries to fork either: - `$JAVA_HOME/jre/sh/java` - `$JAVA_HOME/bin/java` - maybe more?

gitea-mirror

2026-05-05 09:55:52 -06:00

closed this issue
added the
profile-request
label

gitea-mirror commented

2026-05-05 09:55:55 -06:00

Author

Owner

@kmk3 commented on GitHub (Apr 30, 2025):

starting this outside of the main profile request issue, because i am not
sure how to address gradle.

it is the most egregious entry point for a supply chain attack. and to make
it worse, the common usage starts with ./gradlew which kinda can bypass
anything since it starts unsandboxed.

Anyone have any ideas how to wrap this one in a practical way?

For wrapping ./gradlew:

Create a new profile normally (such as gradlew.profile) and a wrapper script,
then make sure to always remember to call the wrapper instead of ./gradlew.

Example:

~/bin/gradlew:

#!/bin/sh
exec firejail --name=gradlew --profile=gradlew ./gradlew "$@"

Run it as gradlew (instead of ./gradlew).

You could also see what ./gradlew generally does and try creating a generic
gradle wrapper (plus a firejail gradle.profile) that calls gradle without
having to run ./gradlew.

@kmk3 commented on GitHub (Apr 30, 2025): > starting this outside of the main profile request issue, because i am not > sure how to address gradle. > > it is the most egregious entry point for a supply chain attack. and to make > it worse, the common usage starts with `./gradlew` which kinda can bypass > anything since it starts unsandboxed. > > Anyone have any ideas how to wrap this one in a practical way? For wrapping `./gradlew`: Create a new profile normally (such as gradlew.profile) and a wrapper script, then make sure to always remember to call the wrapper instead of `./gradlew`. Example: ~/bin/gradlew: ```sh #!/bin/sh exec firejail --name=gradlew --profile=gradlew ./gradlew "$@" ``` Run it as `gradlew` (instead of `./gradlew`). You could also see what `./gradlew` generally does and try creating a generic gradle wrapper (plus a firejail gradle.profile) that calls `gradle` without having to run `./gradlew`.

gitea-mirror commented

2026-05-05 09:55:56 -06:00

Author

Owner

@gcb commented on GitHub (May 5, 2025):

it uses full paths for everything and that wrapper is just a list of fixed paths with a download (to local work dir!) in the end if none are found. Env paths are never used... sigh i hate hacks to work around dumb devs so much. and that is mostly the definition of {js,java}-everything.

I was hopping for something that the entire team could use (we do distribute common firejail profiles). Guess i can just overwrite the gradlew scripts and have a monitor job alert if the files change. That can take care of the repos we own but not the crap they can download from outside.

@gcb commented on GitHub (May 5, 2025): it uses full paths for everything and that wrapper is just a list of fixed paths with a download (to local work dir!) in the end if none are found. Env paths are never used... sigh i hate hacks to work around dumb devs so much. and that is mostly the definition of {js,java}-everything. I was hopping for something that the entire team could use (we do distribute common firejail profiles). Guess i can just overwrite the gradlew scripts and have a monitor job alert if the files change. That can take care of the repos we own but not the crap they can download from outside.

gitea-mirror commented

2026-05-05 09:55:57 -06:00

Author

Owner

@gcb commented on GitHub (May 19, 2025):

sigh. FYI. Found another annoyance that does the exact same thing.

/usr/bin/iex For some reason the script checks where it is, check if itself is a link, follow that link, and call elixir from the path it ultimately finds.

@gcb commented on GitHub (May 19, 2025): sigh. FYI. Found another annoyance that does the exact same thing. `/usr/bin/iex` For some reason the script checks where it is, check if itself is a link, follow that link, and call `elixir` from the path it ultimately finds.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#3346

No description provided.

Rows
Columns