On Tue 19 Aug 2014 05:12:31 PM CEST, Chris Adams wrote: > Once upon a time, Tomas Hozza <tho...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
