3 ms·

Agreed - the cognitive load associated with tame is so minimal, that almost everyone gets it, and can use it, immediately. I don't think I've ever met a casual

Agreed - the cognitive load associated with tame is so minimal, that almost everyone gets it, and can use it, immediately. I don't think I've ever met a casual sysadmin who groks SELinux, and I've never met a user who understands what it's all about. Something that does 90% of the job that is used 50% of the time, is better than something that does 99% of the job and is used 1% of the time.

caf 11y ago
tame() isn't for sysadmins or users either - it has to be wired into the application by the application developer.
- batou 11y ago
  Exactly. If you isolate this as an programmer's concern then you can skip the administrative effort and assume that the application configures itself properly rather than relies on someone to experiment with producing a sandbox for it to run in. The latter is error prone hence why things like SELinux have permissive and enforcing modes. SELinux turns your job into a reverse engineering one which isn't fun. I'm slightly bitter that I've become a bit of an SELinux expert over the years. I shouldn't have to be one, hell the tech shouldn't even need to exist in 2015.
- ghshephard 11y ago
  The whole idea is that Users and SysAdmins don't have to do anything - it just works. With SELinux, the first thing that users/sysadmins do is disable it because it's screwing up their environment and annoying them.
  - chousuke 11y ago
    SELinux isn't that hard. Disabling it is just lazy. Granted, creating a really secure policy takes effort, but even just having it enabled with simple policies can help mitigate the impact of a bunch of vulnerabilities, even if it won't make you invulnerable.
    - zmyrgel 11y ago
      I spent two days trying to get selinux working with our servers and just gave up again. I have actual work to be done instead of turning the selinux knobs. Something simple as tame would be welcome, zero administrative overhead but plugs few potential security holes.
      - chousuke 11y ago
        I can't say what you were trying to do, but I've had to set up SELinux several times, and it's always been a fairly simple iterative process: 1. enable permissive mode 2. test application 3. check audit logs for any complaints 4. if no complaints, you're done. enable enforcing mode and test again. 5. otherwise, evaluate the complaints and fix the issues, either by tuning fcontexts (often, a simple path equivalency is enough if you're installing things on nondefault paths, as is common.) or by creating a custom policy module (audit2allow helps), then go to 2. It's work you should do anyway. Securing an environment is part of setting it up.
        ghshephard 11y ago
        The users/sysadmins I've known take the following process: o Run Application o Get weird error. o Google the error, see someone mentioning "This is because of SElinux" o Google how to "Disable SELinux" I'm not saying that's what they should be doing, just saying it's what I've observed. What's nice about tame is - there is nothing to enable/disable, it's just part of software.
        mhurron 11y ago
        That's pretty much the definition of lazy. Yes, its one more thing that needs to be learned but that is part of the job. > What's nice about tame is - there is nothing to enable/disable, it's just part of software. And what's nice about SELinux (if you learn it) is it applies to the system and everything running on it whether or not it's been written for it. You can even put it in a logging only, and use those logs to generate the needed policies. SELinux will tell you what is going on. What you point out as nice about tame() means that nothing will use it except what is in the core of OpenBSD.

caf 11y ago

tame() isn't for sysadmins or users either - it has to be wired into the application by the application developer.

batou 11y ago
Exactly. If you isolate this as an programmer's concern then you can skip the administrative effort and assume that the application configures itself properly rather than relies on someone to experiment with producing a sandbox for it to run in. The latter is error prone hence why things like SELinux have permissive and enforcing modes. SELinux turns your job into a reverse engineering one which isn't fun. I'm slightly bitter that I've become a bit of an SELinux expert over the years. I shouldn't have to be one, hell the tech shouldn't even need to exist in 2015.
ghshephard 11y ago
The whole idea is that Users and SysAdmins don't have to do anything - it just works. With SELinux, the first thing that users/sysadmins do is disable it because it's screwing up their environment and annoying them.
- chousuke 11y ago
  SELinux isn't that hard. Disabling it is just lazy. Granted, creating a really secure policy takes effort, but even just having it enabled with simple policies can help mitigate the impact of a bunch of vulnerabilities, even if it won't make you invulnerable.
  - zmyrgel 11y ago
    I spent two days trying to get selinux working with our servers and just gave up again. I have actual work to be done instead of turning the selinux knobs. Something simple as tame would be welcome, zero administrative overhead but plugs few potential security holes.
    - chousuke 11y ago
      I can't say what you were trying to do, but I've had to set up SELinux several times, and it's always been a fairly simple iterative process: 1. enable permissive mode 2. test application 3. check audit logs for any complaints 4. if no complaints, you're done. enable enforcing mode and test again. 5. otherwise, evaluate the complaints and fix the issues, either by tuning fcontexts (often, a simple path equivalency is enough if you're installing things on nondefault paths, as is common.) or by creating a custom policy module (audit2allow helps), then go to 2. It's work you should do anyway. Securing an environment is part of setting it up.
      - ghshephard 11y ago
        The users/sysadmins I've known take the following process: o Run Application o Get weird error. o Google the error, see someone mentioning "This is because of SElinux" o Google how to "Disable SELinux" I'm not saying that's what they should be doing, just saying it's what I've observed. What's nice about tame is - there is nothing to enable/disable, it's just part of software.
        mhurron 11y ago
        That's pretty much the definition of lazy. Yes, its one more thing that needs to be learned but that is part of the job. > What's nice about tame is - there is nothing to enable/disable, it's just part of software. And what's nice about SELinux (if you learn it) is it applies to the system and everything running on it whether or not it's been written for it. You can even put it in a logging only, and use those logs to generate the needed policies. SELinux will tell you what is going on. What you point out as nice about tame() means that nothing will use it except what is in the core of OpenBSD.