Hi, >This highlights a serious concern of mine: Lots of time is being wasted >tracking down strange problems because the only place SE Linux has to >report security errors is in dmesg and the system log. The avc denial goes to the kernel audit system. It in turn decides whether to send it to the audit daemon or syslog. The audit daemon is the preferred disposition for avc messages. >When the cgi program would not produce any output at all it was not >even obvious that it was a security problem. This problem is really caused by the fact that cgi programs should not output errors or you will draw the attention of hackers. The rule of the road is that each program is responsible for reporting its own errors. >Traditionally when there is a security policy violation you get a >"permission denied" on the tty. And guess who is responsible for writing that message? Its not the kernel. >We have got to find a way to make an error appear on the tty associated >with the process that caused the violation. I think I am going to look >into setting up syslog to log all such security messages to all tty's >until I can find a better solution. A better solution is to check the return code of any OS related syscall and write the error to a log. This is what I do when I write cgi-bin apps. You can't write them to stdout or you are asking to be hacked. >But what is the better solution? I suspect that now that we have a very >granular way of specifying security policy we will need a more granular >way to report errors back to the user. tail -f /var/log/audit/audit.log will show you something in realtime. The audit daemon will be getting some event dispatcher code over the next month or two. This will help out as you could have a client app that write it to the console for you. >I am having a rather difficult time selling SE Linux in my business due >to issues like this. People really hate it when this cool new security >feature causes things to fail in dark and mysterious ways. I have been >forced to disable it on all of our machines lest we have a developer >uprising. Your problem is not really SE Linux, its that every syscall needs to have its return code checked. Your applications need to handle errors in a way that you can do post-mortum analysis. If it reports permission denied, you should take a look at file permissions and review audit events. It really is that simple. I think you can use dmesg -n xx to make syslog messages appear on the console, too. Maybe that will help in the interim? Hope this helps... -Steve Grubb __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
