I've heard of sandboxes for a while now. From what I gathered a sandbox is a directory which the program assumes is the root directory. Anything a service requires needs to be available from there. I was wondering is there a way for a program to get out of this area and gain access to the rest of the system?

Also I recently found a program for Windows called Sandboxie which seems to do something similar except slightly different. Rather than having to create a separate area for the sandbox the sandbox uses the real root and does almost a layer effect. For example, the program can add/delete files but it doesn't affect the real system. Like layers the OS is underneath the layer it's using. It can read contents from it but when it modifies anything the sandbox has a directory which it uses to keep the results. For example if you add a file to C:\downloads it will create a directory called c, then downloads, then the file in question under this directory. The program would see the top layer and think the transaction happened but it never touched the system. You can delete the contents at any time and the next time you run the program it would be reset to how your real system is. I use this to run my browser. I use Delicious to keep my bookmarks and since it doesn't reside on the system I don't have to worry about losing any bookmarks. I was wondering is this how most sandboxes work or is it only common to Sandboxie because it seems much easier to set up than having to create a seperate directory which contains all the programs and dependencies? I also think this would be safer because if you only had a few files in a directory it might tip someone off they are in a sandbox.

Less is more. If the sandbox is a good one, and it's configured properly, then it's *reasonably* secure (nothing is ever truly secure...sandboxes are no different). Having less in the sandbox means less stuff for the potential attacker to play with, meaning fewer chances for an exploit that would allow priv. elevation or breaking out of the sandbox.

Some things to keep in mind: run as little code as possible with root priv. turn off everything that isn't *critical* to the system's intended use. use a firewall to restrict access to services. sandboxing, while potentially useful, can present problems (notably a false sense of security).

As for the Windows sandbox you mentioned, it sounds very similar to Windows file system handling, only doubled over again...(Windows already does a similar trick, which makes it relatively easy to hide rootkits and other malicious code from users (only, in the Windows built-in you *can* modify files on the filesystem through the "sandbox")).

Bottom line is that the individual responsible for the machine *must* be paying attention...

A chroot jail will often be run in a restricted shell and the service running will not be run as root to make it harder for someone to escalate to root.

I think the term sandbox is more often used to refer to java web applications.

Under Windows I use to run as a limited user but Windows isn't designed well for this and can cause weird problems even when you elevate privileges for a program. Instead I started using a program (DropMyRights) which runs a program under limited rights. I append it to my web browsers and run them under limited rights. When I need to run a program I don't trust (Like a keygen) I have a dummy account which belongs to no groups. I modify the permission on the executable to give it rights for the account and run it, if I run into permission errors I know it's trying to do something it shouldn't. I knock off all unnecessary services and modify some services to run with limited accounts. I go in and give the least permissions possible for that service to run properly.

Under Linux I disable remote root through SSH and I set it up that the only accounts that can su into root are members of the wheel group (which I create. Some distros actually set up the root group as wheel instead). I knock off unnecessary services as well as well as run services using limited rights. I also use Bastille to harden it. I use sudo for almost everything. These are my must haves and are done whenever I set up a Linux machine. If I really was paranoid I could do a lot more.

