[Eug-lug] Gentoo hardened

[larry price]

On Thu, 5 Aug 2004 16:15:53 -0701, Jacob Meuser <jakemsr at jakemsr.com> wrote:
> On Thu, Aug 05, 2004 at 03:55:52PM -0700, larry price wrote:

> > I would be curious to see the difference in performance between the
> > hardened gentoo and a plain vanilla install that's been secured to
> > adequate standards (no xinetd running wideopen, a standard firewall,
> > smtpd basics etc.).
> 
> There are immense differences.  The hardened stuff is a whole other
> level of security.  It's still important to use firewalls and basic
> hardening techniques along with the kernel and ld.so enhancements.
> 
Yes, one would expect a hit, but it's not a necessary hit in  every case
after all the speed of an algorithm is not necessarily coupled with
it's security.

> > What would be the variables that could be tested that would tell you
> > something worthwhile?
> >
> > partial list:
> > 1. read/write speed (also open, close, and sync)
> 
> Heh, 2^10 small reads and writes, then pull the plug.  How long did the
> reads and writes take, and did the filesystem get corrupted.
>
Or N reads/writes/close  on /mnt/tmp;  umount /mnt/tmp; mount
/mnt/tmp; check files
> > 2. speed to respond to  a network request ( how many requests/second
> > before failure)
> 
> what kind of "network request"?
> 
apache serving a standard page? 
echo request.;  chargen ? 

> > 3. speed of opening network sockets ( how many open, write, close
> > cycles in a given t)
> 
> would require "native" code for each platform.
> 
I would think a perl or python script, or a posix-compliant  C program
would work,
this would be more in the nature of testing "real world performance"
so a scripting language would actually be a good measure of likely
performance.

> > 4. speed of performing a standard numeric benchmark
> 
> standard in what sense?
well there is the LINPACK benchmark, or the calculation of  a set
number of digits of pi
> 
> > 5. fork and exec benchmark (how fast, how many, privilege checking)
> 
> would require "native" code for each platform.
> 
see #3 above

> > Of course to be at all meaningful all other variable would need to be
> > constrained...
> 
> Well, for starters, we'd need each OS to have dedicated disks, all
> identical.  We couldn't just install them all on the same disk, as
> position on the disk would skew disk access times.
> 
> > It would be somewhat interesting way to compare OS's
> > if we could count on having a standard reference box available
> > it might be a good clinic project.
> 
> It would be a fun and teaching challenge.  It would probably be
> expensive to do it "Really Right" though.
> 
well, I'll ask around and see if we can get OPN to loan us a low-end
box and just do one OS a week for several weeks, on the premise that 
actually hitting the limits of a slower older box will tell us more
about the overhead imposed by the OS.

Just went to set up a wiki page to edit benchmark, but wiki is gone, oh well.