Re: a new syscalls table

On Fri, 25 Jan 2008 14:51:44 -0800 "Jerry Toung" <jrytoung@xxxxxxxxx> wrote:

Hello list,
I am trying to create an environment where you can't run my binaries on your
box and I can't run
your binaries on my system (x86 platform).
For that, I have modified the system calls table (i.e everything is offset
by 5).
[...]
When it comes back, it panics in kern/kern_exit.c with
"Going nowhere without my init!"

How can I make this work?

Treat it like a cross-platform build, and install to a different
partition on your disk, then boot that partition.

Is my initial objective even possible?
I think the correct approach would be to have a cpu that no else in the
world has,
any in between solution.?

Depends on what you mean by "correct approach". Basically, it's a
security issue. So you almost certainly can't make it mathematically
impossible, but you can raise the cost of people running your binaries
on their box - and vice versa - pretty much as high as you want,
providing you're willing to pay for it. I'm not sure how well fabbing
custom silicon would work; it's certainly at the high end of the cost
scale, but it can be reverse engineered, and then your custom CPU
could be emulated in software for a lot less than it cost you to
design the silicon. Of course, you could take that approach yourself
to save money.

On the other hand, once you realize that it's a security issue, you
can start using security tools for this. For instance, the NetBSD
executable verification feature does half the job - it won't run their
executables on your system. By tweaking it a bit - encrypting as well
as signing, for instance - you'd do both halves, with better
performance than emulating a new CPU, and a lot less work. Personally,
I think that'd also be more useful to the rest of the community than
an offset syscall table as well.

<mike
--
Mike Meyer <mwm@xxxxxxxxx> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: z9BC as Web Server
    ... The cost to do it is a fraction of the cost my fellow ... Windows Brethren spend to do the same thing. ... Indeed if one puts a CPU intensive application on ... As far as security. ...
    (bit.listserv.ibm-main)
  • Re: a new syscalls table
    ... I'll look into the NetBSD thing. ... I am trying to create an environment where you can't run my binaries on ... but you can raise the cost of people running your binaries ... On the other hand, once you realize that it's a security issue, you ...
    (freebsd-hackers)
  • Re: thoughts on kernel security issues
    ... people _do_ need to execute binaries in their home directory. ... Containment is what real security is about. ...
    (Linux-Kernel)
  • Re: thoughts on kernel security issues
    ... exec-shield has trapped quite a few remotely ... you can only execute binaries that you cannot ... nobody should ever depend on the kernel having zero holes. ... We do our best, but if you want real security, you should have other ...
    (Linux-Kernel)
  • Re: The price of SELinux (CPU)
    ... > do what they want to his system, and other users' idiotic actions on a ... any additional security ends up trading off against other things. ... And then those binaries are still vulnerable.... ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)