Reposting surprising21415's dead comment (spam filter went mad?):

> Also: https://github.com/arachsys/containers https://github.com/ghedo/pflask https://github.com/vincentbernat/jchroot https://github.com/vi/dive

> But seccomp in Firejail is a distinctive feature.

ah nice, an mbox rival.. http://pdos.csail.mit.edu/mbox/

Mbox does a lot more than this.

mbox also uses ptrace which is likely to have more impact on application performances

wow, very interesting. Thanks!

Looks like mbox doesnt use file system namespaces to isolate a process from fs, but instead combines seccomp and ptrace.

Hm, Ill try to use this to record a programs interactions with the network, tcpdump listens to _all_ the traffic and I havent found a good way yet to filter only on a certain process.

Nice! Would these tools (firejail, mbox) finally allow some user-friendly per-application firewall like Little Snitch on Linux?

Certainly!

But its not yet there, mbox is closest - as it can intercept any socket syscalls from a process, and then choose to deny based on the socket syscall arguments. Firejail could do the same, as it also has seccomp filters.

Firejail is pre-compiled with syscall filter table, but could be extended/fixed to provide those in a config file.

Hm, actually Im thinking firejail extended like this - firejailed process could be run in its own network namespace, catch any socket syscalls with a seccomp-filter, show what the process attempted to do to the user (through syslog or another daemon listening to present question to user with choice of UI), then if he denies/accepts it - run iptables -A OUTPUT -j REJECT/DROP/ACCEPT in the namespace of the process. Then save the "profile" for the process somewhere for next time it is invoked with firejail! Yes, yes, this would be quite nice!

And all of this, even the invocation of programs using firejail with their respective profiles could be automated/integrated seamlessly, with say KDE! This would be BEAUTIFUL.

This is nice for example, just firejail --seccomp --private --profile your_profile bash and then run your more-secure rtorrent "session". If rtorrent is breached, say buffer overflow/string format, the exploit would not have access to your ~. Let your rtorrent files be somewhere else than /home like /mnt/stuff.

Granted, not identical from a security perspective, but you can achieve a lot of security separation for rtorrent by simply running rtorrent under a different user-id than the one you normally use (and restricting your homedir such that only your normal user-id is allowed to browse around within it).

Yes indeed.

Firejail adds easy seccomp - right now only about 4-5 syscalls are blacklisted, but it would be gravy to specify a whitelist of syscalls and arguments on the command line to firejail.

Other security improvments to do is to run with grsecurity, or just use alpine linux - it has all binaries compiled with stack-protection position independent code.