"Safer" Execution of Semi-Trusted Code

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

OpenBSD has pledge (man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2?query=pledge). pledge(2) is a system call that irrevocably restricts the abilities of a running process and any of its descendants and prevents them from accessing certain families of system calls. Any program that attempts to perform a prohibited system call after pledging it away will crash and produce a core dump, allowing the developer to investigate the problem. Evidently, there are future plans to allow a whitelist of paths that can be referred to in system calls.

It would certainly be interesting if you had a high-level language like Lisp or Python with similar capabilities. If you could wall off certain bits of functionality dynamically, then it would be easier to verify assumptions you've made about libraries that your code doesn't use. Support for privilege revocation inside the language runtime can also be more fine-grained than the pledge(2) interface and allow the programmer to revoke access to individual modules or functions, or to perform additional checks before running a potentially unsafe function. Sticking this kind of functionality inside the runtime for a high-level language also allows the ability to get informative stack traces or even an interactive prompt with potential handlers like Common Lisp has.

So, my question is, why don't we already have languages with support for privilege revocation and would even it be a good idea?

Other urls found in this thread:

hackage.haskell.org/package/Capabilities
twitter.com/AnonBabble

You seem to have confused Sup Forums with a technology board and not a consumer electronics board.

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

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)

Are you retarded?
>5 replies
>5 posters

>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.

How often is pledge actually used?

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.

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

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

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 Sup Forums is consumerist safe space so you shall not trigger their diginity.

>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

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.

How effective is pledge and chroot compared to freebsd jails?

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.

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

>whitelist instead of a blacklist
sounds like /thread

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

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.

I prefer grsecurity's rbac MAC

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

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?

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)

Isn't there a capability Haskell thing somewhere?

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

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)

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.

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