[nycbug-talk] BSD Chapter in HLE

[Ray Lai]

On Fri, Sep 15, 2006 at 01:23:11PM -0400, Dru wrote:
> Hacking Linux Exposed is going to its third edition and I've been asked to 
> write a chapter on BSD security for this edition. I only get one chapter 
> and am supposed to provide an overview of the security features available 
> in *BSD.
> 
> A draft outline is appended. I plan to showcase the features common to 
> FreeBSD, NetBSD, and OpenBSD as well as point out any features which may not
> be currently available in all 3.

I can't really speak for the other BSDs, but I'll try to discuss
OpenBSD-specific features worthy of mention.

> My question to the list is: is this draft missing any features which 
> should be mentioned? Should I mention the ability to strip kernels and 
> build world/build.sh?

I don't see how stripping kernels is a feature, since it is helpful to
debug kernel panics.  make build is a nice and easy way to keep your
system up to date.  Just cvs up or apply patches, make build, and go to
sleep.

> What about OpenBSD propolice?

It would be nice to describe some of these security enhancements in
depth (more in depth than Theo's slides, less in depth than the author's
web pages).

> What about Coverity 
> audits being integrated into engineering processes?

Coverity is a nice tool, but its suggested fixes should not be committed
wholesale without checking if they are correct.  This is true for just
about every other tool.  Don't overlook lint, either.  Chad Loder has
been improving our lint to quiet it down and to concentrate on real
issues.  It is pretty useful to run these tools on the source code and
look carefully at areas they point out, concentrating on new findings.
Be careful not to change code just to silence the tools, however; this
can introduce bugs or silence legitimate ones.

> Built-in security features
>  	- minimal install (secure by default)

I'd like to mention that the GENERIC kernel has all the usable devices
enabled by default, so users don't need to configure and recompile
anything to get their devices working.  The less there is to configure,
the less chances users have of messing up.

>  	- periodic security scripts

Checks for changed suid/sgid files, changed devices, and wrong
permissions.

>  	- sysctl

Enable holes in the kernel, if you'd like.  Mainly,
machdep.allowaperture=2 is required for i386 for the X Window System.
This requirement is being worked on; I am currently running an
unaccelerated X with machdep.allowaperture=0 on my X40, but
unfortunately this won't make the 4.0 release.  4.1 will probably have
it.

>  	- chflags

chflags (and read-only mounts) can be used to prevent files from being
overwritten, but can be maintenance nightmares.  Log rolling and
updating system files suddenly requires rebooting, sometimes in single-
user mode.

>  	- /etc/ssh/sshd_config

Privilege separation, delayed compression, and no forwarding by default
are worthy of mention.

>  	- blowfish support

Be sure to mention the techniques described in "Future-Adaptable
Password Scheme", by Niels Provos and David Mazieres.

It would be nice to mention all the different sources of entropy used to
generate random data as well.

>  	- encrypted (filesystem) support (cfs, cgd, gbde, geli)

vnconfig(8) supports encrypted filesystem images.  Also, encrypted swap
is enabled by default.

>  	- securelevel

Like chflags and read-only mounts, securelevels can be maintenance
nightmares, requiring booting to single-user mode for firewall or system
updates.

>  	- rc.conf

By default, almost everything is turned off but can easily be turned on
by adding lines to rc.conf.local.

> pf Firewall Features
>  	- CARP

pfsync and CARP allow firewalls to be upgraded without having downtime.

>  	- stateful tracking (connection limiting, synproxy)

Many complicated firewall filtering rules can be condensed into simple
keep state rules, leaving all the packet validation to the pf instead.
synproxy is nice, but does anyone still do syn floods?  I guess it's
useful for protecting operating systems that are vulnerable to them,
though.

>  	- direct manipulation of state table

Useful for writing simple, secure userland proxies, such as ftp-proxy.

>  	- OS fingerprinting

Redirect mail sent from Windows and Linux machines to spamd(8) works
wonders, I hear.

>  	- traffic normalization
>  	- state modulation

Like synproxy, these two are helpful for protecting other operating
systems.

> Additional BSD Resources
>  	- URLs to FreeBSD Handbook, NetBSD Guide, OpenBSD Guide

We strive to have correct, up-to-date, and useful manuals, so please
don't ignore them!  For more extensive coverage of certain topics, the
FAQ is useful as well.

I hope everything I've stated here is accurate; any corrections are
welcome.

-Ray-