Guy Harris wrote:
> So what distinguishes a "band-aid" from a fix considered more acceptable?
They may be referring to a reactive, fix-problems-as-they-appear vs a
more proactive approach.
> But all privilege separation does is arranges that buggy code run as you
> rather than as root. That's useful, but preventing buggy code would be
> useful as well.
How hard would it be to fork off into privileged "capture" and
non-privileged "display" processes at program startup, or create a
separate (and privileged) program specifically for captures? Even
though it doesn't fix the larger issue of dissectors stomping all over
our memory space, it might be worth looking at.
NAI/McAfee Research has a library called "Privman" that's supposed to
make this sort of thing easier, BTW:
http://opensource.nailabs.com/privman/
> I suspect that at least *some* of the problems might have been avoided
> with a higher-level language in which to write dissectors, with a
> translator that takes that language and generates C code that avoids
> using unsafe idioms. Given that we have a lot of dissector
> contributions, and not a lot of time to review them, that might at least
> help. (If the language is powerful enough, the translator might also be
> able to generate code that properly checks for null pointers in at least
> some cases.)
Were you thinking of something similar to what we currently have with
the ASN.1 and NCP generators, or something beyond that?
Powered by MHonArc 2.6.10