| 1 |
> Well, this gets at my original musing...... are you really |
| 2 |
> safer with a |
| 3 |
> grsecurity-hardened-chrooted VMware application (with root |
| 4 |
> privileges, |
| 5 |
> that uses at least some of the host's kernel) or a |
| 6 |
> grsecurity-hardened-chrooted program with no privilege and only the |
| 7 |
> additional executables necessary to keep it running. |
| 8 |
> |
| 9 |
> And if the answer is yes, are you significantly safer? |
| 10 |
> |
| 11 |
> In one sense there'd be a thicker layer between the host and |
| 12 |
> the server, |
| 13 |
> but in another sense the added complexity and root host |
| 14 |
> privilege may add |
| 15 |
> vulnerabilities? |
| 16 |
> |
| 17 |
> (Sorry if this is foolish...... the answer seems less than obvious) |
| 18 |
|
| 19 |
Well, let's say the uberhackers crack your box and rm -r /*. How much is |
| 20 |
your time worth rebuilding from scratch? If the VM has been cloned, you just |
| 21 |
restart with the old VM. Takes about 12 seconds. |
| 22 |
|
| 23 |
Within that VM, you still have the option to run a hardened kernel or just |
| 24 |
chroot your services. |
| 25 |
|
| 26 |
The security angle is still a function of the inherent security of the |
| 27 |
service. If your creaky FTP server hasn't been patched in two years, that's |
| 28 |
probably the weakest link. If the OS affords a buffer overrun to occur, |
| 29 |
that's a more generic solution to ANY process on the system. Finally, it's a |
| 30 |
probability calculation between these factors. If your service is widely |
| 31 |
accessible, it's going to get hit more often than a protected one. |
| 32 |
|
| 33 |
At the ultimate step, the uberhackers 0wn your box. Will they be able to |
| 34 |
crack their way out of a process that provides them their OS? It's easy to |
| 35 |
detect that you're living inside a VMWare VM, but why would you care? Why is |
| 36 |
the REAL OS any better? |
| 37 |
-- |
| 38 |
gentoo-hardened@g.o mailing list |
Archives