| |||||||||||||
Systemd gets seccomp filter supportSystemd gets seccomp filter supportPosted Jul 17, 2012 19:36 UTC (Tue) by mezcalero (subscriber, #45103)In reply to: Systemd gets seccomp filter support by walters Parent article: Systemd gets seccomp filter support
The sycall filter thingy is not in any way comparable with SELinux, and systemd tightly integrates with SELinux as well.
Please don't think that the syscall filter thingy is intended to replace SELinux in any way. Syscall filtering is hardly comparable to what you can express with SELinux policy. This stuff is useful in a few cases however which SELinux doesn't really cover: it's trivial to write for admins, without the need to get the SELinux policy rebuilt and updated, third party software can easily make of this to lock itself down, and it works fine even in systemd user instances, i.e. to lock down individual user services or apps without any system policy updates.
So, if anybody tries to compare this with SELinux, then you are comparing apples and oranges and assuming that there was competition in something where there is no competition.
(Log in to post comments)
Systemd gets seccomp filter support Posted Jul 17, 2012 19:43 UTC (Tue) by walters (subscriber, #7396) [Link]
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.
Systemd gets seccomp filter support 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:
SystemCallFilter=~ioperm settimeofday clock_settime
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.
|
|||||||||||||