Posted Jul 17, 2012 19:32 UTC (Tue) by dlang (✭ supporter ✭, #313)
[Link]
only if you are sure that you exercise every possible code path while running under strace. otherwise you run the risk of working most of the time, but failing sometimes.
Systemd gets seccomp filter support
Posted Jul 17, 2012 19:36 UTC (Tue) by felixfix (subscriber, #242)
[Link]
What if you upgrade a package which introduces new syscalls, then reboot? Bingo, boot fails. That's pretty abrupt.
Systemd gets seccomp filter support
Posted Jul 17, 2012 19:43 UTC (Tue) by mezcalero (subscriber, #45103)
[Link]
Almost no service in a systemd install actually causes the boot to fail. Basically only file system mounts can do that, and very little else.
But in general this discussion is really pointless. If you write a syscall filter list, an SELinux policy, a capabilities list, or an apparmor policy: they all have in common that you need a good idea what a specific program is allowed to do and what not. So syscall filter lists have the same "problem" as any other security technology, there is nothing new in this.
Note however that of all these techs listed above writing a syscall filter list is probably by far the easiest though since most admins probably played around with the tool for that at least once in their life: strace.
Systemd gets seccomp filter support
Posted Jul 18, 2012 19:50 UTC (Wed) by lindi (subscriber, #53135)
[Link]
strace is not ideal for passively collecting syscall usage statistics of the whole system. I personally use the following systemtap snippet: