Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I was wondering if there is a tool or a technique to run an executable in an isolated environment, maybe in a virtual machine. While the program is running, I want to be able to audit the application, i.e. see everything that the executable is doing (file and network access).

By doing so I want to be able to check if the executable is malicious, i.e. performs operations which it shouldn't (read/write to files, listen on/connect to network ports, ...).

I wouldn't mind something with a graphical interface.

share|improve this question
2  
@EliahKagan: If I understand the question right, the OP asks for "a (tool) where i can see everything that the executable is doing" - imagine if you can run sandbox somebinary and the imaginary sandbox program would log all files somebinary read or written to, all IPs/ports connected to, data transferred etc. That would be a useful thing to have, I also would like to know if something like this exists (and, actually, without such tool observing a program running in a VM would be pointless as you can't say what it does there anyway). Good question. –  Sergey Jan 23 '13 at 10:47
2  
Relevant question on UL.SE I asked before: How do I monitor opened files of a process in realtime? (not just about files, also network) Remember that once you see it happening, the damage already took place. –  gertvdijk Jan 23 '13 at 11:38
2  
I asked a question on meta regarding closing this question: meta.askubuntu.com/questions/5871/… - I don't believe it should've been closed. –  Sergey Jan 23 '13 at 21:26
add comment

4 Answers

is a tool or maybe a virtual machine to run an executable inside it

Yes, this is called Application virtualization.

LXC (Linux Containers) is a commonly used tool to set this up. It allows you to set up completely separated network for this application and it "sandboxes" it into a sort of virtual machine, much like a chroot. This is mainly for security purposes (a "jail"), not really for auditing.

I think it's a little bit outside the scope of the question to explain the complete LXC containers as well as how to audit it exactly. Below is a little bit on how to get started, though.

While the program is running, I want to be able to see everything that the executable is doing (file and network access).

This can be accomplished using strace and I've asked the same question on Unix&Linux:

As answered there, it comes down to basically

strace -t -e trace=open,close,read,getdents,write,connect,accept command-here

Important: once you see it happening, the damage already took place.


LXC application container

From this article. It comes down to:

  1. lxc-macvlan.conf configuration file:

    # example as found on /usr/share/doc/lxc/examples/lxc-macvlan.conf
    # Container with network virtualized using the macvlan device driver
    lxc.utsname = alpha
    lxc.network.type = macvlan
    lxc.network.flags = up
    lxc.network.link = eth0 # or eth2 or any of your NICs
    lxc.network.hwaddr = 4a:49:43:49:79:bd
    lxc.network.ipv4 = 0.0.0.0/24
    
  2. Start it using lxc-execute:

    sudo lxc-execute -n bash-test2 -f lxc-macvlan.conf /bin/bash
    

Note that LXC offers both system and application type of containers. You're looking for application containers here.

share|improve this answer
1  
LXC is not ready yet and is currently unsafe. For example, /sys is not virtualized and changes made to /sys from the container are made to the /sys of the host. Doing a quick search on the Web, there are some articles that document how to "escape" from a container. LXC will be a good solution to the problem, but currently it isn't, and should not be used as a security tool. –  Andrea Corbellini Jan 24 '13 at 18:34
1  
By the way the example configuration posted does not make use of lxc.mount options. This means that the whole user's filesystem is accessible by the executable run. –  Andrea Corbellini Jan 24 '13 at 18:41
add comment

What you are looking for is a tool that shows how a program interacts with the system (more specifically, with the kernel). Programs interact with the system using syscalls. Examples of syscalls are:

  • open -- used to open a file;
  • read and write -- used to read/write from/to a file descriptor;
  • connect -- used to connect a socket to a peer;
  • many, many others (see man syscalls).

The point is: syscalls can be traced using ptrace(2). So, basically, you are looking for tools built around ptrace. One of such tools is strace(1), which is a terminal application that takes a command as an argument and outputs:

  • the system calls the program is calling;
  • the arguments used to make the syscalls;
  • the result of the syscalls.

The output is in a C-fashion. Here is an example:

$ strace cat test
execve("/bin/cat", ["cat", "test"], [/* 55 vars */]) = 0
/* ... */
open("test", O_RDONLY)                 = 3
/* ... */
read(3, "hello\n", 32768)               = 6
write(1, "hello\n", 6)                  = 6
read(3, "", 32768)                      = 0
/* ... */

There you see that cat test is opening a file named test, reading its content (hello) and placing it on the standard output.

strace can produce much output, so be sure to read its man page (man strace), especially the documentation of the -e output that will let you see just the syscalls you are interested in.

Unfortunately, I'm not aware of graphical or easy-to-use alternatives. If you want to look for them, ptrace should be one of your search keywords.


About the isolation, there are many technologies out there. Chroots, Linux containers (which are currently under development and incomplete), software virtualization and paravirtualization are the most used. However this is a topic way too large to discuss. I'd suggest opening a new question if you wish to have more details.

share|improve this answer
add comment

Take a look at AppArmor. You can add a limited profile for an executable and put it into "complain" mode, where actions will be permitted but logged, which I think fulfils your requirements.

But note that this isn't really enough. A clever malicious binary may be able to detect that it is under observation and not perform malicious actions except when it is not being observed.

AppArmor goes further than this and allows an application to forever be restrained to only approved operations. Apps that end up in the Ubuntu Software Centre ship with AppArmor profiles.

share|improve this answer
add comment

As you've identified, a virtual machine would be better to provide isolation, particularly if you have reason to believe that an executable is malicious in the first place. But even this isn't perfect, since vulnerabilities in the virtualization platform (both hardware and software) can be exploited by malicious code in order to break out. Here's an example of a real world virtualization vulnerabilty: http://www.kb.cert.org/vuls/id/649219

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.