10 ms·

Linux has a richer set of security features available than OpenBSD, in some areas. One is the mandatory access control of SELinux, used extensively in Android

by disvor 4y ago

Linux has a richer set of security features available than OpenBSD, in some areas. One is the mandatory access control of SELinux, used extensively in Android (probably the most widely-used Linux distribution of them all). This has no OpenBSD equivalent, as far as I know. Another is that the Linux kernel has some compiled-in exploit mitigations enabled that OpenBSD doesn't, such as automatic bounds checks on fixed-size array access (based on UBSan).

dbolgheroni 4y ago
That's not true. There is pledge(2) and unveil(2) (just to start) and the whole point of them is to _make it usable_. Some Linux distros have a basic config for SELinux, but if you need to change it for anything, it's so difficult that most people just end up disabling it, thus making it less secure than a default OpenBSD install. Besides this, it changes the perspective of who is the best person to configure the secure features. OpenBSD makes this a decision for the developer of the application, who should know better about it than a random sysadmin who most probably won't even open the source code to know better (this is the approach SELinux takes). https://man.openbsd.org/pledge https://man.openbsd.org/pledge https://man.openbsd.org/unveil https://man.openbsd.org/unveil
- PrimeMcFly 4y ago
  pledge and unveil are not even close to being full alternatives to something like SELinux.
  - nix23 4y ago
    You are not wrong but also not right, it's something different. For example FreeBSD has a MAC framework (a massive one btw) and also the "SELinux/SEBSD" framework on top of it (FLASK/TE), but you don't need to use it (not on Linux nor on FBSD). OpenBSD has no MAC implementation, and with that no framework (SE*) on top of it, but has different/other way's to secure a system. And TBH i have seen just 3 Customers until now who really develop highly secure/complicated policies (Two use MLS and one uses Brewer-Nash) I think MAC should be used much more, but it's time intensive and hard to do it right, also to keep the policies clean and understandable need's LOTS of documentation and dedication. https://www.diva-portal.org/smash/get/diva2:5365/FULLTEXT01.pdf https://www.diva-portal.org/smash/get/diva2:5365/FULLTEXT01.... (2006) https://hardenedbsd.org/content/easy-feature-comparison https://hardenedbsd.org/content/easy-feature-comparison
    - Zurrrrr 4y ago
      What massive MAC framework does FreeBSD has? Last I heard SELinux was attempting to be ported (SEBSD) but that was never finished? The 'different/other/ ways to secure the system are inferior since they offer no protection if root is compromised. I don't think MAC is as hard to use as it was, there are so many policies and issues known this much later, but people still just disable it by default because they don't want to put in the time.
      - twic 4y ago
        > What massive MAC framework does FreeBSD has? Capsicum?
        Zurrrrr 4y ago
        That's capabilities, not MAC
      - nix23 4y ago
        >What massive MAC framework does FreeBSD has? That's NOT what i said, the FreeBSD MAC implementation is big and pretty much feature complete, NOT SEBSD. >The 'different/other/ ways to secure the system are inferior since they offer no protection if root is compromised. There is no such thing as "inferior" but different approaches, from completely deleting root as a user to using Container/Jail/Zones, Sandbox's, VM's etc. MAC is one of just many methods and OpenBSD voted against it and went another route (and that is totally fine and understandable). >I don't think MAC is as hard to use as it was MAC is still very hard, you are talking about SELinux that is just one implementation called FLASK/TE. Try to implement Brewer-Nash MAC-policy on a Fileserver and i will see you sweating ;) But as you can see, there is you and me (in this thread) who understand what a MAC even is, and that on HN....that just tells you how many people really have even a understanding what it even is.
        Zurrrrr 4y ago
        > That's NOT what i said, the FreeBSD MAC implementation is big and pretty much feature complete, NOT SEBSD. It is what you said. I never said you claimed SEBSD. You said FreeBSD has a massive MAC framework. I was asking which one, and the only one I know of is SEBSD, which is not at all massive. You are saying now FreeBSD has its own MAC framework, but I've never heard of it. What is it called? > There is no such thing as "inferior" but different approaches, Well that's not true. A screen door vs a heavy deadbolted door is clearly an inferior approach, not just a different approach to security, and that analogy extends to OS security technologies. MAC is the only system that can 100% protect against an attacker getting remote root. > There is no such thing as "inferior" but different approaches, I've been dealing with MAC for 20 years, so I don't find it hard at all, and if people are willing to put in the effort to learn it the reward is worth it. But this is a world where most people want to get home to watch their latest story instead of doing any kind of mental work, and admins are no different.
  - anthk 4y ago
    SeLinux it's snake oill compared to pledge an unveil. Intrinsic vs extrinsic. The first one always wins.
    - Zurrrrr 4y ago
      lol, you clearly have no clue. SELinux and other MAC systems are the only thing that can protect against a hostile actor getting remote root.
      - anthk 4y ago
        You need to get root in first place. Good luck trying to crack any pledged process running something outside it's allowed syscalls without being ABRT'd in zero time.
        Zurrrrr 4y ago
        Yeah, it's not like OpenBSD hasn't had remote root issues before... And this is exactly what I'm talking about. Putting more energy into hoping no one ever gets root rather than providing anything to protect against the scenario where it is obtained.
  - jmclnx 4y ago
    What ? You can say that, but unveil(2) will hide whole portions of any file system from a application. I do not think selinux does that (correct?). For example, firefox can only access ~/.mozilla/firefox, ~/Downloads and that is it (IIRC). There may be other directories I forgot. pledge(2) will hide system calls to prevent unintended processing. But, for the application programmer, it may be a bit harder and you need to know what you are doing. One hopes the programmer knows what he is doing :) IMHO, pledge(2) and unveil(2) is far easier to maintain than selinux, containers etc. But of course the programmer needs to code it. And not to mention, these calls are far more efficient than the multiple containers out there. (edit) I also saw somewhere a person is tring to get pledge(2) and unveil(2) into Linux, but I forgot all the details.
    - Zurrrrr 4y ago
      Hiding filesystems is security via obscurity more than anything else, and probably won't hold up if someone has root. Things like SELinux by contrast allow you to remove all access and power from the root account except for what it specifically needs, while allowing you to grant root capabilities to other accounts as needed. pledge and unveil are toys by comparison.
      - ori_b 4y ago
        > Hiding filesystems is security via obscurity more than anything else, and probably won't hold up if someone has root. Can you show me a proof of concept here?
        Zurrrrr 4y ago
        If someone has remote root you are telling me they can't unhide a filesystem? Otherwise what are you disputing and what would you accept as evidence?
        ori_b 4y ago
        > If someone has remote root you are telling me they can't unhide a filesystem? Yes. There is no mechanism at all to unmask the vnode. If you believe otherwise, I'd like to see a proof of concept.

