4 ms·

Grsecurity's approach is superior to OpenBSD's, but both are acceptable. FreeBSD is actually behind Linux - it lacks an effective access control framework and

by _yy 11y ago

Grsecurity's approach is superior to OpenBSD's, but both are acceptable. FreeBSD is actually behind Linux - it lacks an effective access control framework and did not have ASLR until the latest release. At least they're working on it (TrustedBSD, Capsicum).

taavi013 11y ago
FreeBSD supports Mandatory Access Control, implemented as part of the TrustedBSD project. It was introduced in FreeBSD 5.0. Since FreeBSD 7.2, MAC support is enabled by default. The framework is extensible; various MAC modules implement policies such as Biba and Multi-Level Security.
- throwaway2048 11y ago
  and how much of the system is protected by trusted bsd by default: none of it how many people ever bother to write and deploy a trustedbsd policy: (to first order approximation) nobody Defaults matter, a feature matrix checkbox is simply deceptive because the fact something isn't on (and configured) by default often means its an insane amount to work to try to enable it and/or thing are unfixably broken when you do (from a user point of view) unfortunately both these things are true of trustedBSD
  - emidln 11y ago
    The TrustedBSD features are used by appliance vendors who base their product on FreeBSD. Applicances have very narrow profiles of acceptable use and thus it's actually sane to develop policies for them.
    - nickpsecurity 11y ago
      That's true. It goes back further than TrustedBSD: Secure Computing Corporation invented Type Enforcement, put it in a high assurance system (LOCK), put it into a BSD-OS for a firewall (Sidewinder firewall), and helped create Flask architecture for integration of type enforcement into vanilla OS's. Flask was ported to Linux in SELinux project. That got enough acceptance that TrustedBSD project was started to do same for FreeBSD. So, full circle back the the OS the tech was first fielded on. LOCK System http://www.cyberdefenseagency.com/publications/LOCK-An_Historical_Perspective.pdf http://www.cyberdefenseagency.com/publications/LOCK-An_Histo... Sidewinder firewall http://www.ittoday.info/AIMS/DSM/83-10-35.pdf http://www.ittoday.info/AIMS/DSM/83-10-35.pdf Flask project/architecture https://www.cs.utah.edu/flux/fluke/html/flask.html https://www.cs.utah.edu/flux/fluke/html/flask.html Nonetheless, the old stuff (esp LOCK & LOCK/ix) are still stronger in security architecture and design despite all these years. Good design is timeless I guess. :) Note: Cambridge's CHERI project and CheriBSD are the cutting-edge for FreeBSD security as they do capability-security from hardware up with FreeBSD already ported. Also supports Capsicum, Flask, and separation kernels if one wanted. True integration of each major branch of INFOSEC. :) https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
  - nickpsecurity 11y ago
    Sounds like a demand problem rather than a FreeBSD problem. I've heard the same about SELinux etc with them overly permissive by default due to user apathy. I'd say Linux is ahead of usability of these controls, even supported by vendors like Tresys. It's also ahead in terms of risky code/tools a major distribution will support vs a major BSD. So, comparisons are a moving target. Fortunately, the best security approaches (HW-centric) are portable to both w/ FreeBSD getting most prototypes. You can already run capability-secure FreeBSD via Cambridge CHERI project. Criswell's people are doing lots of stuff with FreeBSD and maybe Linux: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://sva.cs.illinois.edu/pubs.html http://sva.cs.illinois.edu/pubs.html Examples for Linux include these: http://scholar.lib.vt.edu/theses/available/etd-10112006-204811/unrestricted/edmison_joshua_dissertation.pdf http://scholar.lib.vt.edu/theses/available/etd-10112006-2048... https://web.archive.org/web/20120509155852/http://archives.ece.iastate.edu/archive/00000561/01/thesis.pdf https://web.archive.org/web/20120509155852/http://archives.e... https://docs.google.com/file/d/0B1i_Zf52vJctMTA4YTI1MmUtNzdjNC00ZDRmLTlhYTItYjM0YjhlNGE2MzUz/edit?hl=en&pli=1 https://docs.google.com/file/d/0B1i_Zf52vJctMTA4YTI1MmUtNzdj... That doesn't even include software-related techniques like microkernels, low TCB software, safe low-level languages, and automatic compiler transformations for security that neither are adopting. They're both low-medium assurance by my standards due to cultural refusal to apply what's proven to work. So, I already have predictions about tech-transfer of papers above to Linux/FreeBSD use at large. You can probably guess how optimistic I am. ;)
hiphopyo 11y ago
Some interesting insights on Grsecurity's approach by OpenBSD's Nick Holland in the comments section: https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-1-basic-concepts https://www.digitalocean.com/community/tutorials/an-introduc...
- j_s 11y ago
  Link directly to the comment: https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-1-basic-concepts?comment=17853 https://www.digitalocean.com/community/tutorials/an-introduc... And here is the referenced email with a bit of context: http://osdir.com/ml/general/2014-02/msg44493.html http://osdir.com/ml/general/2014-02/msg44493.html
- aidenn0 11y ago
  Substitute "Untrusted user" for "possibly buggy server code" and you will see why Grsecurity's approach can have value in single-user systems.
- _yy 11y ago
  He's actually talking about the SELinux/"RBAC in general" approach. His only criticism of Grsecurity is that it's not in the mainline and therefore not as effective as it could be.
