And I can say this. I bought the machine, and spend hours developing code to have the function it can only have by exploiting the self-modifying code. That is the purpose of the computing device. The reason this computation exists. The purpose of the device is not to burn cycles on an watchdog that isn’t house trained.

I have been trying to get a web app installation working with SELinux on CentOS 5.4, kernel 2.6.18-164.15.1.el5.
The app has Apache httpd calling a cgi script, which in turn sends an HTTP request to another host. The latter set of an AVC denial, understandably enough. The message given was:

SELinux has denied the http daemon from connecting to itself or the relay ports. An httpd script is trying to do a network connect to an http/ftp port. If you did not setup httpd to network connections, this could signal a intrusion attempt.
Allowing Access: If you want httpd to connect to httpd/ftp ports you need to turn on the httpd_can_network_relay boolean: "setsebool -P httpd_can_network_relay=1"
The following command will allow this access:
setsebool -P httpd_can_network_relay=1


I’m impressed with the SELinux troubleshooter (now that I know about it), how it shows what was denied, why in general, and especially, what command to use to set policy to allow the needed action. In the past, these messages have helped me successfully tailor security settings to fit the needs of the app. Unfortunately in this case they don’t work. I run the setsebool command, but there is no change in behavior: SELinux continues to block the HTTP request, and continues to report the blockage, and keeps telling me to run the setsebool command. I used “getsebool httpd_can_network_relay” to verify that the setting was on, and it is; still no joy. When I set SELinux to Permissive, the problem goes away.

This sure seems like an SELinux bug. I’ve searched the web for info on the problem, with no results. I don’t see any alternative but to leave SELinux set to Permissive. Thankfully it’s an internal server so I can do that.
Any other ideas?

Here are the raw audit messages:
host=...... type=AVC msg=audit(1271177386.738:217): avc: denied { name_connect } for pid=6007 comm="webdot" dest=80 scontext=root:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket host=.... type=SYSCALL msg=audit(1271177386.738:217): arch=40000003 syscall=102 success=yes exit=0 a0=3 a1=bfd87cd0 a2=828514 a3=0 items=0 ppid=3169 pid=6007 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="webdot" exe="/usr/bin/tclsh8.4" subj=root:system_r:httpd_sys_script_t:s0 key=(null)


Look, SELinux strives to make things better, we all get it. But as the previous commentors stated, it’s just too damn clunky and complicated to get real traction with many overloaded sysadmins that have lots machines to configure and monitor and not enough time to dick around with shotty docs. Unfortunately, SELinux seems to be having the opposite of its intended effect since it ultimately contributes to insecure practices by making security too time-consuming to implement in the real world. Additionally, complicated workflows tend to invite additional problems by increasing the number of mistakes that admins make. For security packages, it’s often true that complexity=insecurity. Anyhow, that’s my two cents.

Better docs, real-world cookbook sites with user feedback, and a complete overhaul of the configuration workflow would really help quell the rebellion against SELinux.

Anybody found any sites to help?

At our company, we run all our servers with SELinux enabled and enforcing, and except for the first few times, writing policy modules for misbehaving applications has been mostly a no-brainer.

I’m a big fan of the principle of least privilege, and SELinux allows me to implement this in a granular way to protect our valuable systems and the information they contain from malicious entities on the network.

And to those that demand that SELinux should be removed from Fedora/CentOS/RHEL, I’d say In Your Dreams. SELinux is a critical part of what got RHEL5 the EAL4 certificate so that they can sell RHEL5 to government entities that require advanced security mechanisms.

There are valid points put forth by some posters though. Documentation could surely be much better, as I have found it sorely lacking. But since my employers take security very seriously (having been the victim of an intrusion seems to have that effect), I have been allowed to spend the time to figure it out, and nowadays I write custom policy modules with few issues.

I truly urge people to do as I do and rm -rf /etc/selinux

recompile a custom kernel with all hints of selinux disabled (that is till red hat wannabes taint even the kernel source by making it not compile with out their rubbish enabled).

I’m happy to admin on the command line and I in fact do so all day long, but I simply do not have time to “debug” 3 or more services per machine in our network.

Finally, any service that demands a reboot to reconfigure is so fscking out of bounds that I want nothing to do with it. I don’t sit around and develop libs. I have to maintain 100% uptime in a real world situation, because out here, where we pay taxes (not collect them), TIME is MONEY.

I spend a lot of time on security and let me share an (again) *real-world* truism with you: security mechanisms need to be usable, because if they aren’t, THEY DON’T GET USED. The real art of security is putting in place policies and systems that your user-base can live with on a daily basis.

OK, now I reboot and PRAY I’m not facing a trip to the colo.

SELinux should be EASY TO USE. Right now, it is not. It is an unmitigated disaster. Every time I install a new system, I hope and pray that things have gotten better. I try. I follow the directions. I work with the denials to try to figure out what the problem is. I read. I search on the net. And EVERY SINGLE TIME I END UP BEING FRUSTRATED AND TURN SELINUX OFF.

Total, utter disaster of a package.

Don’t make me, the naive user, learn some new arcane mechanisms. Don’t make me learn new arcane syntax (WTF is xxx:yyy:zzz:aaa? What’s the difference between a source and target context? What is a context? How am I supposed to know if program XYZ is supposed to have access to some file or resource?) Don’t give me inaccurate or incomplete instructions on how to fix the problem. Don’t make me click three times to delete an alert. Don’t make gratuitous changes to tried-and-true GUI mechanisms. Don’t make me spend cycles doing stuff that should JUST WORK.

Oh, and “click icon to view”. You have NO IDEA how many times I clicked THE ICON IN THAT ALERT, and it did nothing? Why don’t you say, CLICK THE ICON IN THE SYSTEM TRAY?

Total, unmitigated disaster. This is not even beta test grade software. It should be removed from Fedora.