by disvor 4y ago

dbolgheroni 4y ago

That's not true. There is pledge(2) and unveil(2) (just to start) and the whole point of them is to _make it usable_. Some Linux distros have a basic config for SELinux, but if you need to change it for anything, it's so difficult that most people just end up disabling it, thus making it less secure than a default OpenBSD install. Besides this, it changes the perspective of who is the best person to configure the secure features. OpenBSD makes this a decision for the developer of the application, who should know better about it than a random sysadmin who most probably won't even open the source code to know better (this is the approach SELinux takes). https://man.openbsd.org/pledge https://man.openbsd.org/pledge https://man.openbsd.org/unveil https://man.openbsd.org/unveil

PrimeMcFly 4y ago
pledge and unveil are not even close to being full alternatives to something like SELinux.
- nix23 4y ago
  You are not wrong but also not right, it's something different. For example FreeBSD has a MAC framework (a massive one btw) and also the "SELinux/SEBSD" framework on top of it (FLASK/TE), but you don't need to use it (not on Linux nor on FBSD). OpenBSD has no MAC implementation, and with that no framework (SE*) on top of it, but has different/other way's to secure a system. And TBH i have seen just 3 Customers until now who really develop highly secure/complicated policies (Two use MLS and one uses Brewer-Nash) I think MAC should be used much more, but it's time intensive and hard to do it right, also to keep the policies clean and understandable need's LOTS of documentation and dedication. https://www.diva-portal.org/smash/get/diva2:5365/FULLTEXT01.pdf https://www.diva-portal.org/smash/get/diva2:5365/FULLTEXT01.... (2006) https://hardenedbsd.org/content/easy-feature-comparison https://hardenedbsd.org/content/easy-feature-comparison
  - Zurrrrr 4y ago
    What massive MAC framework does FreeBSD has? Last I heard SELinux was attempting to be ported (SEBSD) but that was never finished? The 'different/other/ ways to secure the system are inferior since they offer no protection if root is compromised. I don't think MAC is as hard to use as it was, there are so many policies and issues known this much later, but people still just disable it by default because they don't want to put in the time.
    - twic 4y ago
      > What massive MAC framework does FreeBSD has? Capsicum?
      - Zurrrrr 4y ago
        That's capabilities, not MAC
    - nix23 4y ago
      >What massive MAC framework does FreeBSD has? That's NOT what i said, the FreeBSD MAC implementation is big and pretty much feature complete, NOT SEBSD. >The 'different/other/ ways to secure the system are inferior since they offer no protection if root is compromised. There is no such thing as "inferior" but different approaches, from completely deleting root as a user to using Container/Jail/Zones, Sandbox's, VM's etc. MAC is one of just many methods and OpenBSD voted against it and went another route (and that is totally fine and understandable). >I don't think MAC is as hard to use as it was MAC is still very hard, you are talking about SELinux that is just one implementation called FLASK/TE. Try to implement Brewer-Nash MAC-policy on a Fileserver and i will see you sweating ;) But as you can see, there is you and me (in this thread) who understand what a MAC even is, and that on HN....that just tells you how many people really have even a understanding what it even is.
      - Zurrrrr 4y ago
        > That's NOT what i said, the FreeBSD MAC implementation is big and pretty much feature complete, NOT SEBSD. It is what you said. I never said you claimed SEBSD. You said FreeBSD has a massive MAC framework. I was asking which one, and the only one I know of is SEBSD, which is not at all massive. You are saying now FreeBSD has its own MAC framework, but I've never heard of it. What is it called? > There is no such thing as "inferior" but different approaches, Well that's not true. A screen door vs a heavy deadbolted door is clearly an inferior approach, not just a different approach to security, and that analogy extends to OS security technologies. MAC is the only system that can 100% protect against an attacker getting remote root. > There is no such thing as "inferior" but different approaches, I've been dealing with MAC for 20 years, so I don't find it hard at all, and if people are willing to put in the effort to learn it the reward is worth it. But this is a world where most people want to get home to watch their latest story instead of doing any kind of mental work, and admins are no different.
