Hacker News Reader

Comment by laurent123456 | Hacker News Reader

> Jan 31 10:48:54 server audit[16067]: AVC avc: denied { name_connect } for pid=16067 comm="nginx" dest=8000 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:transproxy_port_t:s0 tclass=tcp_socket permissive=0

I think one reason security programs are sometime ineffective and end up being disabled is that they give problems to developers and sysadmin but no solutions.

I wish that rather than messages like "doesn't work - too bad", these programs would output a solution as well, such as "consider setting `httpd_can_network_connect` to `true` to allow it".

In some cases it might be tricky to propose a solution, in which case even a link to the doc would be useful like "check http://example.com/doc#456 for more information". That would go a long way towards making security software issues less of a pain for those who aren't expert in the topic.

View on HN

"audit2allow -a" or "audit2why" will tell you what the reason for a denial is and potentially how to fix it. Pretty sure it will tell you to run setsebool to allow httpd_can_network_connect in this instance.

audit2allow is the single greatest tool I've ever used for dealing with SELinux, people need to hear it's name sung from the mountains.

I actually write SELinux policies for software I develop, first thing I do is put them in the most restrictive context imaginable with no permissions, set SELinux in permissive mode and run the application through it's paces, at the end run audit2allow and there's 90% of the work done for you outside of defining fcontext's.

It must be used with care though, otherwise you'll end up with so many holes in your policy that you defeat whole point of using SELinux in the first place. Definitely don't use the output directly.

Certainly not, but it's a great first step.

This is doubly annoying when you're on a fresh install of some distro (in my case, Fedora) and it just starts whinging about files and services you've never heard of, before I've had a chance to do anything with the system.

"This service did the bad thing, supposedly", ok, so what am I supposed to do with that? Is the service at fault? or is the default SElinux config borked? or both?

If the answer is actually "no that's fine", then why am I being alerted about it?

This is exactly why setroubleshootd exists. It literally does what you suggest :-)

Learning .Net now and this is one of the things that that I like about it: sometimes the error messages is a lot clearer and sometimes they include suggested solutions.

Perhaps the SELinux rules should be included together with the package?

This is a great idea and reminiscent of LLVM to me...

Reply on news.ycombinator.com