From: Primero <pr...@fa...> - 2004-06-29 12:56:52
|
Ok, Talking with a friend i was wondering about UML impact on security of my Host Machine. I'm running a couple of 2.6.6 UML virtual machine on a 2.6.6 Host Machine serving like Mail Server and Syslog centralized server. I was wondering about secuity risk ... Ok, the System is a stadalone machine and any kind of compromise would affect only the attacked machine, but what about Guest Kernel-Host Kernel Comunications? Could these be used to compromise the Host machine and in this way all the Uml Environment? What do you do to car about you Uml Env security? thx bye -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
From: James N. <jn...@nk...> - 2004-06-29 17:48:27
|
Primero wrote: > Ok, Talking with a friend i was wondering about UML impact on security > of my Host Machine. > > I'm running a couple of 2.6.6 UML virtual machine on a 2.6.6 Host > Machine serving like Mail Server and Syslog centralized server. > I was wondering about secuity risk ... > Ok, the System is a stadalone machine and any kind of compromise > would affect only the attacked machine, but what about Guest > Kernel-Host Kernel Comunications? Could these be used to compromise > the Host machine and in this way all the Uml Environment? > > What do you do to car about you Uml Env security? The risk is non-zero, but I believe it's pretty low if you set your system up correctly. In my environment: - Each UML is locked in a chrooted jail with permissions locked down as tightly as I can (described at: http://umlazi.org/2004/06/26/jail-security/) - Each UML runs as its own (non-root) user. - Each UML is individually firewalled by the Host. Only _strictly_ limited packets are allowed in and out. [ The released version of http://www.umlazi.org/ takes care of the first two. If you want the integrated firewalling, I can give you a CVS build.. ] Now, there are still some risks. If an attacker gets root inside the UML, you have to assume they can make the UML kernel do whatever they want. The jail should prevent most privilege-escalation attacks, but there are still several DoS possibilities: - If you oversubscribe your disk space, they could potentially fill up your host's disks, causing mayhem. - They could create a bunch of "tun" interfaces. After about 100,000, any program that gets a list of interfaces (say, "ifconfig -a"), gets really, really, REALLY, slow. - If there are vulnerabilities in your host kernel (like the ptrace bug in pre-2.4.22), or vulnerabilities in your processor (the F00F bug) they could exploit it and crash your machine. -James |
From: Erik de B. <Erik@BudgetDedicated.com> - 2004-06-30 18:40:13
|
Hi, We offer UML comercially in a strong European network. Security was our main issue when starting up our business. An important addition I believe: I've mounted the root_fs and other files except for the kernel itself in a noexec filesystem. The kernel is only executable and not writable. HostFS is not compiled in the kernel. Gentoo SELINUX extention will probably contribute to security a great deal... -- Kind regards, Met vriendelijke groeten, Erik de Bruijn BudgetDedicated www.BudgetDedicated.nl | Tel. +31 492 430559 | Fax. +31 492 663870 | Mob. +31 6 21856715 | Adres: Haagwinde 16 | Zipcode NL-5731 WD Mierlo On Tue, 29 Jun 2004 13:48:16 -0400 James Neal <jn...@nk...> wrote: > Primero wrote: > > > Ok, Talking with a friend i was wondering about UML impact on security > > of my Host Machine. > > > > I'm running a couple of 2.6.6 UML virtual machine on a 2.6.6 Host > > Machine serving like Mail Server and Syslog centralized server. > > I was wondering about secuity risk ... > > Ok, the System is a stadalone machine and any kind of compromise > > would affect only the attacked machine, but what about Guest > > Kernel-Host Kernel Comunications? Could these be used to compromise > > the Host machine and in this way all the Uml Environment? > > > > What do you do to car about you Uml Env security? > > The risk is non-zero, but I believe it's pretty low if you set your > system up correctly. > > In my environment: > - Each UML is locked in a chrooted jail with permissions locked down > as tightly as I can (described at: > http://umlazi.org/2004/06/26/jail-security/) > - Each UML runs as its own (non-root) user. > - Each UML is individually firewalled by the Host. Only _strictly_ > limited packets are allowed in and out. > > [ The released version of http://www.umlazi.org/ takes care of the first > two. If you want the integrated firewalling, I can give you a CVS build.. ] > > Now, there are still some risks. If an attacker gets root inside the > UML, you have to assume they can make the UML kernel do whatever they > want. The jail should prevent most privilege-escalation attacks, but > there are still several DoS possibilities: > - If you oversubscribe your disk space, they could potentially fill up > your host's disks, causing mayhem. > - They could create a bunch of "tun" interfaces. After about 100,000, > any program that gets a list of interfaces (say, "ifconfig -a"), gets > really, really, REALLY, slow. > - If there are vulnerabilities in your host kernel (like the ptrace > bug in pre-2.4.22), or vulnerabilities in your processor (the F00F bug) > they could exploit it and crash your machine. > > -James > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user |
From: Primero <pr...@fa...> - 2004-07-01 08:03:04
|
On Wed, 30 Jun 2004 20:40:01 +0200, Erik de Bruijn <Erik@BudgetDedicated.com> wrote: > Hi, > > We offer UML comercially in a strong European network. Security was our > main issue when starting up our business. Great :) i'm looking for job ... :) (just a joke) > An important addition I believe: > I've mounted the root_fs and other files except for the kernel itself in > a noexec filesystem. The kernel is only executable and not writable. > HostFS is not compiled in the kernel. Ok, but if you mount your root_fs in nonexec partition this apply only to the "Host" system or also inside the "Guest" Machine? Since if it would be so how do you USE your UML? I Think that UML , for is design, is good in security as a standaolne machine, even more with GRSecurity Chroot adds and a good ACL system ... the only thing i'm not able to understand and evaluate is about "Guest Kernel"-"Host Kernel" comunication and if it is a possible breaking in hole to the host system. i've not really well understood the relationship beetween Host and Guest so i was looking for a better information about. > Gentoo SELINUX extention will probably contribute to security a great > deal... Yes man, Tux rulez the world and Gentoo is the prophet ... :) (i'm drunk!) -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
From: David C. <li...@ed...> - 2004-07-01 08:34:15
|
On Thursday 01 July 2004 08:02, Primero wrote: > On Wed, 30 Jun 2004 20:40:01 +0200, Erik de Bruijn > > An important addition I believe: > > I've mounted the root_fs and other files except for the kernel itself > > in a noexec filesystem. The kernel is only executable and not > > writable. HostFS is not compiled in the kernel. > Ok, but if you mount your root_fs in nonexec partition this apply only > to the "Host" system or also inside the "Guest" Machine? Since if it > would be so how do you USE your UML? As he's mentioned he's not using hostfs I'd assume this means that it's only nonexec on the host. Inside the UML, it's a filesystem so the files contained within it would have normal permissions. As an aside, putting the root filesystem in a nonexec partition is only secure if the users don't have access to loopback mounting it somewhere else. This shouldn't be too much of a problem though, as normally only root can do it anyway. David |
From: Erik de B. <Erik@BudgetDedicated.com> - 2004-07-01 10:11:23
|
> As he's mentioned he's not using hostfs I'd assume this means that > it's only nonexec on the host. Inside the UML, it's a filesystem so > the files contained within it would have normal permissions. Correct. The issue is not the security of the UMLs themselves, but the layer on which UML runs, the User Mode process layer of the host OS. If it cannot get a payload on the system that it can then execute, the most important step to HOST OS security is taken. Good host OS security is also essential for subsequent guest OS compromization. > As an aside, putting the root filesystem in a nonexec partition is > only secure if the users don't have access to loopback mounting it > somewhere else. This shouldn't be too much of a problem though, as > normally only root can do it anyway. Loopback-mounting is a good point, but it's not an issue if a user cannot do mounting on the host system, indeed. I believe the interface to the host is pretty safe. But there may be an issue here: Loading kernel modules in an UML (GUEST) would run them in the UM-kernel's layer. But wouldn't it possible for tricking the executable kernel to run it on the host? The loadable kernel modules is still a bit vague to me, concerning UML kernels (I'm not a kernel-hacker yet... so maybe the question is dumb) -- Kind regards, Met vriendelijke groeten, Erik de Bruijn BudgetDedicated www.BudgetDedicated.nl | Tel. +31 492 430559 | Fax. +31 492 663870 | Mob. +31 6 21856715 | Adres: Haagwinde 16 | Zipcode NL-5731 WD Mierlo On Thu, 1 Jul 2004 09:35:18 +0000 David Cannings <li...@ed...> wrote: > On Thursday 01 July 2004 08:02, Primero wrote: > > On Wed, 30 Jun 2004 20:40:01 +0200, Erik de Bruijn > > > An important addition I believe: > > > I've mounted the root_fs and other files except for the kernel itself > > > in a noexec filesystem. The kernel is only executable and not > > > writable. HostFS is not compiled in the kernel. > > Ok, but if you mount your root_fs in nonexec partition this apply only > > to the "Host" system or also inside the "Guest" Machine? Since if it > > would be so how do you USE your UML? > > As he's mentioned he's not using hostfs I'd assume this means that it's > only nonexec on the host. Inside the UML, it's a filesystem so the files > contained within it would have normal permissions. > > As an aside, putting the root filesystem in a nonexec partition is only > secure if the users don't have access to loopback mounting it somewhere > else. This shouldn't be too much of a problem though, as normally only > root can do it anyway. > > David > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user |
From: BlaisorBlade <bla...@ya...> - 2004-07-03 16:54:02
|
Alle 12:11, gioved=EC 1 luglio 2004, Erik de Bruijn ha scritto: > I believe the interface to the host is pretty safe. But there may be an > issue here: Loading kernel modules in an UML (GUEST) would run them in the > UM-kernel's layer. But wouldn't it possible for tricking the executable > kernel to run it on the host? Well, the UM-kernel layer actually runs on the host, and so your module. > The loadable kernel modules is still a bit > vague to me, concerning UML kernels (I'm not a kernel-hacker yet... so > maybe the question is dumb) No, the question is not dumb. Well, this is a situation: =2D suppose that a cracker intrudes your UML and becomes root inside it. Ca= n it=20 hurt at the host? Yes, it can insmod a module and then this module, like th= e=20 UML kernel, runs on the host. So you must assume, when planning your=20 security, that if a cracker is root on your UML he can have local access (n= ot=20 as root) on the host. I.e., like you already said, good host OS security is essential. Well, a script-kiddie cannot do this (nobody wrote a such module), but it's= =20 not too hard to write the code. Most seriously, we have not yet started=20 seeing, on the Uml mailing lists, bugfix for potential security bugs; which= =20 means that there is a lot of ones. =2Dsuppose you build a kernel without module support (this reasoning applie= s=20 both to host and guest kernel); can you trust no module being insmoded? NO!= =20 There is still the /dev/kmem - /dev/mem port. Look on the net, it's a well= =20 known problem with well known fixes. However, I think that while for i386=20 Phrack explained how to do this, the procedure changes a bit for UML, and t= he=20 changes means that probably only an expert programmer can insmod through=20 /dev/kmem inside UML. =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Nick Craig-W. <ni...@me...> - 2004-07-04 08:23:23
|
On Sat, Jul 03, 2004 at 01:24:58PM +0200, BlaisorBlade wrote: > Well, a script-kiddie cannot do this (nobody wrote a such module), > but it's not too hard to write the code. Most seriously, we have not > yet started seeing, on the Uml mailing lists, bugfix for potential > security bugs; which means that there is a lot of ones. > > -suppose you build a kernel without module support (this reasoning > applies both to host and guest kernel); can you trust no module > being insmoded? NO! There is still the /dev/kmem - /dev/mem > port. Look on the net, it's a well known problem with well known > fixes. However, I think that while for i386 Phrack explained how to > do this And its now standard operating procedure for some rootkits... > the procedure changes a bit for UML, and the changes means that > probably only an expert programmer can insmod through /dev/kmem > inside UML. Multiple layered security is our solution 1) run the umls as a user (not root) 2) run them in a chroot 3) the user can't create any files or write to any executables in the chroot 4) disable hostfs/humfs 5) disable module loading 6) disable writing to /dev/kmem, /dev/mem (drop CAP_SYS_RAWIO) 7) ulimit the uml Not all of these are as easy to do as others but I've described how to do 2) and 3) (with patches and code) in previous posts and a patch for 6) was posted to the list also. 6) has successfully foiled rootkits too - its probably good practice for any linux server -- Nick Craig-Wood Tel: 0800 195 4968 Net: ni...@me... Memset Ltd Web: http://www.memset.com |