SE Linux lacks proper user notification for security violations

[Valdis.Kletnieks at vt.edu]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20050625/13922a47/attachment.bin