Le dimanche 14 avril 2013 à 01:43 +0200, Kevin Kofler a écrit :
Richard W.M. Jones wrote:
> This would be excellent, and projects in this area could make a
> significant contribution. I suspect that any general code-to-policy
> translator will hit the Halting Problem, since it seems trivial to
> write a program which would not be possible to translate, but that
> doesn't mean it can't be solved for many useful real world cases.
That's exactly why SELinux policy is the wrong representation. It duplicates
information of the code without being automatically transformable either
way, requiring every change to be made twice.
If a software say he can open any arbitrary files on the filesystem
doesn't mean it should. The code is most of the time not adequate to
explain the permission really needed, that's too low level. And the unix
model of user is not really adequate either.
You could argue the exact same things about unix permissions "why does
apache requires me to modify permission on ~/public_html while I already
expressed it can read them in code" or firewall "why should I open the
port 80 when i already said in the code of apache that it will use this
I repeat: The proper solution is to prevent executing any machine
is not part of the program's source code. Block arbitrary-code execution
exploits and SELinux is just dead weight.
Repeating doesn't make it right.
( like the one we can find in webpages, or in pdf, etc ). Or libreoffice
Or php interpeter, whose source code do we take in account, the one of
php, the one of apache, the one of the php application, ( unless someone
add a plugin of course ) ?
The whole point of having it in 2 different places is to have a proper
inspection of what it need to do. That's defence in depth. And security
bugs have been fixed due to that inspection, like software leaking file
descriptors by errors.
More over, SELinux do more than "blocking arbitrary code-execution
exploit", it also allow to enforce access control to follow security
model such as Bell-LaPadula model, it permit to have proper isolation
for software like openshift origin, or SVirt.
But you are welcome to convince any upstream directly to invest more
time in stuff like seccomp-bpf as did by Chrome, vsftpd and others if
you think that's the right approach to fix security issues.