[SGVLUG] Reverse Engineering / Analyzing the SELinux Kernel Source Code?

[Sean O'Donnell]

Sorry to ask such an *out-there* question, and voicing such an 
irrationally biased opinion on the matter, but like I said, I didn't 
know how to ask. =p

After reading the (2.6.10 kernel) analysis which describes various flaws 
in the linux random number generator, it made me wonder if an actual 
analysis had been performed on the SELinux kernel.

http://www.pinkas.net/PAPERS/gpr06.pdf

I guess my imagination/opinions ran a bit wild *damn coffee+news feeds*, 
but I do agree with what Terry said.

The possibility of tainted binaries are one reason why I prefer 
compiling (most, especially tcp/udp/ip server applications) from source.

*well, that, along with the benefit of being able to define your own 
configuration directives* =)

Another scenario (which can be applied to any software in general) would 
be to replace an ISO image on a distro's mirror with a tainted copy, 
assuming there was no sig included to verify the image/file authenticity 
(which I assume most distros include, by the glimpse of it). *highly 
unlikely, but 100% possible*

Terry Hancock wrote:
> Dustin Laurence wrote:
>>  On Fri, May 19, 2006 at 05:30:04PM -0500, sean at seanodonnell.com
>>  wrote:
> 
>> > Q?: Has anyone reverse engineered the SELinux Kernel? Or analyzed
>> > the source code for possible rootkits or 'undocumented features'??
> 
>>  Effectively, yes. If you are paranoid, then it is probably the only
>>  code you *should* trust. The problem with this is that you still
>>  have lots of people poring over the code, you can't work in secret.
> 
> The way for the NSA to slip in a backdoor would be via a pre-built
> SELinux *binary*, built from secret sources that don't match the
> publically available ones.
> 
> With inside help from any distribution (commercial or community),
> they could manage to slip such a thing into the binary version of
> that distribution (as could others, of course).  It wouldn't be easy,
> but there are documented examples of it being done by other
> organizations.
> 
> Any opinion I had on the likelihood of such a strategy would
> be biased by irrational reasons, so I'll avoid saying.  I'm merely
> commenting on the technical feasibility of it: difficult, but
> not impossible.
> 
> If you want to feel really paranoid, read:
> "Reflections on Trusting Trust"
> by Ken Thompson
> http://www.acm.org/classics/sep95/
> 
> (which suggests a more-difficult-to-trace variation on the above
> strategy).
> 
> I found this intriguing hit in the process of looking that up, though:
> "Countering Trusting Trust through Diverse Double-Compiling"
> by David A. Wheeler
> http://www.acsac.org/2005/abstracts/47.html
> 
> "Hmm."
> 
> Cheers,
> Terry
>