Put a process in a sandbox where it can do least harm - windows

I'm looking for the concept to spawn a process such that:
it has only access to certain libraries/APIs
it cannot acess the file system or only specific parts
it can do least harm should malicious code run in it
This concept is known as sandbox or jail.
It is required to do this for each major Operating system (Windows, MacOSX and Linux) and the question is conceptual (as in what to do, which APIs to use and and what to observe) rather then language specific.
answer requirements
I really want to accept an answer and give you 20 points for that. I cannot accept my own answer, and I don't have it yet anyway. So if you really want your answer to be accepted, please observe:
The answer has to be specific and complete
With specific I mean that it is more then a pointer to some resource on the internet. It has to summarize what the resource says about the topic at least.
It may or may not contain example code, but if it does please write it in C
I cannot accept an answer that is 2/3 complete even if the 2/3 that are there are perfect.
this question FAQ
Is this homework? No.
Why do you ask this like a homework question? If you ask a specific question and you want to get a specific answer, and you know how that answer should look like, even though you don't know the answer, that's the style of question you get.
If you know how it should look like, why do you ask? 1) because I don't know all the answer 2) because on the internet there's no single place that contains all the details to this question in one place. Please also read the stackoverflow FAQ
Why is the main part of your question how to answer this question? Because nobody reads the FAQ.

