mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3073] Feature: post-mortem analysis #1926
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#1926
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 @topimiettinen on GitHub (Dec 4, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3073
Now, after the firejailed application has exited, Firejail just performs necessary cleanup of the file system and exits. But before doing that, it could be interesting (optionally) to see various statistics and analyze the changes which the application made on the file system:
/bin/lsthere), show changes for copied files (diff), or maybe just make the file system available for use of other tools (mount and launch a shell in the file system)SECCOMP_RET_USER_NOTIF?)Also it could be useful to be able to stop the application, do some analysis and then continue running.
@netblue30 commented on GitHub (Dec 6, 2019):
Let's do it! I moved upcoming 0.9.62 release on a separate branch for fixes only (release-0.9.62). A release is pending, probably next week. Use master branch for the development.
@topimiettinen commented on GitHub (Dec 10, 2019):
Should be actually almost doable with existing sandbox joining features. The workflow would be something like this:
(searching adds entries to .lesshst, for example "root")
Here
sudo diffand the path should be replaced with something nicer likefirejail --join=less --diff, or making also original filesystem for /home available somewhere for the shell in 1. for manual diffing.But I have some problem here (probably my configuration) that joining does not work (so 2. above is a bit fake), instead I get this error:
Strace shows this:
I've disabled
kernel.yama.ptrace_scope.Of course, the workflow in 2. could be simply to reuse the shell launched in 1. to start the app like I did. But then the sandbox contains a shell, which is not always wanted.
@netblue30 commented on GitHub (Dec 15, 2019):
I think It needs a delay, maybe the kernel didn't set up all the namespaces yet, or it didn't get a chance to update /proc filesystem?
I played a little bit with your idea of --join and put some code in main.c (look at line 151 in the file). Uncomment the line and run from a terminal:
It will start a second sandbox with a tcpdump (the code is around line 2754), it will join the network namespace of the first sandbox, and it will print the namespace traffic in the terminal. Quite funny, when I close firefox the two sandboxes are closed nicely, but tcpdump survives and it moves to systemd for a parent. Assuming we replace tcpdump with one of our programs, we can close this one also after printing whatever data we need to print on the terminal.
@smitsohu commented on GitHub (Dec 18, 2019):
Maybe we could finally add a delay to the
joinoption, as has been requested already in #2139. If it is helpful I can send a fix.For external tools one could also consider PR_SET_PDEATHSIG, which is preserved across execve.
@netblue30 commented on GitHub (Dec 21, 2019):
Yes, let's do it. I forgot about #2139!
Thanks for PR_SET_PDEATHSIG, I'll try it.
@mYnDstrEAm commented on GitHub (Jan 12, 2021):
Would be amazing if things like this could be logged.
Such logs could later and at real-time even be analyzed by intrusion detection systems. Would be especially useful if combined with other info such as of
psand syslog entries related to the running process. This could advance IDSs by associating made changes with processes and also tracking other stats (in a way that's useful).Of course one would need to make sure that the logs are short enough summaries, can't grow too large (e.g. configurable automatic moving of old logs to external media), don't take too long to create (i.e. don't prepare the log after the log after the app has exited but update the log every few minutes so even if the logging crashes there are still some logs and it'll be fast to create the complete log when it exits) and can be nicely read by other software.