3 ms·

The fix for that would have been: setsebool httpd_can_network_connect=1 audit2allow even tells you right away which booleans apply: tail /var/log/aud

by lima 10y ago

The fix for that would have been: setsebool httpd_can_network_connect=1 audit2allow even tells you right away which booleans apply: tail /var/log/audit.log | audit2allow

simias 10y ago
Thank you for that, that might be helpful in the future! But it kinds of demonstrate my problem with SELinux: when I had my unix socket issue I tried to debug my problem using my usual tools: strace, ls, ps, dmesg, etc... but I couldn't figure out what wasn't working right. All the permissions looked fine and yet I kept getting cryptic failures. With something like a jail, once it's set up I can just use my un*x admin experience without having to learn a brand new OS-specific (if not distribution-specific) set of tools.
- lima 10y ago
  Well, you get that with any security technology and it's just one of many things to be aware of when you use another distribution.
  - clarry 10y ago
    Well, you get that with any security technology That's just not true. There is plenty of security technology that doesn't require you to figure out new tools. There is security technology that doesn't have tools at all and there is nothing to figure out. The program either works correctly or it's buggy and there is no knob to make a buggy program correct. And then there is security technology that is more or less understandable with knowledge of existing Unix tools. pledge() on OpenBSD, for instance, doesn't introduce new fancy tools. A program doing something it promised not to do will get killed with abort trap (which can, admittedly, be a little cryptic if you don't know pledge does that). In addition, the name of the binary, the pid, and the offending syscall is printed in dmesg. Perhaps it would be better still if the dmesg line included the word "pledge" as a hint & guarantee that you'd get relevant results on Google.
    - lima 10y ago
      Well, "security technology" in the context of mandatory access control frameworks. Bad choice of words. My point is that any ACL framework will require configuration, be it SELinux, AppArmor, Tomoyo, or pledge. If you want to use pledge to confine applications that don't use the pledge API, it will get complicated, too (admittedly not quite as complicated as SELinux, but still). SELinux writes denials to the audit log and you get plenty of relevant results. pledge is obviously much more sane than SELinux, but someone has to write a policy no matter what technology is used.
tomaac 10y ago
This is non-persistent and after reboot this seboolean will be set back to 0. You must use -P flag to make it persistent.
- lima 10y ago
  You right, of course. Thanks for noting it! Too late to edit.

by lima 10y ago

The fix for that would have been: setsebool httpd_can_network_connect=1 audit2allow even tells you right away which booleans apply: tail /var/log/audit.log | audit2allow

simias 10y ago

Thank you for that, that might be helpful in the future! But it kinds of demonstrate my problem with SELinux: when I had my unix socket issue I tried to debug my problem using my usual tools: strace, ls, ps, dmesg, etc... but I couldn't figure out what wasn't working right. All the permissions looked fine and yet I kept getting cryptic failures. With something like a jail, once it's set up I can just use my un*x admin experience without having to learn a brand new OS-specific (if not distribution-specific) set of tools.

lima 10y ago
Well, you get that with any security technology and it's just one of many things to be aware of when you use another distribution.
- clarry 10y ago
  Well, you get that with any security technology That's just not true. There is plenty of security technology that doesn't require you to figure out new tools. There is security technology that doesn't have tools at all and there is nothing to figure out. The program either works correctly or it's buggy and there is no knob to make a buggy program correct. And then there is security technology that is more or less understandable with knowledge of existing Unix tools. pledge() on OpenBSD, for instance, doesn't introduce new fancy tools. A program doing something it promised not to do will get killed with abort trap (which can, admittedly, be a little cryptic if you don't know pledge does that). In addition, the name of the binary, the pid, and the offending syscall is printed in dmesg. Perhaps it would be better still if the dmesg line included the word "pledge" as a hint & guarantee that you'd get relevant results on Google.
  - lima 10y ago
    Well, "security technology" in the context of mandatory access control frameworks. Bad choice of words. My point is that any ACL framework will require configuration, be it SELinux, AppArmor, Tomoyo, or pledge. If you want to use pledge to confine applications that don't use the pledge API, it will get complicated, too (admittedly not quite as complicated as SELinux, but still). SELinux writes denials to the audit log and you get plenty of relevant results. pledge is obviously much more sane than SELinux, but someone has to write a policy no matter what technology is used.

tomaac 10y ago

This is non-persistent and after reboot this seboolean will be set back to 0. You must use -P flag to make it persistent.

lima 10y ago
You right, of course. Thanks for noting it! Too late to edit.