Secure Services on Virtual Machines? 61
Matt2000 asks: "With the growing number of package updates that cross my inbox for my redhat systems, and with the vast majority being buffer overflows, or overflows of some kind doesn't it strike anyone that there must be a better way? Instead of spending time auditing every piece of software for mechanically preventable bugs, why isn't there a common, audited virtual machine that people can build net facing services on? I would guess that sshd, httpd, and sendmail would be good candidates to start, as they are the most common and the most exploited. And please don't freak out performance junkies, if you run a website that serves 70,000 people a second and need to run native apache, then do so. Just accept that it will be less secure."
So you want? (Score:2)
and OS version of auto-update? Just kidding...
Why do you need a VM? (Score:3, Interesting)
Re:Why do you need a VM? (Score:3, Insightful)
A good virtual machine, on the other hand, could let you have this level of security because the hardware is virtualized too. VMWare allows you to assign a number of different types of network interfaces to each VM,
Re:Why do you need a VM? (Score:3, Informative)
Well...that's true, if you're running a chroot jail with, say apache running as root. But if you don't have any suid binaries in the jail (apache is running as "httpd" or whatever) and your kernel is secure, it should keep you from putting a sniffer on the thing.
VMWare allows you to assign a number o
Re:Why do you need a VM? (Score:2)
Re:Why do you need a VM? (Score:2)
And using suid root + a VM doesn't give you much functionality that not suid root + no VM doesn't.
Re:Why do you need a VM? (Score:3, Interesting)
But there is functionality to be gained from VM+SUID root. Sendmail needs root to use port 25. It would be useful to create a virtual machine that just ran Sendmail, POP and IMAP. Most email users would only have accounts on that VM. Or it would be useful to have a virtual machine that just ran BIND.
I suppose you can use packet-filtering to remap port 53 and 25 to high ports (say, 8053 and 8025), so you don't have to run Sendmail and Bind as root.
But the other a
Re:Why do you need a VM? (Score:3, Informative)
Re:Why do you need a VM? (Score:2)
It's not so much isolating the services from the rest of the system, but making it possible to completely remove the chance of a buffer overflow type exploit. This means we don't have to waste our time auditing server applications for those types of holes (which seem to make up the majority), we can just audit the virtual machine once.
By virtual machine, I'm talking about a Java or
Re:Why do you need a VM? (Score:2)
StackGuard (Score:5, Interesting)
Re:StackGuard (Score:3, Interesting)
Could I compile existing software, like sendmail, with this and that would remove buffer overflow style explots? If so that's very interesting, how come the binary RPMs that Redhat and crew aren't already compiled with a tool like this?
Re:StackGuard (Score:1)
Yes that's what distributions like Immunix [immunix.org] do, but notice that even with the extra protection they offer they still update their packages everytime a new hole is discovered.
Stackguard isn't a magic bullet, and isn't gonna stop you from being 0wn3ed. Typically it just means that the released exploits won't work, and that's also the case for odd architechtures like Alpha - most of the released exploits are for intel, so avoiding that gives you as much protection as the stack guard compiler.
The same with th
Re:StackGuard (Score:1)
Unfortunately, it only protects against a certain (common) kind of stack buffer-overflow. It does not protect against heap overflows, integer overflows of most sorts, double-frees, printf-style attacks, etc. Unfortunately, many of the recent exploitable bugs have been of this sort. StackGuard does help some, but it wouldn't help as much as a virtual machine, or simply a safe language.
red pill (Score:3, Funny)
User-mode Linux (Score:5, Interesting)
quoted from page:
User-Mode Linux is a safe, secure way of running Linux versions and Linux processes. Run buggy software, experiment with new Linux kernels or distributions, and poke around in the internals of Linux, all without risking your main Linux setup.
User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software.
Re:User-mode Linux (Score:2)
That's not quite what I was getting at. User mode linux is a more safe way to run services that might suffer from overflow style exploits, but it still doesn't stop those exploits from occuring.
I'm looking for one place to prevent those exploits (in a VM), and then build secure services on top of that.
I think there is (Score:3, Informative)
Actually, trusted computing is a pain in the ass for standard development...we always wound up creating a super user program that can run stuff anything to get around priv issues during development. I can see using a system such as this post beta development or for production, but developing under it is a bitch.
--trb
Re:I think there is (Score:2)
I think this kind of approach is better than creating virtual machine sandboxes that still run the old weak UNIX security model. If someone 0wns your sandboxed apache, they can still likely cause
a DoS with it, or propogate worms, or pretty much anything really.
Good use of iptables and linux "capabilities" can help a lot with limiting what an application can do, but still don't g
Re:I think there is (Score:1)
Isn't Trusted Solaris basically just this? [...] Two (or more) people can work on the same box at the same time and view completely different boxes because of their trust level.
Plan9 has the ability to isolate 2 processes completely from each other, since all they have in common is accessed via the FS and mounts are process-specific in Plan9. Hurd presumably has the same ability given that it's based on the same principles.
The concept is a better one than Unix has - Unix has the FS in common between pr
A matrix of jails (Score:2)
How about a list of J2EE servers each in its own chroot jail and the apps executing in Java. How much security is too much???
I personally think the BSDs are secure enough, and if Sendmail is replaced with qmail and apache constantly patched, there are no worries. No need to go to such extremes for production environments. After all. Performance is an issue as well.
a better answer (Score:1)
ISO Pascal requires all array accesses do boundary checking (although most compilers let you disable that for performance reasons).
Re:a better answer (Score:2)
-fbounds-check
For front-ends that support it, generate additional code to check
that indices used to access arrays are within the declared range.
This is currenly only supported by the Java and Fortran 77
front-ends, where this option defaults to true and false respec-
tively.
Does rather decrease the utility of the thing.
Virtual machine (Score:1)
What you're really looking for is services written in a language that make buffer overflows and the normal security problems more difficult. That means that you're looking for mail servers, web servers, etc. written in languages with built in string types and garbage collec
Re:Virtual machine (Score:2)
You can effectively make a VM buffer overflow immune by auditing just the same as you can with any other program, but the difference is that then anything that gets writte on the VM is immune to that class of problem as well - a great gain in security.
A VM is only as secure as the OS it's running (Score:4, Interesting)
Still, there's some merrit to the idea that having each service isolated in its own VM. At least there's some partitioning, and one "captured" service may not interfere with another. Though I'd argue that you should do this same partitioning by using real hardware.
Here's what I do, and it doesn't require that much more overhead:
At the IP level, I use iptables for a default-deny setup. Nothing gets in or out unless I explicity account for it, logging everything that violates policy and then silently dropping the packet.
At the kernel level, I use the grsecurity patch to shore up generic, known weaknesses (stack smashing, buffer overruns), as well as the various randomizations of PIDs, socket numbers, etc. I tried using StackGuard and libsafe for this kind of stuff, but found them too troublesome (plus, grsecurity addresses most of this stuff).
At the application level, I chroot what I can. I then use tcp_wrappers (for apps that use it) in a default-deny config, plus any ACLs that the application itself manages.
Of course, I try to keep up with gaping security holes in services I run. However, I don't find myself scrambling out of fear that my boxes are in much danger when there is an advisory.
These many layers add up to a pretty secure box, that's functional and no more of a hassle to admin that a stock installation.
Re:A VM is only as secure as the OS it's running (Score:1)
That way even if somebody does compromise, say, named, they won't be able to screw with much. And since LIDS logs attempts to violate security, as soon as they try to, say, view the password file or alter the logs, I'll know about it.
Re:A VM is only as secure as the OS it's running (Score:2)
That's not quite what I was getting at. I was asking why things aren't run in a virtual machine that can provide one place to audit to protect against buffer overflows. Meaning that if you are 99% certain that your virtual machine is safe, then anything that runs on top of it will also be 99% safe from those types of attacks. This is in contrast to having to be 99% sure of each and every native mode application that you run on your machine.
This is the fundamental difference between trying to protect you
Re:A VM is only as secure as the OS it's running (Score:2)
The idea sounds pretty neat. But is sounds like a pretty tough challenge. You may just as well ask for a complete overhaul of the way unix systems work (all-powerful root account is evil, etc.). As others have pointed out, the best bet seems to be the various ACL
Re:A VM is only as secure as the OS it's running (Score:2)
Not quite. I'm not advocating user permission isolation or resitrction by the VM, just memory control. For example, in Java there are no pointers and all bounds checking is done by the VM, so buffer overflows are non-existant.
If you managed to hack the password on an app running on the VM you'd still have that user's level of access, but we can be fairly certain that hack would not occur as a result of an overflow style attack.
Re:A VM is only as secure as the OS it's running (Score:2)
What you are asking for cannot be done. Worse, it is a dangerous route to go down, because it gives an illusion of safety.
From a VM level you cannot know what a program it up to unless that program obeys certain rules. When dealing with x86 architecture (specifically), those rules are not sufficiently verbose to allow for the sort of checking you are after.
While a VM could intercept all stack access and prevent modification to the return address (presenting stack smashing attacks), it cannot tell if a
Writing secure software (Score:4, Interesting)
Re:Writing secure software (Score:2)
I don't doubt secure C programs can be written, but we must ensure that everyone that writes a C program does write them in a secure manner. However, if people write their programs to a virtual machine then all we need to ensure is that the VM is written in a secure manner. That will lead directly to a more secure now, and in case new applications show up that you want to run. You don't need the qmail security guarantee to prove that there aren't buffer overflows, you know that the virtual machine has th
CHROOT (Score:2)
Safe languages are not necessarily secure (Score:2)
Imagine a Java sendmail installation running on a JVM. I may be able to compromise jsendmail, and while this won't give me local root, I may be able to use the compromised sendmailer to implement social engineering hacks.
Also, if the VM is designed to run "safe" languages that rely on static type checking for safety (such as jav
Re:Safe languages are not necessarily secure (Score:2)
I totally agree that it's not a "solve-all" solution to the problem, I just was thinking it would be a way to greatly reduce or eliminate a whole (large) class of security problems in one step.
And yes, the programs are only as secure as the VM, but at least then you can focus on the VM for audits.
Mistaken reasoning (Score:3, Insightful)
> local root, I may be able to use the compromised sendmailer to implement social engineering hacks.
How do you expect to compromise jsendmail? If sendmail were written in java, then the 2 most recent bugs would not have been exploitable. Part of the point is that safe languages like Java are not vulnerable to buffer overflows, double-frees, etc.
> Also, if the VM is designed
Chasing your tail (Score:1)
There is no need to have a VM for safety (Score:2)
I wish people didn't (for whatever reason) equate Virtual Machines with language-level safety. It's true that Java was the first mainstream OO language with C-like syntax, but is this really the only experience that anyone has with safe languages?
Let me try to set the record straight: The features of Java that make it good for writing secure code are independent from the VM. Those features are things like array bounds checking, lack of pointer arithmetic, checked casts, and garbage collection. All of these
Re:There is no need to have a VM for safety (Score:3, Insightful)
This is complete bullshit. The Java VM is exactly what makes the language safe. Even if you use Java assembler you can't overflow an array boundary, because the VM knows what an array is, knows its limits, and executes the instruction to set an element of the array on your behalf. Most of the RuntimeExceptions and all of the Errors in Java are thrown directly from the VM, not from code libraries.
This means that you can take an arbitrary, untrusted Java executable and run it, and it will not be subject
Re:There is no need to have a VM for safety (Score:2)
You may wish to read my statement in the context of the entire post, rather than on its own. Use of pointer arithmetic makes it impossible for a tool for analyse a program and determine when it is behaving incorrectly. It is thus impossible for a compiler to automatically insert protective code that will prevent the program from being coerced into behaving badly.
At best you can annotate regions of memory to prevent overflowing them -- but within stricter typing you cannot determine what the correct cont
Re:There is no need to have a VM for safety (Score:2)
The VM is not what makes the *language* safe, unless by language you mean Java Bytecode. Java the language specifies array bounds checks and garbage collection, etc., and if you compile it natively, it is still safe. Why is this bullshit? (I happen to be resesarching programming languages for my PhD, so I do know what I'm talking about, here...)
> It is certainly quite possible to take any sufficiently constrained language and compile it to native code such that it is
> not susceptible to buffer overfl
Re:There is no need to have a VM for safety (Score:2)
The issues we are contending are based on the understandings of two concepts: what is Java, and what is a VM? These sound like easy questions to answer, but they are not.
Java does not refer to the grammer, nor does it refer to the VM. Java refers to a platform. The grammar, execution machine and a basic set of libraries are all included in the specification, and cannot be meaningfully separated without altering the behaviour of the thing we call Java. This is perhaps most clear when you consider that
Re:There is no need to have a VM for safety (Score:2)
It's true that the safety in a program is often manifest somewhere in the "runtime" or "VM". A good example is garbage collection -- surely, even in natively compiled code, there is a runtime system that implements GC. But stuff like array bounds checks are not necessarily part of this. For insta
Why a virtual machine? Why not just user perms? (Score:2)
The two are both excellent ideas, and are essentially orthogonal. Privileges protect a server's interactions with other processes and the rest of the system. They limit its use of the file system, network ports, and sensitive APIs.
However, permissions can't limit a program's interactions with itself -- and that's
Re:Why a virtual machine? Why not just user perms? (Score:2)
You neatly summed up the debate for me there. Most of the posts on here have confused user permissions with what I was getting at with the virtual machine angle.
Perhaps I wasn't clear enough by not providing an example, but as I'm a Java programmer too I didn't want this to immediately devolve into a language war. I don't need to have everything I run on my system be written in Java, but it'd be nice if they were on a common secured runtime.
Wow, that's starting to sound like
Re:Why a virtual machine? Why not just user perms? (Score:1)
> in Java: private members are truly private, and
> it's physically impossible for other code to
> access them, except as I expose them.
What you mean you can't do this?
privateField = String.class.getDeclaredField("value");
privateField.setAccessible(true);
String foo = new String("foo");
Object oldValue = privateField.get(foo);
privateField.setValue(foo, new char[] {'b', 'a', 'r'});
(
Re:Why a virtual machine? Why not just user perms? (Score:2)
Aha. (Score:2)
So you still have complete private field sealing, but only if you explicitly turn it on. It's more than a little disturbing that this permission is enabled by default. Still, I suppose if you're writing a security-sensitive server, you'll configure your security manager to be very secure.
Does anybody kno
Let me see if I get this straight (Score:1)
Whole lot of good that jail/UML/whatever virtual system did you then.
Either keep your software up to date, or turn in your sysadmin badge...
Good security is multi-layered (Score:1)
I think VMs are a very useful and valuable for setting up secure servers. But like most other aspects of security they don't make a secure system on their own.
They provide another method of isolation of individual applications that potentially have buffer overflows. There's no reason for example a user mode linux install couldn't be
Valgrind? (Score:1)