* Ross Cameron <[email protected]> [2009-07-15 03:19]:
> On Wed, Jul 15, 2009 at 9:21 AM, Anton Karpov<[email protected]> wrote:
> > According to Provos's blog,
> >
> http://www.provos.org/index.php?/archives/34-Evading-System-Sandbox-Containme
> nt.html
> >
> > "The initial prototype of Systrace as described in the paper avoided this
> > problem by using a look-aside buffer in the kernel. This imposes a slight
> > performance penalty but I hope that this obvious solution is going to be
> > included in the OpenBSD and NetBSD kernel soon."
> >
> > But we have no idea about was this solution included into OpenBSD sources
> > tree or not...
>
> Anyone got any thoughts on how hard implimenting said look aside
> buffer would be?
> Id love to do it myself but Ive not spent much time poking around in
> oBSD kernel land.
>
Relatively difficult and invasive but not impossible.
Now, you wanna know why we're probably not looking at it? Nobody is
interested. Wanna know why? Most of us don't believe systrace is a be
all and end all security tool. Most of us who work in the kernel do
not want to go to the trouble and disruption in the kernel to try to
"fix" something that in our opinion is broken by design.
Why do I say it is "broken by design"? It's *too complicated*. For a
regular user to set it up it requires too much twiddling of the
policy, particularly to open it up and make a real daemon work within
it, so I'm relatively certain that 99% of the sysadmins who would use
it and deploy it have to use a policy that allows enough stuff so that
it really doesn't matter that they are using it - By comparison, I've
seen sysadmins trying to set up apache with PERL CHROOTED into an
apache chroot so they can run fully functional perl CGI stuff within
the chroot (so why bother in the first place!). It's kind of like
having a maximum security prison but you have to give the inmates
ak-47's and ladders anyway...
Now it's not to say that *theoretically* systrace can't be a help.
I'm certain it could if you knew 100% what you were doing and knew the
inside and outs of the code. but really that's a job for the
developers, not the sysadmin running it. If the developer is going to
do it, well, at that point your best bet is simply to privsep the code
properly - that has been show to actually work, and doesn't require
insanity on the part of the system admin to pull wild guesses out of
his ass about what system calls this should use and why and when and
what the impact of allowing something is.
So short answer, I think in theory it's a neat thing. in practice,
it's not practical, and is not a magic bullet to allow you to run horrible
things securtly.
-Bob
