4 ms·

Are you saying that the measures listed here http://hardenedbsd.org/content/easy-feature-comparison http://hardenedbsd.org/content/easy-feature-comparison do no

by cm3 10y ago

Are you saying that the measures listed here http://hardenedbsd.org/content/easy-feature-comparison http://hardenedbsd.org/content/easy-feature-comparison do not work properly?

loeg 10y ago
I'm not GP, but yes. They do not work properly and likely introduce additional vulnerabilities.
- 2trill2spill 10y ago
  Do you have any evidence for this? I've heard rumors here on HN and else where that HardenedBSD's code quality is lacking and that they didn't incorporate all the fixes and suggestions from the FreeBSD community during the various code reviews. But none of that is definitive, do you have any proof or evidence for this statement, "They do not work properly and likely introduce additional vulnerabilities."
  - loeg 10y ago
    Here's an example of poor code quality: https://github.com/HardenedBSD/secadm/commit/3dd7584b70804cf0bd3eb6f45d15b07851466ef2#diff-e4ccce5da8f7b4683a2f989b674e9d8aR80 https://github.com/HardenedBSD/secadm/commit/3dd7584b70804cf... If this check did anything, it appears susceptible to time-of-check, time-of-use attack. See also https://reviews.freebsd.org/D473 https://reviews.freebsd.org/D473 , where Shawn pretty cleary does not incorporate feedback from the FreeBSD community.
    - cm3 10y ago
      Fair enough. The more important part of my question: isn't there a focused effort to complete FreeBSD's security feature checklist?
      - loeg 10y ago
        No one is paying for completion of checkbox security features in FreeBSD. So the community is really only interested in effective mitigations and not checkbox features. We would love to merge in Konstantin's ASLR work. Reviewers have pointed out performance issues and memory fragmentation issues, especially on 32-bit platforms, but it's still better than nothing. I think we should just merge it as is, maybe default to off on 32-bit platforms, and improve from there. With the intent to have it polished for 12.0-RELEASE. One such mitigation receiving community attention is Capsicum. The Capsicum security sandbox is a viable way to constrain applications. Unlike OpenBSD's pledge, rights are limited on a file descriptor basis. It has been ported to Linux and DragonFlyBSD (although merged to neither). There has been a lot of work in FreeBSD lately to restrict base programs, especially setuid programs, using Capsicum.

by cm3 10y ago

Are you saying that the measures listed here http://hardenedbsd.org/content/easy-feature-comparison http://hardenedbsd.org/content/easy-feature-comparison do not work properly?

loeg 10y ago

I'm not GP, but yes. They do not work properly and likely introduce additional vulnerabilities.

2trill2spill 10y ago
Do you have any evidence for this? I've heard rumors here on HN and else where that HardenedBSD's code quality is lacking and that they didn't incorporate all the fixes and suggestions from the FreeBSD community during the various code reviews. But none of that is definitive, do you have any proof or evidence for this statement, "They do not work properly and likely introduce additional vulnerabilities."
- loeg 10y ago
  Here's an example of poor code quality: https://github.com/HardenedBSD/secadm/commit/3dd7584b70804cf0bd3eb6f45d15b07851466ef2#diff-e4ccce5da8f7b4683a2f989b674e9d8aR80 https://github.com/HardenedBSD/secadm/commit/3dd7584b70804cf... If this check did anything, it appears susceptible to time-of-check, time-of-use attack. See also https://reviews.freebsd.org/D473 https://reviews.freebsd.org/D473 , where Shawn pretty cleary does not incorporate feedback from the FreeBSD community.
  - cm3 10y ago
    Fair enough. The more important part of my question: isn't there a focused effort to complete FreeBSD's security feature checklist?
    - loeg 10y ago
      No one is paying for completion of checkbox security features in FreeBSD. So the community is really only interested in effective mitigations and not checkbox features. We would love to merge in Konstantin's ASLR work. Reviewers have pointed out performance issues and memory fragmentation issues, especially on 32-bit platforms, but it's still better than nothing. I think we should just merge it as is, maybe default to off on 32-bit platforms, and improve from there. With the intent to have it polished for 12.0-RELEASE. One such mitigation receiving community attention is Capsicum. The Capsicum security sandbox is a viable way to constrain applications. Unlike OpenBSD's pledge, rights are limited on a file descriptor basis. It has been ported to Linux and DragonFlyBSD (although merged to neither). There has been a lot of work in FreeBSD lately to restrict base programs, especially setuid programs, using Capsicum.