"Safer" Execution of Semi-Trusted Code

You seem to have confused /g/ with a technology board and not a consumer electronics board.

>>57711409
I haven't posted here in a while... What happened?

>>57711482
teenagers with smartphones

Isn't Common Language Runtime all about that? It certainly doesn't run anything directly.

OP samefagging so obviously

was going to reply seriously but I won't now desu (to be honest)

>>57714886
Are you retarded?
>5 replies
>5 posters

>>57711360
>It would certainly be interesting if you had a high-level language like Lisp or Python with similar capabilities.

As far as I remember, Perl, Mono/.Net and JVM have this capabilities somehow, though you might want to do your own research here.

Python was always a fuckup if it comes to being a useful interpreter and Lisp was always about hurrdurr muh complete immerse environment.

>>57711360
How often is pledge actually used?

>>57716059
Uneducated guess:
Probably not often, maybe a couple of system tools or VMs use that stuff, but most software doesn't require exotic stuff like this, in particular on the OS level.

It's still a good thing to have special APIs for everything, otherwise your OS ends up not being supported. Compare for Linux with PyParallel.

>>57716059
it's used in most of the OS it's from

>>57711360
Sounds like you basically want static linking / inlining, anon? Code that you don't use won't end up in the binary, and therefore can't be called by your program

File: kek.jpg (31KB, 446x562px) Image search: [Google]

31KB, 446x562px

>>57711482
Even c fizz buzzers and lis memers were replaced by kids.

Every technical thread and especially threads that involve some kind of math makes those people really angry and /g/ is consumerist safe space so you shall not trigger their diginity.

>>57711360
>Any program that attempts to perform a prohibited system call after pledging it away will crash and produce a core dump

Because trojan writers will pledge away system calls?

Right?

LAUGHTER OL

>>57716059
>>57716257
The problem with a security tool that isn't guaranteed to be used by programs is that the programs with all the security flaws in them will be the ones not using these tools either.

That's why I much prefer the SELinux/MAC approach, which uses a whitelist instead of a blacklist - unless you specifically *enabled* a system call, it's blocked by default.

Much safer in practice than OpenBSD's blacklist monkey patch approach where they try to stomp out all of the weeds as they pop up.

>>57711360
How effective is pledge and chroot compared to freebsd jails?

>>57718174
You're missing the point. The moment you install a trojan you are fucked no matter what fancy security mechanism you have. No mechanism can fix stupidity.

The point is making your own programs survive being exploited. You don't want a stack overflow turning into RCE. If you prevent your program from doing anything other than accessing its own files, then at best an RCE could subvert your program's database or whatever - but not install a trojan on the system itself.

>>57718118
Sounds more like linking of plugins with options to forbid the plugin to call certain stdlib functions to me...

>>57718180
>whitelist instead of a blacklist
sounds like /thread

>>57718267
I don't really follow. Can you provide a more concrete scenario?

>>57718289
You have a software and you want to provide a C plugin interface and manager.
Since those plugins come from the interwebs/otherwise untrusted sources you can't validate, you don't want to allow them too much.

>>57718180
I prefer grsecurity's rbac MAC

>>57711360
>I don't know of any programming languages out there that have the ability to restrict the functionality of a running program.
Tcl/Tk

>>57718198
Apples to Oranges
Pledge is a syscall that tells the OS what I(the program) shouldn't be doing, jails are more comparable to linux containers, which are more of telling the OS what is the environment I live in. Chroot is a way of changing your root, not designed from the ground up as a security feature but people used them as a means to trap exploiters into an environment which is much easier to break out of.

Maybe you could post this question in OpenBSD Misc?

>>57711360
You could do this in Haskell if IO were implemented differently, say in terms of the operational monad with a coproduct of different sets of actions (e.g. console actions, disk actions, network actions)

>>57719027
Isn't there a capability Haskell thing somewhere?

>>57719113
Possibly. There's this but it hasn't been worked on since 2013: https://hackage.haskell.org/package/Capabilities

>>57718392
Ah, makes sense. That doesn't so much seem like something that would be part of a language though as much as it would seem like some kind of virtualization/jail solution in general.

I mean the mechanism is totally there, x86 has virtualization primitives which is what enables stuff like KVM to run at near native speeds when it comes to code execution (not I/O).

You could totally build some kind of plugin wrapper that executes plugin code through something like KVM or Xen. Erlang can basically do this (look up xenling)

>>57720376
I guess that is how the chrome sandbox native API works, whatever it was called again.

People usually go the lazy way through scripting languages.

>>57711360
This would have been unnecessary if modern CPUs inherited hardware bounds and type checking from Burroughs and Lisp machines.