-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all!
Yesterday I ran into a very odd problem which I think highlights a serious weakness in the current selinux implementation. A newbie linux/web developer was testing a perl based cgi on his fedora box. If he put the cgi progran in /var/www/cgi-bin it would not produce any output nor error messages. It just seemed to exit. If he ran it from his ~/ it produced the expected output. It took me a good 15 min of scratching my head over this before I realized this must be an selinux thing due to the context of the cgi-bin dir and of course I was right.
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. When the cgi program would not produce any output at all it was not even obvious that it was a security problem. This is not acceptable for general use. My users won't think to check the system log for possible security policy violations relating to their activities and even I often forget to do it because security policy violation is often not the first thing that comes to my mind when something like this happens. And even if we do think of it, we should not have to go check the logs every time something odd happens suspecting SE Linux. It should be immediately obvious.
Traditionally when there is a security policy violation you get a "permission denied" on the tty. 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.
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.
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.
- -- Tracy R Reed http://ultraviolet.org
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
On Sat, 25 Jun 2005 15:23:04 +0700, Tracy R Reed said:
Yesterday I ran into a very odd problem which I think highlights a serious weakness in the current selinux implementation. A newbie linux/web developer was testing a perl based cgi on his fedora box
This isn't a serious weakness in SELinux. This is a serious weakness in the way you train your newbie developers.
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.
And where *else* is your Apache supposed to write things, besides the various system log files? ;)
Traditionally when there is a security policy violation you get a "permission denied" on the tty. 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.
If you're not getting a "permission denied", that means that *your* code failed to check the return code of a syscall and call perror() (or language equivalent) if needed.
Don't blame SELinux for your failure to write correct code. What would you have wanted the system to do at that same line of code, if the rejection was due to the file being chmod'ed or chown/chgrp to the wrong value?
Just as an aside: You want "make an error appear on the tty associated". Now think this through - if the problem had been the *reverse* (works when run from ~/, but fails when it's in the system cgi-bin and called by Apache), where exactly is the "associated TTY"? Hand the error message back to the browser of the attacker in some eastern European country? How smart is *that*? ;)
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.
Better solution:
1) Tell your programmers to (a) test the return values of system calls and (b) *call perror() if something fails*. Remember - "permission denied" messages come from *your program*, not the system.
2) If you get "permission denied", the traditional solution has been to do an 'ls -l' of the target and ponder the mode/uid/gid. Replace that with: do an 'ls -lZ' of the target and ponder the mode/uid/gid/context.
For your newbie Perl programmers, the proper solution is to replace all your:
open (FOO, $file);
with open (FOO, $file) || die "Failed trying to open $file - $!, stopped";
If 'die' is too heavy-weight, at least use 'warn'.
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.
Developers riot when forced to write proper code. Film at 11.
Unfortunately, if your organization has decided that letting the coders write slack code is more important than security, SELinux is probably the wrong choice for you, and both you and us are probably better off if you don't use it.
There's no amount of magic pixie dust we can sprinkle over SELinux to make it do proper security on systems where programmers are writing code that doesn't even bother checking return codes. Unfortunately, that's true of *any* security system.
On Sat, 2005-06-25 at 09:21 -0400, Valdis.Kletnieks@vt.edu wrote:
If you're not getting a "permission denied", that means that *your* code failed to check the return code of a syscall and call perror() (or language equivalent) if needed.
To be fair, SELinux will sometimes prevent such error reporting by the application because it will have already closed stdin/stdout/stderr and re-opened them to the null device due to a policy denial on the inherited descriptor at exec time (upon a domain change). Hence, the only safe approach is to log such error reports to a log file (and naturally, to ensure that the application has the necessary permissions to append to the log file).
selinux@lists.fedoraproject.org
-
Stephen Smalley -
Steve G -
Tracy Reed -
Valdis.Kletnieks＠vt.edu