Open QUser534 opened 2 months ago
There is one thing you have to consider. globals.local
is usually included at the top (after foo.local
). Meaning ?HAS_NET:
will be false in 99% for the times you reach it in globals.local
.
Also ?HAS_NET:
will be true once net
is used, right? Be it net none
or net eth0
.
?HAS_NET
I want to create very restrictive sandbox when net is enabled because the biggest risk is stealing private data. If net is NOT enabled, then I would like to have a looser profile that enables more data access.
I'm happy to see that you have a more real world thread model than "I want to protect root because it is the user with the highest privileges". But keep in mind that a looser profile might allow data stealing thought other means than direct networking.
negative conditionals
workaround:
?HAS_NET: include super-restrictive-rules.inc
?HAS_NET: ignore include looser-rules.inc
include looser-rules.inc
?!HAS_NET:
Should be easy to implement, copy HAS_NET and negate the condition.
But keep in mind that a looser profile might allow data stealing thought other means than direct networking.
I am not a security expert, so would you mind elaborating a malicious app could steal data if it's networking is disabled? Is there an easy way to break out of the network jail so it can upload data to a remote server?
Or would it require some type of user action, such as the program with no net-access modifies another program that it hopes will be run unsandboxed (such as modifying the .profile file), so then that program can upload the data?
There is one thing you have to consider.
globals.local
is usually included at the top (afterfoo.local
). Meaning?HAS_NET:
will be false in 99% for the times you reach it inglobals.local
.
Hmmm, I see what you mean that for most people that would be the case. I modified it so firejail is always run with firejail --net=none
, so in this case it would be aware of when to include each profile (even if the profile itself will disable net later that is okay).
Another way to do this that is perhaps more generalizable
1) Make it so ?CONDITION
can utilize include
directive
2) Make "conditions" passable via command line switches: --conditional="foo=1" --conditional="bar=1"
Then, allow these to be conditionals. For example:
?HAS_XXX:
where XXX is the passed flag, in this case ?HAS_FOO
and ?HAS_BAR
This resolves the issue of these "flags" not being known.
Then, users can pass a flag. This is especially important when wanting to use the "default" program on a new program.
For example:
firejail --conditional="net=0" --conditional="personal=0" --conditional="images=1"
Then the conditions the user created would include whatever was needed based on the flag data they passed.
What do you think about this idea?
The concept of user-defineable conditionals seems useful even without "include" directive support. Should it be made into a separate feature enhancement for tracking?
In general, some conditionals could be useful even for standard profiles. For example: paranoid=1
Currently, many profiles enable net access for example to not break some very rarely used feature. So, basically net access was enabled for a feature 1% of people use like maybe a music program uses it to fetch lyrics on request as an example. Expanded use of conditions could allow profiles to be written to have more aggressive profiles when it's okay if the program works 99% instead of 100%.
Or would it require some type of user action, such as the program with no net-access modifies another program that it hopes will be run unsandboxed (such as modifying the .profile file), so then that program can upload the data?
Yes, anything in that direction.
?HAS_XXX:
I somewhere suggested a ?HAS(...)
but I can not find it anymore.
--conditional
If you already need to construct a firejail cmd, you can simply add the wanted includes. Conditionals an interesting for the firecfg case where you don't have a firejail cmd.
Is your feature request related to a problem? Please describe.
I want to create very restrictive sandbox when net is enabled because the biggest risk is stealing private data. If net is NOT enabled, then I would like to have a looser profile that enables more data access.
In addition, support of negative conditionals.
Describe the solution you'd like
Describe alternatives you've considered
Nothing as clean as this. Currently I have to use a loader script to load different profiles. Would be much easier to be able to add a conditional to global.inc to make software-wide.
I looked at #2158 and could not see any real reason why
include
was excluded.