4 ms·

I always thought the one-group-per-privileged-action-or-device model could have been taken farther than it was rather than diving into ACLs and capabilities (wh

I always thought the one-group-per-privileged-action-or-device model could have been taken farther than it was rather than diving into ACLs and capabilities (which IIRC OpenBSD doesn't support anyways) or the various -kits. Is it just that it's an absolute pain to administer, or is there a deeper problem lurking there?

creshal 3y ago
> or is there a deeper problem lurking there? The problem is that organizations don't want to be told by computers to just use sane and logical structures for their meatbags, they'd rather spend billions on making the computers compatible with every single deranged edge organizational case that only exists because of 20 years of unmitigated office politics and/or warfare. On the plus side, most of IT would be redundant if they ever smartened up, so let's hope they continue to wage their little wars through IT procurement.
- deltarholamda 3y ago
  Contrast that to how OpenBSD handled this. There was a thing, disk access, that shouldn't be allowed to those who could shutdown/reboot, so they bounced it around internally for a while, then de Raadt submitted a patch that said, "we're doing it this way, our users will figure it out, it's not a complex thing." No massive re-architecting, just add a group, done. Businesses could learn a lot from the way the *BSDs and Linux do things. They're all different, but you can't argue with the results.
  - nvy 3y ago
    I actually think, given how the usage share of the BSDs is a fraction of that of Linux or Windows, that OpenBSD is a textbook example of how "good enough" almost always trumps technical excellence. Linux is unquestionably less "cohesive" and "organized" than BSD but I can't think of any reason to reach for BSD given Linux exists.
    - linksnapzz 3y ago
      They find sufficient usage; even if their utility hasn't become relevant for you, yet.
      - nvy 3y ago
        Actually I used to run OpenBSD on a Thinkpad as a daily driver. Did that for work at a startup around 2010, but it was a miserable experience.
        linksnapzz 3y ago
        For laptops, I've always found the least-miserable experience is to run what the manufacturer prefers as the OS. Sad, but true (for me).
        nvy 3y ago
        Same! Though mainstream Linux distros are quite good these days, for ThinkPads and Dells
jerf 3y ago
"Is it just that it's an absolute pain to administer, or is there a deeper problem lurking there?" Deeper problem. Authorization in the general case can not be done with a set of simple textual tags. Consider sudo. A group might be able to flip on or off whether or not you have generalized sudo, but if I want Bob to be able to run these threes scripts, Betty to be able to run anything as root, and Billy to be able to run this exact script with this regular expression validating the argument, how are you going to do that with groups? Obviously, you can use groups in the solution (each of those names can be replaced with a group identifying a set of people instead of an individual name), but you can't be creating an OS-level group for every tiny fiddly permission that may exist somewhere on the system, especially in contexts where the groups are shared across an organization. Or, to put it another way, yes you could take any arbitrary policy and compile it down into a final set of tag-based permissions, but nobody would want to deal with the resulting thousands/millions of little group tags. It is technically possible but not a win on any level. For example, would you prefer an ACL that says you can access some resource during business hours, or an appearing and disappearing group tag? ACLs and capabilities may suck in some ways, but a quite significant amount of the suckage is fundamental to the problem space. As humans we just don't want to be that specific about security.
- bandrami 3y ago
  > nobody would want to deal with the resulting thousands/millions of little group tags But... you have to? You can hide it behind polkit or ACLs or capabilities or whatever but you still have to actually specify the logic. It's something I'm still annoyed about as we port a realtime application to rtkit: it's the exact same limits you used to have to establish in /etc/limits.conf but now they're in a different place. That doesn't actually simplify anything; you still have to establish the same limits.

creshal 3y ago

> or is there a deeper problem lurking there? The problem is that organizations don't want to be told by computers to just use sane and logical structures for their meatbags, they'd rather spend billions on making the computers compatible with every single deranged edge organizational case that only exists because of 20 years of unmitigated office politics and/or warfare. On the plus side, most of IT would be redundant if they ever smartened up, so let's hope they continue to wage their little wars through IT procurement.

deltarholamda 3y ago
Contrast that to how OpenBSD handled this. There was a thing, disk access, that shouldn't be allowed to those who could shutdown/reboot, so they bounced it around internally for a while, then de Raadt submitted a patch that said, "we're doing it this way, our users will figure it out, it's not a complex thing." No massive re-architecting, just add a group, done. Businesses could learn a lot from the way the *BSDs and Linux do things. They're all different, but you can't argue with the results.
- nvy 3y ago
  I actually think, given how the usage share of the BSDs is a fraction of that of Linux or Windows, that OpenBSD is a textbook example of how "good enough" almost always trumps technical excellence. Linux is unquestionably less "cohesive" and "organized" than BSD but I can't think of any reason to reach for BSD given Linux exists.
  - linksnapzz 3y ago
    They find sufficient usage; even if their utility hasn't become relevant for you, yet.
    - nvy 3y ago
      Actually I used to run OpenBSD on a Thinkpad as a daily driver. Did that for work at a startup around 2010, but it was a miserable experience.
      - linksnapzz 3y ago
        For laptops, I've always found the least-miserable experience is to run what the manufacturer prefers as the OS. Sad, but true (for me).
        nvy 3y ago
        Same! Though mainstream Linux distros are quite good these days, for ThinkPads and Dells

jerf 3y ago

"Is it just that it's an absolute pain to administer, or is there a deeper problem lurking there?" Deeper problem. Authorization in the general case can not be done with a set of simple textual tags. Consider sudo. A group might be able to flip on or off whether or not you have generalized sudo, but if I want Bob to be able to run these threes scripts, Betty to be able to run anything as root, and Billy to be able to run this exact script with this regular expression validating the argument, how are you going to do that with groups? Obviously, you can use groups in the solution (each of those names can be replaced with a group identifying a set of people instead of an individual name), but you can't be creating an OS-level group for every tiny fiddly permission that may exist somewhere on the system, especially in contexts where the groups are shared across an organization. Or, to put it another way, yes you could take any arbitrary policy and compile it down into a final set of tag-based permissions, but nobody would want to deal with the resulting thousands/millions of little group tags. It is technically possible but not a win on any level. For example, would you prefer an ACL that says you can access some resource during business hours, or an appearing and disappearing group tag? ACLs and capabilities may suck in some ways, but a quite significant amount of the suckage is fundamental to the problem space. As humans we just don't want to be that specific about security.

bandrami 3y ago
> nobody would want to deal with the resulting thousands/millions of little group tags But... you have to? You can hide it behind polkit or ACLs or capabilities or whatever but you still have to actually specify the logic. It's something I'm still annoyed about as we port a realtime application to rtkit: it's the exact same limits you used to have to establish in /etc/limits.conf but now they're in a different place. That doesn't actually simplify anything; you still have to establish the same limits.