Re: Making SELinux standard for etch
Manoj Srivastava writes ("Making SELinux standard for etch"):
> We are at a point where we can support a targeted SELinux
> policy, at least in permissive mode. Everything seems to work for
> me; I can fire up targeted SELinux UML's and only see a few harmless
> log messages.
I am deeply uninspired with the SELinux approach to security. I think
SELinux is the wrong answer to the problem it is being touted to
tackle and we should be thinking about dropping it, rather than
deploying it (even after an explicit choice).
The basic approach seems to be to try to deal with complex protocols,
resulting in buggy applications, by introducing a new layer which
contains as-yet-unprecedented complexity and confusion.
Furthermore, the SELinux patches I have seen in various applications
have given me an extremely poor impression of the code quality.
This will probably extend to other areas of SELinux.
I say, ditch SELinux.
 Here's just one example, from src/archives.c in dpkg:
* if selinux is enabled, restore the default security context
if (selinux_enabled > 0)
if(setfscreatecon(NULL) < 0)
perror("Error restoring default security context:");
#endif /* WITH_SELINUX */
Error checking ? We don't need no steenking error checking, this is
SECURITY software ! Quick, dump your brains and deploy it !