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)?