I certainly wasn't saying that one *replaces* the other. However it's *perfectly* valid to compare the *tradeoffs* between them.
You even do it yourself in the second paragraph:
"This stuff is useful in a few cases however which SELinux doesn't really cover: it's trivial to write for admins,"
I think "trivial to write for admins" is less true than you think. And of those issues are the same reasons that writing SELinux policy is hard; version skew of the "app" and the underlying system, delta between tested configuration and deployment, etc.
Posted Jul 17, 2012 19:56 UTC (Tue) by mezcalero (subscriber, #45103)
[Link]
Well, I think it's much easier to write syscall filter lists for the simple reason that everybody knows the main tool for doing that: strace. And what's also nice is that it allows you to write blacklists too, which adds a bit of security, and is super duper easy to do:
And that's all yoou need to make sure that your process doesn't get access to any IO port or can change the time.
Systemd gets seccomp filter support
Posted Jul 17, 2012 21:46 UTC (Tue) by jimparis (subscriber, #38647)
[Link]
Until you remember that iopl() also gives access to IO ports, and direct memory access makes it easy enough to change the time. I don't think blacklists can ever realistically work.
Systemd gets seccomp filter support
Posted Jul 18, 2012 2:21 UTC (Wed) by jcm (subscriber, #18262)
[Link]
Just a note here. "Everybody" is "one who is skilled in the art" (of computer programming on Unix and Linux systems). That isn't most sysadmins. It's perhaps most sysadmins I hang out with, but it's not most out there. The idea of sysadmins writing system call filters terrifies me from a support perspective :)
Systemd gets seccomp filter support
Posted Jul 18, 2012 17:55 UTC (Wed) by cmccabe (guest, #60281)
[Link]
Yeah, I thought the whole idea behind seccomp was that developers would add sandboxing to their own programs. Adding it as yet another sysadmin-configurable knob seems like exactly the wrong direction to go.