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.
Attachment:
pgpm4tuhASnFX.pgp
Description: PGP signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
