How NSA access was built into Windows

[Stephen Smalley]

On Sun, 2007-01-21 at 17:11 -0500, Gene Heskett wrote:
> On Sunday 21 January 2007 14:36, Lyvim Xaphir wrote:
> >On Sun, 2007-01-21 at 01:14 -0500, R. G. Newbury wrote:
> >> David Boles wrote:
> [and I snipped, we have enough trolls under this bridge already]
> 
> Also, to add a bit of fuel to the fire, I just rebuilt my 2.6.20-rc4 again 
> after having found some more selinux stuff in the previous build that I 
> am now running without.
> 
> 1: Now my logs are clean again.
> 
> 2: It took me 27 minutes to build that selinux free kernel.  Now check 
> this, after having added quite a few usb network related modules as I'm 
> trying to get into a wap11 via the usb port, which will allow me to do a 
> reset to factory, something I cannot do from the snmp interface because 
> that interface requires the old password, something I've forgotten in the 
> 8 months since I last used this device.
> 
> #> time ./makeit
> [snip about 200k of make output]
> All done! Edit grub.conf, reboot and chose your kernel at the grub prompt
> 
> real    8m42.183s
> user    4m21.606s
> sys     1m11.805s
> [root at coyote linux-2.6.20-rc4]#                 
> 
> Now, I could have done something to speed this system up that's not 
> related to selinux, but the only things I've done is to rip out the livna 
> versions of mplayer and mplayerplugin with --nodeps, and put them back in 
> from dries before they were missed, and then restart firefox from its own 
> file menu pulldown, (normal quits and re-runs didn't seem to do it) and 
> now both foxnews and cnn video's now play, although cnn's videos act like 
> the server is in need of quite a bit more iron in its diet.
> 
> Now, somebody, preferably Dr. Smalley, please explain to me why I should 
> run something that takes a 9 minute compile and makes it take 27 minutes 
> to do it.  And the rest of the system just plain feels snappier.

(1) I'm not a PhD.
(2) If SELinux tripled your kernel compile time, then something is
terribly wrong with it.  I've never seen that kind of overhead in kernel
compile benchmarks, not even close.  More like a few percent.  Please
verify that you are using comparable baselines (e.g. same kernel other
than selinux options in .config) and tests (are you sure your second
build was from a clean state, and was there any other system activity
ongoing during either build?).  Can you reproduce the result reliably?
Were any audit/avc messages generated during either build,
to /var/log/messages or /var/log/audit/audit.log (if running auditd)?

-- 
Stephen Smalley
National Security Agency