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 port". > I repeat: The proper solution is to prevent executing any machine code which > 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. For example, what do you do for javascript interpreters ? ( like the one we can find in webpages, or in pdf, etc ). Or libreoffice macros. 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. -- Michael Scherer !DSPAM:516a7a988771503385058! -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
