Expanding the list of "Hardened Packages"

[Michael Scherer]

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!