SE Linux lacks proper user notification for security violations

[Tracy Reed]

-----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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCvRRn9PIYKZYVAq0RAvsvAJ4xRlOfEIcgYPPoVwEKOuRqOr6z7QCfQvcm
> XVkZUwoM8+2ot0Neg15RkYA=
> =W6Qq
> -----END PGP SIGNATURE-----

[Steve G]

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.

[Stephen Smalley]

On Sat, 2005-06-25 at 09:21 -0400, Valdis.Kletnieks(a)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).

-- 
Stephen Smalley
National Security Agency