geraldcombs 11y ago
MinGW-w64 also lacks ASLR and DEP. As a result most FOSS Windows packages lack them as well: https://sourceware.org/bugzilla/show_bug.cgi?id=19011 https://sourceware.org/bugzilla/show_bug.cgi?id=19011

by _yy 11y ago

taavi013 11y ago

FreeBSD supports Mandatory Access Control, implemented as part of the TrustedBSD project. It was introduced in FreeBSD 5.0. Since FreeBSD 7.2, MAC support is enabled by default. The framework is extensible; various MAC modules implement policies such as Biba and Multi-Level Security.

throwaway2048 11y ago
and how much of the system is protected by trusted bsd by default: none of it how many people ever bother to write and deploy a trustedbsd policy: (to first order approximation) nobody Defaults matter, a feature matrix checkbox is simply deceptive because the fact something isn't on (and configured) by default often means its an insane amount to work to try to enable it and/or thing are unfixably broken when you do (from a user point of view) unfortunately both these things are true of trustedBSD
- emidln 11y ago
  The TrustedBSD features are used by appliance vendors who base their product on FreeBSD. Applicances have very narrow profiles of acceptable use and thus it's actually sane to develop policies for them.
  - nickpsecurity 11y ago
    That's true. It goes back further than TrustedBSD: Secure Computing Corporation invented Type Enforcement, put it in a high assurance system (LOCK), put it into a BSD-OS for a firewall (Sidewinder firewall), and helped create Flask architecture for integration of type enforcement into vanilla OS's. Flask was ported to Linux in SELinux project. That got enough acceptance that TrustedBSD project was started to do same for FreeBSD. So, full circle back the the OS the tech was first fielded on. LOCK System http://www.cyberdefenseagency.com/publications/LOCK-An_Historical_Perspective.pdf http://www.cyberdefenseagency.com/publications/LOCK-An_Histo... Sidewinder firewall http://www.ittoday.info/AIMS/DSM/83-10-35.pdf http://www.ittoday.info/AIMS/DSM/83-10-35.pdf Flask project/architecture https://www.cs.utah.edu/flux/fluke/html/flask.html https://www.cs.utah.edu/flux/fluke/html/flask.html Nonetheless, the old stuff (esp LOCK & LOCK/ix) are still stronger in security architecture and design despite all these years. Good design is timeless I guess. :) Note: Cambridge's CHERI project and CheriBSD are the cutting-edge for FreeBSD security as they do capability-security from hardware up with FreeBSD already ported. Also supports Capsicum, Flask, and separation kernels if one wanted. True integration of each major branch of INFOSEC. :) https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
- nickpsecurity 11y ago
  Sounds like a demand problem rather than a FreeBSD problem. I've heard the same about SELinux etc with them overly permissive by default due to user apathy. I'd say Linux is ahead of usability of these controls, even supported by vendors like Tresys. It's also ahead in terms of risky code/tools a major distribution will support vs a major BSD. So, comparisons are a moving target. Fortunately, the best security approaches (HW-centric) are portable to both w/ FreeBSD getting most prototypes. You can already run capability-secure FreeBSD via Cambridge CHERI project. Criswell's people are doing lots of stuff with FreeBSD and maybe Linux: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://sva.cs.illinois.edu/pubs.html http://sva.cs.illinois.edu/pubs.html Examples for Linux include these: http://scholar.lib.vt.edu/theses/available/etd-10112006-204811/unrestricted/edmison_joshua_dissertation.pdf http://scholar.lib.vt.edu/theses/available/etd-10112006-2048... https://web.archive.org/web/20120509155852/http://archives.ece.iastate.edu/archive/00000561/01/thesis.pdf https://web.archive.org/web/20120509155852/http://archives.e... https://docs.google.com/file/d/0B1i_Zf52vJctMTA4YTI1MmUtNzdjNC00ZDRmLTlhYTItYjM0YjhlNGE2MzUz/edit?hl=en&pli=1 https://docs.google.com/file/d/0B1i_Zf52vJctMTA4YTI1MmUtNzdj... That doesn't even include software-related techniques like microkernels, low TCB software, safe low-level languages, and automatic compiler transformations for security that neither are adopting. They're both low-medium assurance by my standards due to cultural refusal to apply what's proven to work. So, I already have predictions about tech-transfer of papers above to Linux/FreeBSD use at large. You can probably guess how optimistic I am. ;)

hiphopyo 11y ago

Some interesting insights on Grsecurity's approach by OpenBSD's Nick Holland in the comments section: https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-1-basic-concepts https://www.digitalocean.com/community/tutorials/an-introduc...

j_s 11y ago
Link directly to the comment: https://www.digitalocean.com/community/tutorials/an-introduction-to-selinux-on-centos-7-part-1-basic-concepts?comment=17853 https://www.digitalocean.com/community/tutorials/an-introduc... And here is the referenced email with a bit of context: http://osdir.com/ml/general/2014-02/msg44493.html http://osdir.com/ml/general/2014-02/msg44493.html
aidenn0 11y ago
Substitute "Untrusted user" for "possibly buggy server code" and you will see why Grsecurity's approach can have value in single-user systems.
_yy 11y ago
He's actually talking about the SELinux/"RBAC in general" approach. His only criticism of Grsecurity is that it's not in the mainline and therefore not as effective as it could be.

geraldcombs 11y ago

MinGW-w64 also lacks ASLR and DEP. As a result most FOSS Windows packages lack them as well: https://sourceware.org/bugzilla/show_bug.cgi?id=19011 https://sourceware.org/bugzilla/show_bug.cgi?id=19011