-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello.
ISC is working on new BIND 9.10 release which includes the seccomp functionality. It can be turned on by configuring BIND before build with "--enable-seccomp".
ISC asked me to kindly ask Fedora community if they would be willing to test it. Currently I'm working on rebasing BIND to 9.10 in rawhide. However it is still not finished. Since DHCP (including dhclient) depends on BIND libraries I'm not able to easily provide a testing RPMs that would be installable.
In the future I would like to turn the feature on by default.
So if you are willing to test the feature, you can download latest BIND 9.10.1b2 on http://www.isc.org/downloads/
Configure it with "--enable-seccomp" and you're good to go.
You can send your feedback to bind-beta-response@lists.isc.org, bind-users@lists.isc.org or bind-bugs@isc.org
Some words about the feature from the contributor: "It goes further than a chroot. chroot limits an attacker to a filesystem. it doesn't prevent the attacker from running his "exploit" aka nefarious code and making socket connections over the internet that would give him some kind of backdoor access where he can remotely execute his code.
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.”
Thank you.
Regards, - -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com
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)?
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
On Tue, Aug 19, 2014 at 10:12:31AM -0500, 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)?
The mechanism is called ”seccomp” – http://en.wikipedia.org/wiki/Seccomp
On 08/19/2014 11:20 AM, Tomasz Torcz wrote:
On Tue, Aug 19, 2014 at 10:12:31AM -0500, 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)?
The mechanism is called ”seccomp” – http://en.wikipedia.org/wiki/Seccomp
Seccomp can add additional security features to SELinux by eliminating certain syscalls. I think using both SELinux and seccomp is a good idea. Security in Depth.
Il 19/Ago/2014 17:10 "Tomas Hozza" thozza@redhat.com ha scritto:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello.
ISC is working on new BIND 9.10 release which includes the seccomp functionality. It can be turned on by configuring BIND before build with "--enable-seccomp".
ISC asked me to kindly ask Fedora community if they would be willing to test it. Currently I'm working on rebasing BIND to 9.10 in rawhide. However it is still not finished. Since DHCP (including dhclient) depends on BIND libraries I'm not able to easily provide a testing RPMs that would be installable.
In the future I would like to turn the feature on by default.
So if you are willing to test the feature, you can download latest BIND 9.10.1b2 on http://www.isc.org/downloads/
Configure it with "--enable-seccomp" and you're good to go.
You can send your feedback to bind-beta-response@lists.isc.org, bind-users@lists.isc.org or bind-bugs@isc.org
Some words about the feature from the contributor: "It goes further than a chroot. chroot limits an attacker to a filesystem. it doesn't prevent the attacker from running his "exploit" aka nefarious code and making socket connections over the internet that would give him some kind of backdoor access where he can remotely execute his code.
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.”
Are there some duplication of security feature that some mac system offer as selinux, in first place ? Sure someone can Tell that selinux could be disabled by the lazy sysadmin.
Thanks
Best regards
Thank you.
Regards,
Tomas Hozza Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEcBAEBAgAGBQJT82i/AAoJEMWIetUdnzwtooYH/1hffLhpDtY1zTPNVtSlFLUx 236mJQGZMS5jsHAKPtd354qLCSMSIBTEeeGPCUkV9YC3ZtrF+wT6FCN1XFgDylpr 7S2toCAVOpjbPIUIOJZ8HvRZENb//KGxUHg8GrlIfHZMeXB9EXhvaTcxLC1QTX04 JSZyQKXIaDWurTGM/AQESAwHkIWK1vaubmrI2dt8L0mp9e5RWc3N/sb5XAup0jfa zfkP/oPsmeS6mZvKdoc/BiwDDj8bLm8NBLHFO++tES0e43HnWAo9+H4HqSNuX5JQ 0q4a11zy55VtL8G99kzGN64gdvtXbiNDVuxulecWxxK9BUncHv3aXu5t4ggO0yg= =MtKc
-----END PGP SIGNATURE-----
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-
Chris Adams -
Daniel J Walsh -
devzero2000 -
Tomas Hozza -
Tomasz Torcz