Slashdot Mirror
Secure Services on Virtual Machines?
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."
and OS version of auto-update? Just kidding...
Neck_of_the_Woods
#/usr/local/surf/glassy/overhead
You've got chroot. Both sandbox the server from the rest of the system. Chroot is just a lot easier to make performance-efficient.
May we never see th
Beware, Nugget is watching... See?
Just hope the client doesn't take the red pill. I'd think a virtual machine would be more vulnerable, as there is potential to trick it to run code "outside the box".
Karma: Excellent (fuck, even in the future moderation doesn't work!)
Is this what you're looking for?
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.
Isn't Trusted Solaris basically just this? At an OS level, you associate trust levels that permeate throughout your network. Two (or more) people can work on the same box at the same time and view completely different boxes because of their trust level. One trust level can't talk to or look at another's processes without the proper authorization. Like Unix file privs only much, much more controllable.
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
java
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.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
ISO Pascal requires all array accesses do boundary checking (although most compilers let you disable that for performance reasons).
Do you even lift?
These aren't the 'roids you're looking for.
A VM won't give you any security that you can't get from the OS, because it will still need to have access to things to do its job. That means that a hole in the VM or the program it's running can be just as bad as a hole in a C program.
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 collection. You should be able to easily find these sorts of things written in Java or Python by doing a search on Sourceforge. Replace all your services with the ones you find, and you're done.
If tits were wings it'd be flying around.
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.
Method of processing duck feet
Monolithic, buggy programs like sendmail will always be a security nightmare. That doesn't mean that secure code can't be written in C. qmail, for example, is completely secure. If more programmers followed good coding practices, we would see fewer security disasters. A good start would be to stop using C strings and to start using the stralloc concept.
chrooting can accomplish much of what you want. Even if the process in question has an exploit, it is used, and the process gets compromised, the damage is contained to the chroot jail. And it's easy to find chrooted versions of popular (vulnerable) services. ftp, httpd, probably even sendmail.
Just because you are running a VM doesn't mean too much - in fact, it may be a bad thing, as security becomes less of a concern (no need to upgrade, doesn't matter if I am hacked).
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 java) a non-too-impossible attach on the machine it is running to randomly corrupt memory could be used to compromise the underlying system. See the recent paper by Appel and Govindavajhala.
Which isn't to say I don't think this is a great idea. Writing your servers in a safe language is the easiest way to avoid rampant overflow errors, making jsendmail that much harder to compromise.
Also, don't forget that all those malformed-request attacks against poorly written PERL CGIs that fail to validate strings passed to a subshell: perl runs in a VM, but does no good when the attack slips by the VM to the base hardware.
I hope somebody takes the time to audit the VM. No, I hope a lot of people take the time to audit the VM.
use openbsd, base system (with httpd, sendmail, named, ...) is audited:
3.3 as stack protection, propolice,W^X, and more
see openbsd.org & misc@
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 things can be, and are, done in native code. The VM is not what makes your code safe, it's what allows you to check a binary that you download to make sure it is safe. If you're compiling the code yourself, you can easily target native code and pay very little performance overhead.
For instance, mlton (mlton.org) is a high performance native code compiler for Standard ML. It doesn't use a virtual machine, but it's impossible to write code with exploitable buffer overflows, integer overflows, double-frees, etc.. (In my opinion, it's also a much cooler language than C or Java). O'caml is another good language in the same family that can target either bytecode or native code. There exist native compilers for Java, though I've never used them.
VM => portable byte code.
safe language => secure code.
Be wary of people who tell you that all we need is properly written C code. The days of grepping for "strcpy" are long gone -- the new age of exploitable holes are trickier things, usually living in hand-written parsing routines. C programmers will always have to live with buffer overflows, integer overflows, and double-frees.
> 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.
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 to run "safe" languages that rely on static type checking for safety (such as java) a
> non-too-impossible attach on the machine it is running to randomly corrupt memory could be used to compromise the underlying
> system. See the recent paper by Appel and Govindavajhala.
This is a total red herring. The situation described in their paper is where the attacker gets to supply the program (and also has the ability to induce memory faults on the target). While I might buy the argument that memory faults happen randomly as well, the attacker surely doesn't get to install his own trojaned jsendmail on my computer. (If he did, he could do a lot more damage anyway!) A C program is equally dangerous on a computer with faulty memory--Appel's paper is irrelevant in this scenario.
> Also, don't forget that all those malformed-request attacks against poorly written PERL CGIs that fail to validate strings
> passed to a subshell: perl runs in a VM, but does no good when the attack slips by the VM to the base hardware.
I'm with you here. perl is "safe" in some sense and is interpreted, but is still susceptible to easy security holes. I think this is mostly due to its interpreted and highly dynamic nature, as well as due to some misfeatures in the language (allowing "|/bin/rm" as a filename, etc.). In my (informed, but not substantiated) opinion, statically-typed compiled languages are not typically susceptible to easy-to-make security holes like these. (For instance, to spawn a process in SML, you give the path to the process, and a list of its arguments -- there is no shell globbing to screw up.) I really think that such languages would go a long long way towards making more secure computing environments, and in fact they don't need to run in a VM (see my other post), giving us the best of both worlds!
There's a lot of confusion on this thread as to why you'd *want* a virtual machine when you can always just run your servers with isolated privileges. Good question. I'll take a stab at that:
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 where a VM comes in. Obviously, a buffer overflows exploit doesn't instantly get you root if you're using the exploit on a server running as user www. But most buffer overflows don't work that way; instead, one uses that exploit to tweak some part of the system which the server might perfectly well need access to, in order to open a wider door.
No amount of privilege-futzing can prevent buffer overflows, stack smashing, etc. Setting privileges is good because it contains the damage, but a virtual machine may also be good, because it prevents much of the damage in the first place. That's one of the things I like about programming in Java: private members are truly private, and it's physically impossible for other code to access them, except as I expose them. If I design objects with a tight, well-defined contract, then I get automatic closure of that contract over all interactions with all other objects, guaranteed. And of course Java isn't the only language that offers guarantees like this.
So I think the author has a point: why not sacrifice some of the raw speed of C++ for security when 20% slower performance is acceptable?
(Of course, VMs can't fix the logical errors that invariably crop up in messy code; programmers unfortunately still have to think about what they're doing!)
I am constantly amazed that there is no discussion of hardware enforced bounds checking. This isn't anything new, some architectures had it in the '70s. It can be done (with a little difficulty) in x86 architecture(or so I have read). It WOULD mean that C programmers couldn't play so fast and loose with pointers, but that would be a good thing, IMO. This discussion isn't new either.
5 .h tml
http://bugtraq.inet-one.com/dir.1998-07/msg0021
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
Uhm, so what happens when someone compromises apache and replaces your website with the goatse guy?
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...
Only on slashdot can a posting be rated "Score -1, Insightful".
> That's one of the things I like about programming
// Make it accessible
// Read it
// Change it
:)
> 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'});
(to non java peeps, this will make the private field in the String class accessible, read it, and then change it via reflection)
I do agree whole heartedly with the point you're making though!
Wow. I am flabberghasted. That's utter nonsense, and it works!
Does anybody know if Sun has released a recommended "high security" configuration for a security manager?
When i was in university we used to prove our code - it was hell, box logic diagrams recurrring over each other with an in-out structure down to a central point. Now this was at a pretty fundamental level. We could use libraries as one of these central points...
Note, when I mean proved, I mean one input results in one output, using mathematical proof, which therefore cannot be got around (randomness could exist within this mathematical framework).
Damn, don't get me wrong, I know this will be damn labour intensive and hardware specific. But isn't a one-off investment worth it if this hardware-software solution can last a sufficient period of time?
So why not prove your programs are secure, bottom up building on proofed instruction sets (though these are system-specific) gone before. C could be seen as just a language to write in which would then be compiled over these proved-secure components.
You could use virtual machine (suggested in previous posts), a virtual machine which had been proved before, so anything which runs on it cannot get below this unhackability...
The fact is, it is possible to prove code, it is possible to have unbreakable/perfectly predictable code. It is just damn hard work and very hardware specific. The main thing I see is the cost of investment on hardware which quickly moves on, needing a new proof... this is just a theoretical solution. [you could have an increased cluster of older hardware to give extendability].
I see lots of post that various stuff is better or good enough. I think that's missing the big picture. A truly secure system doesn't rely on only one security methodology.
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 built that has named built with stackguard running in a chroot session.
Hack detection is much harder to fool. I.E. have the main OS run tripwire against the VM. So the tripwire database isn't stored on the VM disk image...
Recovery from a hacked system is easier. It's just a matter of taking the backup copy of the original VM image, installing a patch to fix the exploit and putting the service back into operation. This is certainly much easier than rebuilding a server.
Using multiple VM sessions also means that installing patches, security or otherwise to one VMs services isn't going to screw up the other services. This is of course real handy for testing.
When I read this I thought of Valgrind. It's a program designed to find memory management problems such as memory leaks and using unitialised memory. The program being tested runs under Valgrind so it is very much like a virtual machine. I've never thought of running a server under it, but if you can stand the (probably substantial) performance hit it would probably do what you're intending.