mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #63] Blacklisted by default! #36
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#36
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @curiosity-seeker on GitHub (Sep 14, 2015).
Original GitHub issue: https://github.com/netblue30/firejail/issues/63
Thanks a lot for the new version, netblue30!
One suggestion: Doesn't it make sense to blacklist the various autostart folders to prevent their manipulation? Like this:
blacklist ${HOME}/.config/autostart
blacklist ${HOME}/.kde4/Autostart
blacklist ${HOME}/.kde/Autostart
Other DE's will have different autostart folders.
@netblue30 commented on GitHub (Sep 15, 2015):
This is a good idea, I'll put it in. Thanks.
@netblue30 commented on GitHub (Sep 16, 2015):
all done!
@curiosity-seeker commented on GitHub (Sep 17, 2015):
Thank you very much! The list you added in disable-common.inc is already very comprehensive. Nevertheless, after thinking a bit more about this issue and further digging in the Arch Linux wiki I think there are more candidates worth being included:
~/.kde4/share/autostart
/var/spool/cron
/var/spool/anacron
/etc/cron.*
/etc/profile.d
/etc/rc.local
/etc/anacrontab
/usr/lib/systemd
/etc/systemd
Regarding the last 2 suggestions: I've firejailed dnsmasq, and blacklisting those directories didn't hurt when I restarted dnsmasq. Nevertheless it might be sifficient to make them read-only to prevent possible breakage.
@netblue30 commented on GitHub (Sep 20, 2015):
I'll put everything in, thanks. I'll make the last two read-only. I'll keep the discussion open, in case there are more suggestions.
@ajs124 commented on GitHub (Sep 22, 2015):
How about the user specific systemd folder: ~/.local/share/systemd ?
@netblue30 commented on GitHub (Sep 22, 2015):
/usr/lib/systemd and /etc/systemd are done by default - /usr and /etc are mounted read-only. I added everything else, including ~/.local/share/systemd. Thanks!
@curiosity-seeker commented on GitHub (Sep 22, 2015):
Thank you very much, netblue30!
I have some more suggestions:
blacklist {HOME}/.wine
This should prevent the unintentional execution of Windows malware.
blacklist {HOME}/.VirtualBox
Prevent manipulation of VMs.
blacklist {HOME}/.lastpass
blacklist {HOME}/.keepassx
for disable-secret.inc. A rule like
noblacklist ${HOME}/.lastpass
would be needed for the various browser profiles, of course.
@pigmonkey commented on GitHub (Sep 22, 2015):
I'm not sure how far down the rabbit-hole of default blacklists you want to go (at some point it is easier to tell people just to use
--whitelistor--private), but pass defaults to~/.password-store. That may be worth considering if KeePass and LastPass stuff is also going to be added.@netblue30 commented on GitHub (Sep 24, 2015):
went in all profiles for media players, pdf, and bittorrent apps.
Disabled .wine in all profiles with the exception of browsers and mail clients - some users run Microsoft Silverlight under wine in browsers.
Disabled VirtualBox in everything.
@curiosity-seeker commented on GitHub (Sep 24, 2015):
Thanks, netblue30! However, wouldn't it be preferable to add the first 4 directories to disable-secret.inc and .wine to disable-common.inc and rather add noblacklist rules in the profiles where necessary?
This would make sure that those important directories are protected if the user creates own profiles for other applications without the need to remember adding those blacklist rules manually.
@netblue30 commented on GitHub (Sep 26, 2015):
It's the same thing. I did include them in the generic.profile, so by default the blacklists are always enabled.
@curiosity-seeker commented on GitHub (Sep 28, 2015):
Thanks, I see!