[Eug-lug] Gentoo hardened

[Jacob Meuser]

On Thu, Aug 05, 2004 at 05:41:16PM -0700, larry price wrote:
> 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.

I didn't mean to suggest that.  The "immense differences" are in
the method of security as compared to shutting down services, firewalls,
etc.

> > > 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.

yes, measuring "real world" performance is probably more meaningful.

> > > 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.

I think it would be interesting also, to see what kind of increases
can be made by changing configurations, without recompiling.  For
example, in OpenBSD, there are limits on open files, amount of memory
in use, etc, that can be controlled by plain text configuration files.

-- 
<jakemsr at jakemsr.com>