- anthk 4y ago
  SeLinux it's snake oill compared to pledge an unveil. Intrinsic vs extrinsic. The first one always wins.
  - Zurrrrr 4y ago
    lol, you clearly have no clue. SELinux and other MAC systems are the only thing that can protect against a hostile actor getting remote root.
    - anthk 4y ago
      You need to get root in first place. Good luck trying to crack any pledged process running something outside it's allowed syscalls without being ABRT'd in zero time.
      - Zurrrrr 4y ago
        Yeah, it's not like OpenBSD hasn't had remote root issues before... And this is exactly what I'm talking about. Putting more energy into hoping no one ever gets root rather than providing anything to protect against the scenario where it is obtained.
- jmclnx 4y ago
  What ? You can say that, but unveil(2) will hide whole portions of any file system from a application. I do not think selinux does that (correct?). For example, firefox can only access ~/.mozilla/firefox, ~/Downloads and that is it (IIRC). There may be other directories I forgot. pledge(2) will hide system calls to prevent unintended processing. But, for the application programmer, it may be a bit harder and you need to know what you are doing. One hopes the programmer knows what he is doing :) IMHO, pledge(2) and unveil(2) is far easier to maintain than selinux, containers etc. But of course the programmer needs to code it. And not to mention, these calls are far more efficient than the multiple containers out there. (edit) I also saw somewhere a person is tring to get pledge(2) and unveil(2) into Linux, but I forgot all the details.
  - Zurrrrr 4y ago
    Hiding filesystems is security via obscurity more than anything else, and probably won't hold up if someone has root. Things like SELinux by contrast allow you to remove all access and power from the root account except for what it specifically needs, while allowing you to grant root capabilities to other accounts as needed. pledge and unveil are toys by comparison.
    - ori_b 4y ago
      > Hiding filesystems is security via obscurity more than anything else, and probably won't hold up if someone has root. Can you show me a proof of concept here?
      - Zurrrrr 4y ago
        If someone has remote root you are telling me they can't unhide a filesystem? Otherwise what are you disputing and what would you accept as evidence?
        ori_b 4y ago
        > If someone has remote root you are telling me they can't unhide a filesystem? Yes. There is no mechanism at all to unmask the vnode. If you believe otherwise, I'd like to see a proof of concept.