On 1/29/06, Elad Efrat <elad@netbsd.org> wrote:
> > Personally, I do security for a living
> are you a white-hat hacker? :)

I don't wear cowboy hats.

>   - expect gcc 4.1 soon (?) with built-in ssp;

Cool.  If you happened to be at Usenix Security when Crispin presented
his StackGuard paper, I was the one who caught him off-guard by asking
why he didn't use processor protection of the stack frame to protect
the data, and why he didn't consider storing return addresses on an
alternate stack.  After all, you have to compare the canary to
something, right?  So why not store the return address where you would
have stored the canary, and trade probabilistic security for a sure
thing?  You can compare it to the original if you like detection with
your prevention.

>   - this very thread is about redesigning securelevel in a finger
>     grained way;

I like fine-grained control.  What do you think about it with regard
to the access granted to processes and programs?

>   - there is a lot of work in progress in having netbsd use kernel
>     authorization;

``The expressiveness of our system includes both Discretionary and
Mandatory Access Controls (DACs) and (MACs).''  Hmmm.  Didn't you say
you thought MAC was a waste of time?

> of course throughout this thread i've been trying to balance "design"
> with not too much of over-engineering.. but...
>
> or was there a different point to your mail that i completely missed? :)

Well, I'd still like to hear the argument against MAC.  I can see how
the total access required by a typical application could be big enough
that compromise could do a fair amount of damage anyway.  But
certainly limiting processes or programs to the minimum access they
need can't be an altogether bad thing?  It follows the "principle of
least privilege", something I consider wise and fairly conservative
(some may say paranoid).  I implement that for network-based security
with packet filters, but there's no equivalent for host-based
security, at least in NetBSD (last time I checked -- perhaps systrace
is available now I really don't know).
--
"The generation of random numbers is too important to be left to chance."
  -- Robert Coveyou -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B