Mac OS X has a sandbox facility code-named Seatbelt. The public API for it is documented in the sandbox(7), sandbox_init(3), and related manual pages. The public API is somewhat limited, but the facility itself is very powerful. While the public API only lets you choose from some pre-defined sandboxes (e.g. “All sockets-based networking is prohibited”), you can also use the more powerful underlying implementation which allows you to specify exactly what operating system resources are available via a Scheme-like language. For example, here is an excerpt of the sandbox used for portmap:
(allow process-exec (regex #"^/usr/sbin/portmap$"))
(allow file-read-data file-read-metadata (regex
#"^/etc"
#"^/usr/lib/.*\.dylib$"
#"^/var"
#"^/private/var/db/dyld/"
#"^/dev/urandom$"))
(allow file-write-data (regex
#"^/dev/dtracehelper$"))
You can see many sandboxes used by the system in /usr/share/sandbox. It is easy to experiment with sandboxes by using the sandbox-exec(1) command.
For Windows, you may want to have a look at David LeBlanc’s “Practical Sandboxing” talk given at Black Hat USA 2007. Windows has no built-in sandboxing technology per se, so the techniques described leverage an incomplete mechanism introduced with Windows 2000 called SAFER. By using restricted tokens, one can create a process that has limited access to operating system resources.
For Linux, you might investigate the complicated SELinux mechanism:
SELinux home,
a HOWTO. It is used by Red Hat, for example, to harden some system services in some of their products.

For Windows there is a sandbox in Google Chrome. You may want to investigate it. It uses liberal BSD-like license.
For Linux there would be good old chroot or more sophisticated http://plash.beasts.org/wiki/.
OS X since Leopard has some SELinux-like protection available.

The site codepad.prg has a good "About" page on how they safely allow the execution of any code snippets..
Code execution is handled by a supervisor based on geordi. The strategy is to run everything under ptrace, with many system calls disallowed or ignored. Compilers and final executables are both executed in a chroot jail, with strict resource limits. The supervisor is written in Haskell.
When your app is remote code execution, you have to expect security problems. Rather than rely on just the chroot and ptrace supervisor, I've taken some additional precautions:
The supervisor processes run on virtual machines, which are firewalled such that they are incapable of making outgoing connections.
The machines that run the virtual machines are also heavily firewalled, and restored from their source images periodically.

FreeBSD has specific concepts of jails, and Solaris has containers. Depending on what you're looking for, these may help.
chroot jails can help to limit what an application can do (though any app with root privileges can escape a jail), and they're available on most UNIXen, including OS X.
As for Windows, I'm not sure. If there was an easy way to sandbox a Windows app, most of them would be a lot more secure by now, I'm sure.

On windows (2000 and later) you can use Job objects to restrict processes.

If you really want a technique that will work with all these platforms, as opposed to a separate solution for each platform, then I think your only answer is to set up a virtual machine for each testing environment. You can restore back to a snapshot at any time.
Another big advantage of using virtualization is that you can have all of the testing environments with their guest operating systems all on the same box.

For Linux, there is AppArmor. Unfortunately, the project is somewhat on hiatus.
Another sandboxing-alternative is VServer, which uses virtualization.

Generally any virtual private server will do:
Linux VServer
http://linux-vserver.org/Welcome_to_Linux-VServer.org
Parallels Virtuozzo Containers
http://www.parallels.com/products/pvc/
and as was mentioned FreeBSD and Solaris has own implementations.
Oh. actually I've noticed you're asking it to work on ANY OS. Well, that might be complicated a bit as the I think less effort is just to reuse some VM that can support some level of sandboxing like:
Java
.NET

I'm not an expert on the topic, but i think the standard answer for linux is to define a SeLinux policy with the right capabilities for the process.

Related

How to create a debugger without using operating system capabilities

Recently I get a test task from one company. And one question is:
Suppose you are given a task to write a simple debugger (for a
proprietary operating system) that is capable of setting a break-point
in an application and running it. What would be key design decisions
you make in such a task?
I think I don't know something but I have absolutely no idea about answer. I understand how debuggers work (INT 3 - should have access to virtual space of debuggie) but I suppose the answer about "proprietary operating system".
This question, as usual at the interview should make you asking more questions about the system and requirements.
Does operating system already provide some kind of primitive tracing tool you can use?
What language are tested applications written in?
Some inspection tools, for example valgrind, run inspected programs in their own environment, which seems a good way to go in your case. The other approach is to instrument the binary with tracing instructions, communicating with your debugger - this is probably more suitable and easier to do when your applications run under a VM.

Writing an SNMP Agent for Windows: SnmpAPI.Lib or MgmtAPI.lib?

I need to write an SNMP agent on Windows for our company product.
SnmpApi.lib - It's my understanding that SnmpApi.lib allows you to create a full agent from scratch and probably requires more work. This, however, takes over the SNMP port and doesn't allow other agents to run and will take longer to code.
MgmtAPI.lib - This lib will allow one to create an extension to the already running Windows SNMP service and seems a more elegant approach to creating an Windows agent. However, I'm findining very little official MS documentation/examples on how to code such an agent. I've also read on another forum that this might be deprecated.
I've seen an Oreilly book out in the wild called "Windows NT SNMP" but I heard it uses deprecated libs or techniques. I don't know if this is true or not.
I've also seen libraries like SNMP++ that use the SnmpAPI.lib to create an agent, but again, this isn't as elegant as letting multiple sub-agents on the system via MgmtAPI.lib, it seems.
A few questions:
I heard that MgmtAPI.lib is legacy/deprecated. Is this true?
What's the best practice for creating a Windows SNMP agent?
What library should i be using?
Any other suggestions?
Thank you!
The default windows SNMP stack and framework is very limited in its ability. Unfortunately, your best solutions are probably found elsewhere (of which there are a number of external libraries and stacks). If you want one that is modular and allows sub-agents, then look into a stack that supports the AgentX protocol. That's a standardized SNMP subagent protocol and will let multiple sub-agents attach to a master agent.
But whatever you do, please pick a stack that supports SNMPv3 and use the security in it.
If you want a random stack example that is known to work well on windows, try Net-SNMP which is fairly popular among the "replace the SNMP stack on windows" crowd. But I'm also biased and associated with the project, so I'll end with saying: "it doesn't matter too much; pick any stack that supports both AgentX and SNMPv3".

Wanted: multi-platform shell provider for code debugging, Itanium/IA64 preferred

Does anyone know of a UNIX shell provider that offers access to a multitude of platforms (e.g. Linux/Itanium, Max OS X/PPC, etc.) for debugging and portability testing?
I suppose that since this is a common problem that there are such services, but a Google search did not turn up anything interesting...
I am particularly interested in Linux on various CPUs, IA64 being the most important right now.
Thanks, S.
If you're developing Free software, look at the GCC CompileFarm: http://gcc.gnu.org/wiki/CompileFarm
---- The post that came back from the cold (3 year edit) ----
Launchpad gets pretty close, but it is not clear if their compiler farm can be reached by projects that are not managed by their project management software.
Most people eventually setup their own farm of servers, as simply having access to a machine might not even be enough. Often you will want to determine exactly what software is installed, which makes it very hard to reuse for a completely different project.
Fedora and OpenSUSE have a linux-specific build farms for the architectures they supports. It is unlikley that the extend such services to proprietary (or even non-their-distro) softare projects. That won't do much for the HPUX / Solaris / etc OS platforms.
---- Edited after response ----
Have you tried SSH?
---- Original Post Follows ----
The problem with Shells is that even when you have a multi-platform shell, each platform has different executables installed, and different options on the executables you'll call from your shell.
For maximum portability, use Bourne shell, without extensions. That said, you'll find yourself in some pretty odd situations; as with Microsoft Windows platforms, Cygwin will require a few path altering tools to work well under the Cygwin environment.
The key is not only the shell, it's how to use it portably. For some guidance, look to this chapter in the Autotools manual
There are many hosts that offer shell accounts. One example, polarhome.com, offers a variety of environments to choose from. I don't believe they have much variety in hardware. Shell accounts cost a one-time fee of "10 local currency units" (minimum US$2 - for a user in the US it would be $10) per account (per environment).
Availability of what you're looking for is going to be somewhat limited, since providers have a number of security issues to contend with.

Executing a third-party compiled program on a client's computer

I'd like to ask for your advice about improving security of executing a compiled program on a client's computer. The idea is that we send a compiled program to a client but the program has been written and compiled by a third-party. How to make sure that the program won't make any harm to a client's operating system while running? What would be the best to achieve that goal and not decrease dramatically performance of executing a program?
UPDATE:
I assume that third-party don't want to harm client's OS but it can happen that they make some mistake or their program is infected by someone else.
The program could be compiled to either bytecode or native, it depends on third-party.
There are two main options, depending on whether or not you trust the third party.
If you trust the 3rd party, then you just care that it actually came from them, and that it hasn't changed in transit. Code signing is a good solution here. If the third party signs the code, and you check the signature, then you can check nothing has changed in the middle, and prove it was them who wrote it.
If you don't trust the third party, then it is a difficult problem. The usual solution is to run code in a "sandbox", where it is allowed to perform a limited set of operations. This concept has been implemented for a number of languages - google "sandbox" and you'll find a lot about it. For Perl, see SafePerl, for Java see "Java Permissions". Variations exist for other languages too.
Depending on the language involved and what kind of permissions are required, you may be able to use the language's built in sandboxing capabilities. For example, earlier versions of .NET have a "Trust Level" that can be set to control how much access a program has when it's run (newer versions have a similar feature called Code Access Security (CAS)). Java has policy files that control the same thing.
Another method that may be helpful is to run the program using (Microsoft) Sysinternals process monitor, while scanning all operations that the program is doing.
If it's developed by a third party, then it's very difficult to know exactly what it's going to do without reviewing the code. This may be more of a contractual solution - adding penalties into the contract with the third-party and agreeing on their liability for any damages.
sign it. Google for 'digital signature' or 'code signing'
If you have the resources, use a virtual machine. That is -- usually -- a pretty good sandbox for untrusted applications.
If this happens to be a Unix system, check out what you can do with chroot.
The other thing is that don't underestimate the value of thorough testing. you can run the app (in a non production environment) and verify the following (escalating levels of paranoia!)
CPU/Disk usage is acceptable
doesn't talk to any networked hosts it shouldn't do - i.e no 'phone home capability'
Scan with your AV program of choice
you could even hook up pSpy or something to find out more about what it's doing.
additionally, if possible run the application with a low privileged user. this will offer some degree of 'sandboxing', i.e the app won't be able to interfere with other processes
..also don't overlook the value of the legal contracts with the vendor that may often give you some kind of recompense if there is a problem. of course, choosing a reputable vendor in the first place offers a level of assurance as well.
-ace

telling Windows from Linux (via network)

I am doing a research on how someone can detect whether another machine is running Windows or Linux, if it runs inside a virutal machine, if it's behind NAT\proxy\VPN and what not.
I saw some interesting tools like p0f, which does passive detection.
Basically, I know there are implementation differences in TCP and other underlying protocols, not to mention application level stuff that exist on Windows and not Linux, but I can't find any, and worse still, I really do not know what terms to look for in Google.
Do you have links or tutorials explaining what to detect to differentiate Linux and Windows?
This is not a subject about which I have a great depth of knowledge but try looking for "TCP stack fingerprinting" and also have a look at nmap's source code. I believe nmap is capable of using stack fingerprinting which involves testing for differences in TCP implementation in order to attempt to determine the environment on a host.
I've not used nmap to any great extent so I can't vouch for the quality or accuracy of it's implementation, but source code is available.
For the web, the differences between web browsers are fairly extensively documented. One example of a difference between browsers is the way in which an XmlHttpRequest object is created. By trying to instantiate an XmLHttpObject in different ways and testing which ones succeed, you may be able to determine the browser or JavaScript engine running the code.
here - http://nmap.org/book/osdetect.html
It's all been done before. How about starting with nmap?
Nmap -O is great for detecting systems operating systems by probing.
p0f is another tool that can be set in listener mode, and detects the operating system on systems that make connections to you.

Resources