[jailcheck] Warning: I can run programs in ...

[Rosika2]

Environment

• Linux distribution and version: Lubuntu 20.04.2 LTS
• Firejail version: 0.9.66

Hi altogether,

running Linux Lubuntu 20.04.2 LTS I received my latest batch of updates yesterday, among them
firejail. So I´m on version 0.9.66 now.

I´ve learnt that there´s a new tool - jailcheck - available, which is phantastic. Thanks a lot for that.

However some programmes I run within firejail needed some tinkering with as they wouldn´t run the way they used to.

Finally I got w3m, newsboat and podboat working again.

For e.g. podboat I used the default.profile and had just to comment out "include disable-programs.inc": "#include disable-programs.inc". That way it works again.

But: when invoking the jailcheck command I get this:

4513:rosika::firejail podboat 
   Warning: AppArmor not enabled
   Virtual dirs: /var/tmp, 
   Warning: I can run programs in /home/rosika
   Warning: I can run programs in /tmp
   Warning: I can run programs in /run/user/1000
   Networking: enabled

... which got me wondering. How crucial are those warnings? Should I have done something different?

Comparing it to the results I got from "firejail firefox":

3102:rosika::firejail --private=/media/rosika/f14a27c2-0b49-4607-94ea-2e56bbf76fe1/DATEN-PARTITION/Dokumente/work2 firefox 
   Virtual dirs: /home/rosika, /tmp, /var/tmp, /dev, /usr/share, 
                 /run/user/1000, 
   Networking: enabled

I see I get no warnings here.

Could you help me somehow?

Thanks so much in advance.

Many greetings.
Rosika

[rusty-snake]

Warning: I can run programs in …

That's because default.profile does not include disbale-exec.in. You can either create a podboat.profile and add it there or/and add include disbale-exec.in to default.local (I do this).

How crucial are those warnings?

Low.

Having a whitelist profile and dbus-{user,system} (filter|none) is much more important.

Imagine an attacker can create a file in /home/rosika or /tmp containing malware and he/she can execute this file. Now, if you make this place noexec (via disable-exec.inc), he/she can no longer execute this file. However, maybe there are other directories which are writeable and don't have a noexec or the malware is written in python/perl/... or he/she has unrestricted access to the session-bus or etc. At this point you're quite lost. The only thing firejail provides here is to break the common ways how you do things so an attacker how want's to distribute his/her ransomware only cares about the 9 systems w/o firejail and ignores the one with firejail where things are complicated.

For e.g. podboat I used the default.profile and had just to comment out "include disable-programs.inc": "#include disable-programs.inc". That way it works again.

Not recommended, default.profile is already weak and commenting include disable-programs.inc. Better is to copy default.profile to podboat.profile and add a noblacklist for that paths it need access to.
Usually you find the necessary noblacklists with firejail --build podboat or firejail --noprofile --name=podboat --private podboat+firejail --join=podboat tree -a.

Or best: Copy /usr/share/doc/firejail/profile.template to podboat.profile and start writing a profile for it (and open a PR with it 😉).

when invoking the jailcheck command I get this

Just to say it, applies for jailcheck as well:

https://github.com/rusty-snake/raudit/blob/4e913ebf291bcf749d92fe6f4771ef3764d74438/docs/source/how-can-i-fix.rst?plain=1#L8-L10

[rusty-snake]

My thoughts while reading the changes, some are good and useful and some can be just ignored 🙂.

click me

How to remove specific Firejail symbolic links

If you don't want to use Firejail for a specific application […] you have to manually remove the related symbolic link after every call of firecfg:

Relevant issues:

• firecfg: allow for ignoring specific apps
• With firecfg, how do I configure specific applications to go through firejail?

Use with hardened_malloc in a custom profile.

I'm not sure about

env LD_PRELOAD='/usr/lib/libhardened_malloc.so'

but I think

env LD_PRELOAD=/usr/lib/libhardened_malloc.so

is the right syntax.

Removing the "Desktop Files" section and merging with "Using Firejail by default"

1. firecfg does not create symlinks for all program with a profile. Only programs
   in firecfg.config or with a profile in ~/.config/firejail will get firejailed.
2. firecfg --fix does not create symlinks, you still need to create symlinks.
   Maybe with firecfg --bindir=~/.local/bin.
3. firecfg has only a partial GNOME support, see firecfg dont detect all .desktop files for cleaning for example.
4. Executing firecfg --fix as root creates the fixed .desktop files in /root, it don't?
5. It does two checks, one for Exec=/abs/path and one for DBusActivable=true
6. and it does firejail.users and apparmor stuff

pacman hook: change "firecfg" to "firecfg --fix"

This looks wrong to me. Given that

Description = Configure symlinks in /usr/local/bin based on firecfg.config...

Rephrasing explanations for blacklists and whitelists, adding more explanations and examples

Deny access to a directory or file and permit everything else

It does not really permit, it just don't say anything about every other path.

Disable or undo

Maybe it makes sense to move them out so they are not in the explanation of an other command.
Instead only one "to disable/undo/ignore a black/whitelist prefix it with a no" paragraph.

must be added above

It's a virtual above because of include.
I usually say 'before', however I'm not a native english speaker.

and must add a whitelist directive

OT: We need a consistent naming, command/option/directive/flag/...

Maybe a "Note" block with whitelist restrictions makes sense. e.g.

