Re: [gentoo-hardened] Ports Security

[Jan Krueger]

On Saturday 06 September 2003 15:27, Alexander Gabert wrote:
> hello,
>
> there is nothing that can "guide" you, in my opinion.
> the program that checks for flaws must print out a list of "problematic"
> code pieces based on real facts.
> the threat is real, so must be the defense mechanisms.
> no "guidance" or "counseling" needed for the user to be influenced.

Well, thats true. I thought of an average user that wants to install a 
userspace program that does something with internet. The user heard about 
security issues with the internet and so cares a little bit but ofcourse has 
no knowledge about what this really means nor is the user a developer who is 
able to fix that. luckily there are several option for such a program 
available. So the user exploits some of the suggested emerge commands and 
based on the results uses for now the software with the least impact and 
additionally files a bug report to bugs.gentoo.org saying that actual emerge 
found security issues the user wants to get fixed (and is willing to donate a 
donut for fixing :)

> > some of the next steps i can imagin are:
> > - a ports security policy :)
>
> well, devs are notorious overworked ppl.
> you would not rush in open doors.
> but i appreciate your thoughts and will try to make up my mind.
Most of such a policy is published and available on the net, from other 
projects or known highly secure OS's. (One of them, espicially for those who 
dont like to hear it, is OpenBSD :) I understand that gentoo hardened can not 
be an isolated project. It has to be open + cooperative even with "competing" 
OS's to reach the goal "hardened")

> > - suid scans
> >
> > - scans of binaries
>
> not possible.
> writing disassemblers that make assumptions is bad practice.
Thats not what i meant, so i try to explain better:
We have much information about the binary from the build process before, there 
is no need to disassemble.

Lets say a binary "mta" is build and but into $IMAGE/usr/sbin with suid root.

From analysis of the Makefiles in the still existing source tree we know:
this file comes from the directory $S/smtp/core/mta

And is made out of:
smtp.o
connect.o
socket.o
checkuser.o
deliver.o
rfc.o
bla.o
digitalmess.o
randommess.o
(mess here short for message ;)

for those we got the corresponding source files.
So we can see deliver.o makes extensive use of functions executing external 
binaries. deliver.o is part oft mta. mta is installed suid. no part of mta 
calls a function that indicates a drop of priviliges. Conclusion: mta is 
potentially dangerous.

> > - complexity analysis (we got the code, we got the binaries - if there
> > was createt only 1 biiig binary out of al the code we know that the
> > potential security impact is higher (exim)  then if there would have been
> > created several small binaries (assuming modularity, like qmail), etc.
>
> qmail is not more secure than exim, if the author says so, he may say
> so.  i myself do not believe it, should be careful what you interpret.
Its not that i believe in what the author of qmail claims to be true.

I, therefore i am a unix-user, believe in modularity, simplicity, small tools 
that do dedicated tasks and nothing else, that can be combined to something 
usefull (Well, unix :)

qmail is the only full functioning mta that consistently implements this 
principles (afaik) and _thats_ the reason for me to believe qmail is more 
secure than all those other mta's around.

(Beside the fact that i will receive 500$ as soon as i find a security hole in 
qmail :) This "security garantee" i see as an political advantage of qmail.)

> the truth is that packages like qmail deserve the high reputation only
> from the people who are using it.
>
> > - dynamic meta-information from external sources (CERT, GLSA Database)
>
> very good point, we could make a "link" to bugs found regarding the
> source URI.
> which would resolve in a mapping: CERT/Bugtraq <-> SRC_URI
>

> > ofcourse, this all can be enhanced and so on, thats why i put it here :)
>
> thank you,
>
> a last thought about your binary scanning.
>
> pipacs is the brain behind PaX who is working out the logic for
> protecting accesses.
>
> the holy grail is "full bounds checking" which means basically that you
> can watch, control AND limit any arbitrary (random, going everwhere)
> memory address write or read by the running program.
> the running program has 4GB open memory with 1GB of the 4GB is kernel
> memory.
>
> even stackguards preventing direct linear overwriting of addresses can
> be "circumenvented" as we all know.
> even address space layout randomization, basically moving round and
> round of ELF segments and making the memory address relocations not
> writable with PIC compilation, can be information leaked.
>
> it is not possible to employ bounds checkers like the "mudflap" gcc or
> other solutions.
>
> it is just a compromise between speed and security.
Thats always true :)
Really always?

If transfering mail would be secure (no spam possible) the internet would be 
faster (no trillionsibytes of spam traffic). Hm.

> you inspired me
Finally i did something useful :)

> and what has come into my mind is some kind of "hybrid"
> solution where we run the preprocessed source through some kind of
> "bounds checking sandbox" which evaluates the possible program flows in
> terms of trees (gcc people can explain more about this) and evaluate the
> pointers at each point of execution.
Thats nearly what i wanted to say but could not express :)
I tried to explain above.

Thank you for your positive words.

Jan


--
gentoo-hardened@g.o mailing list