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."

Comments

Why do you need a VM?

[0x0d0a]

You've got chroot. Both sandbox the server from the rest of the system. Chroot is just a lot easier to make performance-efficient.

Re:Why do you need a VM?

[Webmonger]

Yes, something does need to be secure.

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 VM is that you don't have to worry about someone getting a local logon through non-root Sendmail and then using privilege escalation exploits to get root on your whole box. The most they'd get access to would be your mail system.

Anyhow, security isn't black-and-white, and defence-in-depth is a reasonable technique. VM+NOSUID+CHROOT would be a very secure config.

StackGuard

[drdink]

You might want to check out StackGuard:

StackGuard is a compiler that emits programs hardened against "stack smashing" attacks. Stack smashing attacks are the most common form of penetration attack. Programs that have been compiled with StackGuard are largely immune to stack smashing attack. Protection requires no source code changes at all.

Re:StackGuard

[Matt2000]

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?

User-mode Linux

[quakeslut]

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.

A VM is only as secure as the OS it's running

[Deagol]

Unless I misunderstand your post, I don't think isolating an application inside a VM will do all that much good. I mean, I can run Apache on Red Hat under a VMWare virtual server. However, it can still be broken into the same as a real machine.

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.

Writing secure software

[Electrum]

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.