• You can not rename a whitelisted paths, however you can rename files in a whitlisted path. (KDE apps often have immutable settings because of that)
• You can only whitelist paths that exist, use mkdir/mkfile.

Added a "Hardening Firejail" section

In general, nnp breaks any privileged program (all without nnp in it's profile are possible affected).
Notable are vbox, wireshark, chrom* with linux-hardened

restricted-network yes and firejail.users can be "suggested" here to.
firejail-welcome.sh can set both, force-nnp and restricted-network.

[curiosityseeker]

How to remove specific Firejail symbolic links

If you don't want to use Firejail for a specific application […] you have to manually remove the related symbolic link after every call of firecfg:

Relevant issues:

* [firecfg: allow for ignoring specific apps](https://github.com/netblue30/firejail/issues/2097)

* [With firecfg, how do I configure specific applications to go through firejail?](https://github.com/netblue30/firejail/issues/3665)

Yes, I have to think about how to best present it. The problem with removing the symlink is also that it will be re-added when using the pacman hook. So commenting the respective application in firecfg.configshould be added.

Use with hardened_malloc in a custom profile.

I'm not sure about

env LD_PRELOAD='/usr/lib/libhardened_malloc.so'

but I think

env LD_PRELOAD=/usr/lib/libhardened_malloc.so
``

is the right syntax.

I had tried it once and it worked.

Removing the "Desktop Files" section and merging with "Using Firejail by default"

1. `firecfg` does not create symlinks for all program with a profile. Only programs
   in firecfg.config or with a profile in `~/.config/firejail` will get firejailed.

Yes, it's mentioned in the "Note" block in that section but it's probably better to move it to the firecfg instructions.

2. `firecfg --fix` does not create symlinks, you still need to create symlinks.
   Maybe with `firecfg --bindir=~/.local/bin`.

Yes, you're right. That's definitely a problem. The correct way without sudo would be executing firecfg as root and firecfg --fix as user.

3. `firecfg` has only a partial GNOME support, see [firecfg dont detect all .desktop files for cleaning](https://github.com/netblue30/firejail/issues/2624) for example.

Thanks, I wasn't aware of that.

4. Executing `firecfg --fix` as root creates the fixed .desktop files in /root, it don't?

See above.

5. It does two checks, one for Exec=/abs/path and one for DBusActivable=true

6. and it does firejail.users and apparmor stuff

pacman hook: change "firecfg" to "firecfg --fix"

This looks wrong to me. Given that

Yes, right.

Rephrasing explanations for blacklists and whitelists, adding more explanations and examples

Deny access to a directory or file and permit everything else

It does not really permit, it just don't say anything about every other path.

Hm, yes, but don't you think that this phrasing is acceptable to illustrate the point? Any other suggestions?

Disable or undo

Maybe it makes sense to move them out so they are not in the explanation of an other command.
Instead only one "to disable/undo/ignore a black/whitelist prefix it with a no" paragraph.

I will consider this.

must be added above

It's a virtual above because of include.
I usually say 'before', however I'm not a native english speaker.

Neither am I ;-)

OT: We need a consistent naming, command/option/directive/flag/...

Yes, but I think even in the Firejail documentation there is no consistent wording, is it?

Maybe a "Note" block with whitelist restrictions makes sense. e.g.

* You can not rename a whitelisted paths, however you can rename files in a whitlisted path. (KDE apps often have immutable settings because of that)

* You can only whitelist paths that exist, use mkdir/mkfile.

I'm not quite sure that I understand what you're after ...

Added a "Hardening Firejail" section

In general, nnp breaks any privileged program (all without nnp in it's profile are possible affected).
Notable are vbox, wireshark, chrom* with linux-hardened

Yes, probably because that kernel doesn't support unprivileged user namespaces. With linux, linux-zen and linux-lts only Vitualbox seems to be affected.

restricted-network yes and firejail.users can be "suggested" here to.
firejail-welcome.sh can set both, force-nnp and restricted-network.

Thanks, I'll consider that.

Thanks a lot for your comprehensive answer! Much appreciated!

[rusty-snake]

It does not really permit, it just don't say anything about every other path.

Hm, yes, but don't you think that this phrasing is acceptable to illustrate the point? Any other suggestions?

As I said, just thoughts

OT: We need a consistent naming, command/option/directive/flag/...

Yes, but I think even in the Firejail documentation there is no consistent wording, is it?

It's missing everywhere.

I'm not quite sure that I understand what you're after ...

{{Note|<nowiki></nowiki>
* You can not rename a whitelisted paths, however you can rename files in a whitlisted path. (KDE apps often have immutable settings because of that). See issue #123456
* You can only whitelist paths that exist, use mkdir/mkfile.
}}

[curiosityseeker]

{{Note|<nowiki></nowiki>
* You can not rename a whitelisted paths, however you can rename files in a whitlisted path. (KDE apps often have immutable settings because of that). See issue #123456
* You can only whitelist paths that exist, use mkdir/mkfile.
}}

Ah, okay, I now see what you mean! But sorry - I still don't really get the first issue ... Could you, please, illustrate what it's about?

[rusty-snake]

Relevant issues: #1793 and #2874

If you have whitelist ~/.mozilla, you can not mv ~/.mozilla foo or mv foo ~/.mozilla. What you can it mv ~/.mozilla/bar foo or mv foo ~/.mozilla/bar. That's problematic if you whitelist a file and the program writes to the file by 1. create file.858674 and write to it 2. rename file.858674 to file.