On Fri, Nov 01, 2002 at 11:10:00AM -0800, Chuck Yerkes wrote:
> 
> For those that use pre-built binaries.  This makes the advantages of
> Open Source fade a bit (though most of the Linux users do this, I find).
>

Not at all.  You could always sign your own fingerprints.  What it
does do is help mitigate the chicken-and-egg situation of how do you
know that the code you are using to do the signing is able to be
trusted.  The decision, as Bill pointed out, is whether or not you
trust the builders.
 
> 
> In my paranoia days when I had to put up a very important web site
> for a bank, using SunOS 4, I put all the binaries on disks pinned
> readonly.  Data - checked hourly and overwritten entirely every day,
> was on R/W disks.  These days I'd mount those nosuid,noexec,nodev.
> 

Yes, been there, done that.

> While these seems like a neat idea, without having a dedicated
> specialized processor to provide the sig, it's going to be burdensome.
>

No.  As I said in my original announcement there is no detectable
impact on the system, perhaps on a slower processor the impact may be
noticable - the slowest I tested verified exec on was a p120 laptop.
I would be interested in hearing about results on slower machines.

> 
> Getting rid of privilege and executable stacks is a feasible step
> that will give us more.
>

The cold, hard, reality is that non-executable stacks don't buy you as
much as you are hoping.  You can still run library calls, you just
construct the stack frame for the call, put the lib call address as
the return address and away you go.  Making stacks non-executable is
not a bad thing to do (if your hardware supports it) but it does not
stop everything - just like verified exec does not stop everything.

>  Clever use of chflags and, perhaps a way
> to do a hard lockdown of the executable PATH depending on the user
> would be of quicker benefit, IMHO.
>

What? Like what restricted sh fails to do?

-- 
Brett Lymn