On Tue 19 Aug 2014 05:12:31 PM CEST, Chris Adams wrote:
Once upon a time, Tomas Hozza thozza@redhat.com said:
That's where seccomp kicks in, it acts as a 2nd wall of defence. In case of a security hole being present in the server process, it goes further than a chroot, it prevents the attacker from making socket connections orexecuting his code, as his "playing field" is significantly reduced. There's very little he can do.”
How is that different from an SELinux policy? How is the additional resitrction handled (if it isn't SELinux, what mechanism is used to do the restriction)?
I'm not such expert in this field to answer your question. However by googling you can find some information about seccomp: https://wiki.mozilla.org/Security/Sandbox/Seccomp http://outflux.net/teach-seccomp/
However I would love to see some opinion and response from someone working on SELinux and security.
Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com