I don't run machine firewalls I use my router's strictly. It seems like overkill to use machine ones as well (I'd rather another hardware firewall) and then you have to worry about permission errors. Granted I'm running on small local machines so I'm not very worried about being targeted.

rocket357, I'm a little confused by the comment on Windows file system handling. What does Windows do that makes it easy to install rootkits similar to how the sandbox tool works. If you mean unrestricted access Sandboxie does that but with Windows malware has the option of booting with the system so once it's installed it can easily set itself to run. It can also corrupt critical system files that can cause the BSOD. Even if it writes to boot with Windows in the sandbox that part is never loaded in the sandbox because the system is already up when it starts. It would need to attach itself to something the program would need access to to even have an effect. Even if it somehow deleted critical system files if the program didn't touch them the program should be unaffected and the real OS isn't using them so it shouldn't matter. Plus if you clear the old data out all the traces of the corruption are cleared out.

I'm still wondering how a service can gain access out of the sandbox from a logic standpoint. How is this done? Also if you use a package manager, like apt-get how do you get updates and such into the sandbox? What about dependencies that are required outside the sandbox and inside. I would think this would be very difficult to do. With the amount of dependencies in Linux programs this seems like it would take forever.

I didn't say it made it easier to install rootkits...I said it made it easier for rootkits to hide information. The manner in which Windows "abstracts" the underlying filesystem is what I was referring to...

A bad comparison, really...but what I was getting at is that only administrators in Windows NT have RAW access to ntfs drives. Rootkit Revealer works on this premise...it compares low-level RAW data to what Windows is reporting on a high level. User accounts won't see the "real" (RAW) data from the ntfs drive...they see a high level abstraction of it. I realize that modern operating systems cache filesystem information, Linux and *BSD included, but Windows seems to intentionally leave information out, as not to scare off "power users".

The sandbox program that was brought up also "abstracts" the filesystem information, as it reports the information to the program, but intercepts it before it gets back to the real filesystem. It caches the information in memory and uses that until the program is reopened, in which instance the actual filesystem information is available again.

Perhaps I misunderstood the description of this program, but that's what I gathered.

>>> I'm still wondering how a service can gain access out of the sandbox from a logic standpoint. How is this done?

Buffer overflows generally.

Sandbox, chroot, same difference really at the top level though different in implementation.

A chroot plays with the concept of directories and / being the upmost directory. Now, if you present /achroot as being / to most applications they will assume that /achroot is /. And won't go looking elsewhere.

Buf of course, if there is a program included in the mix that ignores the file hierarchy and instead looks at the raw disk information it can bust out. So, further blocking is required, in that particular instance access to the low level file system itself requires blocking.

Once in a chroot or a sandbox, you may have extra privileges than not being in that location such as trust on the IP.

A sandbox has to filter everything, and as such there will generally be ways to include commands that avoid the filter - SQL injection techniques are similar here, with a chroot you are looking at blocking low level disk access really so less chance something will go wrong.

Such a program would require root access. Also chroot jails are created for a single purpose, such as a web server or database, so you need to include in the jail's filesystem hierarchy only what the program need to run. Including a SUID program would be a pretty dumb then to do IMHO.

Chroots aren't so general purpose. Only one application such as MySQL or Apache2 is run from it under it's own name instead of root. So only the program and system files needed to run that service are contained in the chroot hierarchy.

The jails purpose is to contain a hacker who is successful in a buffer overflow attack or other attack on a service, and restrict the damage and rights that such a person would have.
You would still need to do other things such as use quotas so that an attacker in a jail couldn't steal all the resources crashing the host itself. Also you need to track the the programs in the jail for any security fixes. It should be easier doing this for the programs in the jail because it is a small subset of the programs on the host.

It may be easier for a hacker to do an end run and ignore the jailed service altogether, instead attacking another vulnerability of the server. I read where a hacker was able to get in to a network through a remote user in a delivery truck using pcanywhere for around 5 minutes at a time. He got in through the phone company to the guys laptop and guessed a weak password. You only need to make a single mistake. The hacker can use trial and error, making many mistakes.

A chroot jail is a miniture version of a system, with system directories such as /bin and /lib. A sandbox is a specialized virtual environment running another type of system, i.e. Java scripts or javascript scripts rather than looking like the OS.
A sandbox is an environment for running scripts whereas a chroot jail is where a service runs.

A chroot jail is something you would have at the server end. A sandbox is what you would find on a client.

Thank you all for your tips. I"m looking them over and will keep them in mind. I notice some people now are turning to programs like VMWare to run their servers since these act like seperate computers on the network. Is this a better option than chroot?

If an application exploits a local priv escilation vulnerability, then it can be root(some vulnerability in the kernel).

Depends upon the file system - if the file system only allows root then there is your block.

Now note also that other programs are included the kernel is one of them, as is the chroot itself there are others and even without a suid'd app there is the possibility of a breakout.

No, chroots often come with many applications - one use is to run let's say Apache, but of course Apache can access applications such as grep, mod_php, perl, all in the chroot etc. Those are all programs.

So yes, chroots are general purpose, and it revolves around the concept of creating a special root directory.

Many people use them as guest account areas.

Not always, think of the guest account scenario. Think of the SQL injection. Containment via the / is the way though.

Quotas are useful perhaps, but better is partitions. The chroot should be partitioned. Quotas really come up in the concept of multi users, there are other mechanisms that allow for a segment of drive space to be reserved for root.

Anyway the point is the general way of breaking out of the jail is via a buffer overflow - the jail itself may be breached into via a buffer overflow as well but you can use a buffer overflow more than once. And as stated above it is not just suid'd applications in the chroot you have to worry about.

Server and client is not really a distinction in this matter, a sandbox uses perhaps heavier filtering and chroot tends as I say to use the concept of / as the filter. You could use either for applications considered to be a server and applications considered to be a client.

See, you could run an install program in a chroot that is a client program and you might wish to do this to protect your system from a rogue install - perhaps for virus reverse engineering.

And you may wish to run a server application in a sandbox, perhaps on a shared system.

The most common use of a chroot is to install operating systems. That is not a server based idea. The idea is to use the filter to determine if the operating system is near complete.

The point is a chroot is a sandbox both of sorts, distinction exists for normal parlance, you could think of a chroot as being a specialised sandbox though.

VMWare works like a more generalized sandbox, it may also have elements of chroot idea in there.

But, with VMWare you start up a VMWare kernel which in turns starts up the other operating system kernels, note they don't generally replace the kernel of the VMware they all work through it.

Now its job is to allow interoperability or deny it, it is vulnerable to the same attacks on a chroot or any sandbox and may introduce more vulnerabilities, due to complexity.

A chroot is a handy line of defence - it is not the be all and end all - but it is fairly simple and most security problems can be worked around - that is to say the idea is not so complex it introduces more vulnerabilities then it protects from. It can also be used for other purposes than just security - though that is the main reason for introduction outside building an operating system.

VMware is used primarily because you want to run multiple operating systems on a host, for testing applications, perhaps for running other applications. Security is a bolt on to this idea, and is not the place it stems from.
I would bet it introduces more vulnerability then it prevents.

I suppose you have to think what you are trying to achieve. Security for security sake is not a use of a computer system (unless you are trying to learn, but even then you should put it in context). If only firewalls, or virus scanners existed as software then we would all be doing nothing with a computer, well apart from configuring them.

So, why do you want a chroot? Why do you want Virtualization?

The reason people use VMware on servers is to allow people to have an operating system of their own.

A chroot comes works with the existing kernel, so that does not change.

VMware comes with it's own kernel but all the instances come with a kernel as well which works through the VM kernel.

My systems aren't about security for securities sake but I'm always looking for new and better ways to do things. One thing I liked in BSD (which for some reason hasn't been ported to Linux) is secure levels. The concept is the computer runs at a level from -1 (off) to 2 (very hardened). Under BSD (and Linux) you have chattr flags which include immutable and append only (among others). If you make a flag immutable (for example) not even the root user can modify it. However, it's easy to turn back off. In BSD if you are in level 1 or higher you can not turn them off and you need to reboot your machine into a lower level to drop it, it can't only be raised on a running machine. There is a workaround I found in Hardening Linux. There's a utility called LCAP. It will allow you to turn off an chattr flag and it can't be set or removed. It only takes effect until you reboot the machine unfortunately. However, you can create a script to set it to run automatically. The only run level I shut it off in is single user mode with no networking. This can be quite useful and if you want to protect log files you can make them append only. This will make it impossible for someone to remove their tracks.

My first comment to this kind of a discussion is always the same: when done in the context of security, chroots are just a layer. These are not the best layer - and certainly should not be the only layer. Nothing prevents one from running a chrooted program in a system running SELinux, say.

Then few quotes.

Chroots do not come with anything: these roots include just the things you put into them.

While I generally agree with Zention (e.g. my daily usage of chroots involves testing of full systems in those roots), I would here follow jschiwal; if the aim is some kind of a security, the given chroot should not include any other binary than the deamon running. As you know, a typical small deamon does not require much in addition to that binary.

If, further, some chroot restrictions, such as those provided by Grsecurity, are in force, it becomes very difficult to escape from such a root, and I would certainly like to see a working example on how to break from such a root.

But surely, in vanilla-systems "breaking out of a chroot" is a classical example in some textbook.

This of course is the more fundamental argument. Here we come again to the layers, although as an argument, this only proves that in theory we should not trust in any mandatory access control mechanism whatsoever.