From: Lars Marowsky-B. <lm...@su...> - 2001-06-01 09:19:12
|
Hi, just before I leave for the party (I feel sorry for myself really ;), I stumbled across two more questions: - If I don't compile hostfs in, but enable module support, could the module theoretically be obtained from somewhere else and loaded, thus breaking security? I would rather compile netfilter and stuff as modules, but if that doesn't work out, I will just go with a monolithic kernel. - In the exact opposite direction: For simulating cluster environments on a single node, I would need the ability to "reach out" from one sandbox into the host system and kill another UML instance. ie, basically I would need a uml_helper which executed a particular command with arguments for me on the host system. How would I go about that? I am currently looking at running UML on top of LVM devices, so I can just redo my setups as I want. I think some performance could be gained if UML wouldn't do its own caching but instead allow the host to do consolidated caching, but I understand that is not easily possible because of interactions with journaled filesystem requirements, oh well. The installation of SuSE Linux into a root filesystem was mostly painless (would have been some blamage if I failed at that, eh?), but I am still investigating some issues why the system doesn't run like I think it should - most notably, I am seeing kernel crashes, but before I don't have time to provide proper debugging info, I will spare you from it... Cool stuff. My geek-o-meter is reading a very high value ;-) Sincerely, Lars Marowsky-Brée <lm...@su...> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl |
From: Jeff D. <jd...@ka...> - 2001-06-01 13:39:27
|
lm...@su... said: > - If I don't compile hostfs in, but enable module support, could the > module theoretically be obtained from somewhere else and loaded, thus breaking > security? Sure, at the very least, the user could grab a UML source pool, build the hostfs module, and load it. > ie, basically I would need a uml_helper which executed a particular > command > with arguments for me on the host system. How would I go about that? > ssh? Or do you want to do this without a network? > most notably, I am seeing kernel crashes, but before I don't have time > to provide proper debugging info, I will spare you from it... I would like to know about that. Stack traces would be nice... Jeff |
From: Lars Marowsky-B. <lm...@su...> - 2001-06-05 13:25:57
|
On 2001-06-01T09:53:24, Jeff Dike <jd...@ka...> said: > > - If I don't compile hostfs in, but enable module support, could the > > module theoretically be obtained from somewhere else and loaded, thus breaking > > security? > Sure, at the very least, the user could grab a UML source pool, build the > hostfs module, and load it. Hm, even given that UML runs as a normal user and can't really compromise system security, I would rather want to ensure that it isn't this easily circumvented. How "tight" is the security with regard to "breaking out" of the UML sandbox? Sincerely, Lars Marowsky-Brée <lm...@su...> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl |
From: Jeff D. <jd...@ka...> - 2001-06-05 15:37:39
|
lm...@su... said: > Hm, even given that UML runs as a normal user and can't really > compromise system security, I would rather want to ensure that it > isn't this easily circumvented. So, you don't enable modules or hostfs. > How "tight" is the security with regard to "breaking out" of the UML > sandbox? There are currently three problems that I know of, all pretty easily fixable: kernel memory isn't protected from userspace verify_area doesn't check for addresses in kernel memory lcall syscalls can be used to escape UML since they can't be ptraced - the fix is a new personality on the host that segfaults lcalls Having said that, UML is probably pretty secure right now since it is not widely known among the kiddies, so there aren't any attacks against it that I know of. Jeff |
From: Lars Marowsky-B. <lm...@su...> - 2001-06-05 15:46:00
|
On 2001-06-05T11:51:37, Jeff Dike <jd...@ka...> said: > > Hm, even given that UML runs as a normal user and can't really > > compromise system security, I would rather want to ensure that it > > isn't this easily circumvented. > So, you don't enable modules or hostfs. Well, modules can be considered useful for things like netfilter et al, but I guess even that can be compiled in statically. However, not loading a module doesn't protect against this - as the luser^Wuser can easily access /proc/kmem as he is root... ;-) > > How "tight" is the security with regard to "breaking out" of the UML > > sandbox? > There are currently three problems that I know of, all pretty easily fixable: > kernel memory isn't protected from userspace > verify_area doesn't check for addresses in kernel memory > lcall syscalls can be used to escape UML since they can't be ptraced - the > fix is a new personality on the host that segfaults lcalls Define "pretty easily fixable" ;) Are they on your radar? When it comes to kernel hacking, I don't hold up well, so you probably don't want _me_ to fix it ;-) > Having said that, UML is probably pretty secure right now since it is not > widely known among the kiddies, so there aren't any attacks against it that I > know of. Yes, and actually the worst what can happen is that the user becomes a normal user on the host system. Annoying, and open to all the usual exploits, but oh well. Sincerely, Lars Marowsky-Brée <lm...@su...> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl |
From: Jeff D. <jd...@ka...> - 2001-06-05 17:55:16
|
lm...@su... said: > as the luser^Wuser can easily access /proc/kmem as he is root... ;-) Yeah, I forgot to mention that one. That's item #4 - disable /proc/kmem and all other /proc and /dev/ methods of accessing kernel memory. > Define "pretty easily fixable" ;) Are they on your radar? They're on my radar. Even on my todo list :-) Maybe a day or two or work to do and to test. The lcall one requires a patch in the host. It's a trivial patch, but it will likely take longer than a day or two before you see it in the mainline kernel. > Yes, and actually the worst what can happen is that the user becomes a > normal user on the host system. Annoying, and open to all the usual > exploits, but oh well. If you care that much, you'll also be running UML under chroot as a user with nothing but a uid on the system. Jeff |
From: Lars Marowsky-B. <lm...@su...> - 2001-06-05 21:39:48
|
On 2001-06-05T14:09:22, Jeff Dike <jd...@ka...> said: > They're on my radar. Even on my todo list :-) Cool. So I am watching this space ;-) I am toying with the idea of writing a UML agent for FailSafe - restart the virtual server locally/on another host on failure... *g* > The lcall one requires a patch in the host. It's a trivial patch, but it will > likely take longer than a day or two before you see it in the mainline kernel. Would that one be available for 2.2 kernels too, easy to backport or 2.4 only? > If you care that much, you'll also be running UML under chroot as a user with > nothing but a uid on the system. ... which still means access to all world-reachable files and potential security exploits... (Paranoid? Moi? Never) Definetely cool stuff. I wonder if combined with various other patches like MOSIX, the process-group stuff from SGI etc this can "soon" kick S/390 ass ;-) Sincerely, Lars Marowsky-Brée <lm...@su...> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl |
From: Jeff D. <jd...@ka...> - 2001-06-05 23:46:04
|
lm...@su... said: > I am toying with the idea of writing a UML agent for FailSafe - > restart the virtual server locally/on another host on failure... *g* If it's entirely userspace, is there any reason that the existing one won't just work inside UML? > Would that one be available for 2.2 kernels too, easy to backport or > 2.4 only? It's basically trivial. > ... which still means access to all world-reachable files and > potential security exploits... (Paranoid? Moi? Never) :-) Local exploits require something to exploit, like a setuid program or local service with a /tmp race or something. You can run UML in a chroot jail that contains basically nothing, just the binary and filesystem. You don't even need libraries, since UML is statically linked. So unless there's a local exploit against chroot itself, I think that would be pretty tight. > I wonder if combined with various other patches like MOSIX, the > process-group stuff from SGI etc this can "soon" kick S/390 ass ;-) As soon as PC hardware kicks S/390 ass, maybe... Actually, I'm planning on having it kick ass, but not S/390 ass specifically. The IBM guys have no imagination when it comes to what you can do with an OS running over another OS. Jeff |
From: Lars Marowsky-B. <lm...@su...> - 2001-06-06 20:15:54
|
On 2001-06-05T20:00:07, Jeff Dike <jd...@ka...> said: > > I am toying with the idea of writing a UML agent for FailSafe - > > restart the virtual server locally/on another host on failure... *g* > If it's entirely userspace, is there any reason that the existing one won't > just work inside UML? Well, yes, but thats not what I am referring to - I mean making the UML itself highly available. Imagine if you were hosting 100 UML instances for customers - you would want those to be monitored, restarted on another node on failure, and ensure that the netblock the UML is using is routed to the correct host etc. However, I am actually not sure whether FailSafe would run correctly inside UML (not that I see much reason for doing so) - the important tasks run at realtime priority and locked into memory - how does UML map that? > > Would that one be available for 2.2 kernels too, easy to backport or > > 2.4 only? > It's basically trivial. Cool. > > I wonder if combined with various other patches like MOSIX, the > > process-group stuff from SGI etc this can "soon" kick S/390 ass ;-) > As soon as PC hardware kicks S/390 ass, maybe... > > Actually, I'm planning on having it kick ass, but not S/390 ass specifically. > The IBM guys have no imagination when it comes to what you can do with an OS > running over another OS. Have you considered running UML as compartments of the host kernel? I wonder how to best take advantage of "memory sharing" - ie, two UML instances could potentially share many pages between "processes" running inside UML, buffer cache pages etc - this may not be an issue with just 2 or 4 UMLs, but when I am thinking hosting, I keep thinking 100 and more, where this may amount to quite a few megs... Sincerely, Lars Marowsky-Brée <lm...@su...> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl |
From: Jeff D. <jd...@ka...> - 2001-06-06 23:44:25
|
lm...@su... said: > Well, yes, but thats not what I am referring to - I mean making the > UML itself highly available. Oh, I get it. You're thinking of UML as a service which can be failed over (failed over-ed ? Help me out with my English here, Lars :-) I was thinking about failing services from one UML to another. That would be interesting. What requirements does that put on the service? > the important tasks run at realtime priority and locked into memory - > how does UML map that? They're behave exactly as they do on the host, except that it happens virtually. So locked memory inside a UML won't be swapped out by it, but it could get swapped out by the host. > Have you considered running UML as compartments of the host kernel? I don't think that fits the model of UML too well. You don't generally compartmentalize a machine between a number of processes. You run them all and let the OS figure out how to assign resources to them. And if you want to override the OS decision-making (i.e. by pinning pages), that will work just as well with UML. Is that what you meant? > I > wonder how to best take advantage of "memory sharing" - ie, two UML > instances could potentially share many pages between "processes" > running inside UML, buffer cache pages etc - this may not be an issue > with just 2 or 4 UMLs, but when I am thinking hosting, I keep thinking > 100 and more, where this may amount to quite a few megs... This is an interesting question. They can share read-only filesystems - in which case, you could turn off caching for them, making all IO synchronous (to the host), which would have the host caching them and not all the UMLs. They can share read-write filesystems if there's a layering system in which modified blocks are read and written to a private block device and unmodified ones and read and written from the shared device. Greg Lonnon has this in the works a while back - I haven't heard much about it lately. This is the same situation, except you might try to figure out how to have the private blocks, but not the shared ones cached by the UMLs. A more interesting possibility that I've been considering is to implement a shared virtual filesystem plus block device. This would be mapped into the address spaces of a bunch of UMLs, which would hook the top-level filesystem ops into their respective vfs-es. Then they'd have a true shared read-write filesystem, with the mapped code handling sychronization. You could implement that at first with a normal SMP UML kernel with some kind of kludge to export the filesystem ops to the other UMLs. Later, you'd want to configure out everything that's not involved with running a filesystem, like system calls, processes, the scheduler, memory management (but leave memory allocation in). You'd also want to have it run its own page and buffer caches, so the filesystem would have to tell the UMLs that it wasn't using their caches. I don't know how hard that is. This would be the equivalent of a multi-ported disk with a builtin filesystem. You could also leave the filesystem off, but that's a lot less interesting. You're not nearly as interested in sharing a raw disk as you are in sharing a filesystem. It would be very cool to support this sort of hardware virtually and have hardware people come along later and decide that it would be interesting to produce and sell the physical device. This sort of thing could also be done with other types of devices, like consoles and standalone TCP stacks attached to shared network devices. Jeff |
From: Lars Marowsky-B. <lm...@su...> - 2001-06-07 14:25:15
|
On 2001-06-06T19:58:24, Jeff Dike <jd...@ka...> said: > > Well, yes, but thats not what I am referring to - I mean making the > > UML itself highly available. > Oh, I get it. You're thinking of UML as a service which can be failed over > (failed over-ed ? Help me out with my English here, Lars :-) Failed over, as far as I can tell ;-) > That would be interesting. What requirements does that put on the service? UML would be the service. The service needs a defined start, stop and monitor procedure. Basically, one writes a "sophisticated" shell script which performs these actions and reports the result to FailSafe. Not that much work. Of course, as the instances need access to their respective storage, this would also need to be available on all hosts, via Shared Storage (Fibre Channel probably). To ensure network connectivity, I would write another resource type which would tell the frontend router which host to route the netblock to (ie, ssh/telnet to it and set the route, or even via SNMP;). That might be quite interesting for the hosters of this world ;-) > > the important tasks run at realtime priority and locked into memory - > > how does UML map that? > They're behave exactly as they do on the host, except that it happens > virtually. So locked memory inside a UML won't be swapped out by it, but it > could get swapped out by the host. Ok. So I wouldn't actually want to run FailSafe in a UML instance currently, or at least that would put restrictions on how "highly available" that really is - but I am still enjoying the idea of doing this for testing ;-) > > I > > wonder how to best take advantage of "memory sharing" - ie, two UML > > instances could potentially share many pages between "processes" > > running inside UML, buffer cache pages etc - this may not be an issue > > with just 2 or 4 UMLs, but when I am thinking hosting, I keep thinking > > 100 and more, where this may amount to quite a few megs... > This is an interesting question. > > They can share read-only filesystems - in which case, you could turn off > caching for them, making all IO synchronous (to the host), which would have > the host caching them and not all the UMLs. Yes, that is the easy part - however, if two users currently exec the same executable, it will only get loaded once. Even if they share the block device, the pages would be duplicated between different UMLs. That might make for quite some overhead with a huge number of UMLs. (I seem to remember that there once was a patch for Linux which went and located duplicate pages by a checksum - but I think that was around 2.0 ;) > They can share read-write filesystems if there's a layering system in which > modified blocks are read and written to a private block device and unmodified > ones and read and written from the shared device. Greg Lonnon has this in the > works a while back - I haven't heard much about it lately. This is the same > situation, except you might try to figure out how to have the private blocks, > but not the shared ones cached by the UMLs. LVM / writable snapshots might have a lot of the logic required here. However, the cleanest way of sharing a filesystem would be to finally have a union fs for Linux, mount the shared part via ro NFS and the local adaptions on top of it. > A more interesting possibility that I've been considering is to implement a > shared virtual filesystem plus block device. You know, sharing the block device without caching might already be enough, and then just run GFS (www.globalfilesystem.org) on top of that ;-) On a side note, as soon as UML supports "virtual SMP" and is SMP-safe in that regard, and if I wanted the host scheduler to take control and not run an internal scheduler at all, couldn't the processes inside UML be marked runnable permanently, regardless of how many virtual CPUs the UML instances presents to the internal system? That would be a mere cosmetic information, but I don't see the need for having as many CPUs as processes as you suggested in another mail ;-) Sincerely, Lars Marowsky-Brée <lm...@su...> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl |
From: Jeff D. <jd...@ka...> - 2001-06-07 16:46:51
|
lm...@su... said: > UML would be the service. Right. > The service needs a defined start, stop and > monitor procedure. Basically, one writes a "sophisticated" shell > script which performs these actions and reports the result to > FailSafe. I take it that when the service is restarted, it's expected to restore itself to some sane default state, and it's not expected that its internal state will be what it was just before it crapped out? So UML would just be expected to boot on another node (doing whatever fscking is needed) and get ready to start serving again? That would be fairly easy. > but I am still enjoying the idea of doing this for testing ;-) You might as well check it out and see how it works for you. A virtual network is a lot easier to set up and manipulate than a physical one... > You know, sharing the block device without caching might already be > enough, and then just run GFS (www.globalfilesystem.org) on top of > that ;-) Maybe, but you have to copy the blocks into each UML still, even if it's all on the same machine. Unless you can rig up a shmem connection to GFS (or between GFS and the storage, I'm not that familiar with the GFS architecture). The scheme I outlined shares the caches between UMLs. > On a side note, as soon as UML supports "virtual SMP" and is SMP-safe > in that regard, and if I wanted the host scheduler to take control and > not run an internal scheduler at all, couldn't the processes inside > UML be marked runnable permanently, regardless of how many virtual > CPUs the UML instances presents to the internal system? That would be > a mere cosmetic information, but I don't see the need for having as > many CPUs as processes as you suggested in another mail ;-) I think that removing the scheduler is non-trivial. Anyway, the "many virtual processors" thing I described is an accounting gimmick to keep the generic kernel piece of UML happy. It doesn't need to consume extra resources. And it implements exactly what you want. Jeff |
From: Lars Marowsky-B. <lm...@su...> - 2001-06-07 17:56:54
|
On 2001-06-07T13:00:48, Jeff Dike <jd...@ka...> said: > I take it that when the service is restarted, it's expected to restore itself > to some sane default state, and it's not expected that its internal state will > be what it was just before it crapped out? > > So UML would just be expected to boot on another node (doing whatever fscking > is needed) and get ready to start serving again? Yes, that shouldn't require additional support from UML at all. > > but I am still enjoying the idea of doing this for testing ;-) > You might as well check it out and see how it works for you. A virtual > network is a lot easier to set up and manipulate than a physical one... Another FailSafe user just had the same idea. I guess I will test it next week, because I will then have the proper machines (well, I do need a bit more than my laptop 128MB/Celeron 233Mhz for that) in front of me again. > Anyway, the "many virtual processors" thing I described is an accounting > gimmick to keep the generic kernel piece of UML happy. It doesn't need to > consume extra resources. And it implements exactly what you want. Ok, then I am happy as a clam ;-) Sincerely, Lars Marowsky-Brée <lm...@su...> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl |
From: Eric L. G. <er...@ba...> - 2001-06-07 21:42:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 7 Jun 2001, Lars Marowsky-Bree wrote: > Jeff Dike <jd...@ka...> said: > > > > but I am still enjoying the idea of doing this for testing ;-) > > You might as well check it out and see how it works for you. A virtual > > network is a lot easier to set up and manipulate than a physical one... > > Another FailSafe user just had the same idea. I guess I will test it next > week, because I will then have the proper machines (well, I do need a bit more > than my laptop 128MB/Celeron 233Mhz for that) in front of me again. As the "other Failsafe user" involved here (grin): How does UML handle IP Aliasing? Here's my understanding of the latest UML networking system: Each UML instance has two IP addresses -- an internal one (e.g. 192.168.1.10) set up by the system, and a tap0 one (e.g. 192.168.1.11). Setting up a pair of UML instances would require using four addresses, then -- two for the UML internals, and two tap<n> addresses so they can be reached from the outside world. Now, the way Failsafe handles things is to have three IP addresses -- a public address (an IP alias) that all services are advertised on, and then the two machines in the cluster themselves, which have their own (non-aliased) addresses. When a machine fails, the other machine grabs the IP alias, restarts the services on the other machine, and all re-connects go to the new machine (as you can tell there may be a momentary lapse of service as the cluster fails over, but Failsafe is a High Availability system, *NOT* a fault-tolerant system -- fault tolerant systems generally need a lot of expensive hardware to handle migrating internal process states and such too). Anyhow: I just tried setting up an IP alias inside UML. It set it up fine internally. Of course, externally the "helper" application knows nothing about this. Any ideas? - -- Eric Lee Green mailto:er...@ba... GnuPG public key at http://badtux.org/eric/eric.gpg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7H/KX3DrrK1kMA04RAoeBAKDIPcQ0Hl8RGFsYobSeZtJyEpq5zgCgtvUB oIaC1dWWzwoJgp9NboA5WEM= =AuKs -----END PGP SIGNATURE----- |
From: Jeff D. <jd...@ka...> - 2001-06-07 21:57:25
|
er...@ba... said: > Anyhow: I just tried setting up an IP alias inside UML. It set it up > fine internally. Of course, externally the "helper" application knows > nothing about this. > Any ideas? Yeah, at this point, the helper is intended to help with the simplest stuff. So it doesn't at all handle the case of the inner IP changing. So, I think you need to another route through the device when you add another IP to a UML interface. Jeff |
From: Lars Marowsky-B. <lm...@su...> - 2001-06-07 22:29:58
|
On 2001-06-07T16:58:08, Jeff Dike <jd...@ka...> said: > So, I think you need to another route through the device when you add another > IP to a UML interface. The trick is to handle the tap device as a _network_ and not as a point to point interface. Sincerely, Lars Marowsky-Brée <lm...@su...> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl |
From: Lars Marowsky-B. <lm...@su...> - 2001-06-07 22:29:25
|
On 2001-06-07T14:30:57, Eric Lee Green <er...@ba...> said: What you would do (IMHO) is to setup a tap device which is shared between the various UML instances (the public network so to say). The host would use 192.168.1.1/24 (for example) on this network, basically acting as the gateway out of this public network. The UML instances would each get a static IP assigned from the "public" LAN, and the virtual IP addresses (the IP_address resources failsafe controls) would get one of the free ones. As the host routes 192.168.1.0/24 to the tap device, all addresses on that subnet should be reachable. I haven't tried how a tap device reacts to the unsolicited ARP replies FailSafe sends out though, but I guess they either do the right thing or get ignored by the host ;-) > Now, the way Failsafe handles things is to have three IP addresses -- a > public address (an IP alias) that all services are advertised on, Correction, FailSafe can manage arbitary IP addresses, and which IP address a particular service is associated with depends on the resource groups. Sincerely, Lars Marowsky-Brée <lm...@su...> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl |
From: Eric L. G. <er...@ba...> - 2001-06-07 23:24:14
|
On Fri, 8 Jun 2001, Lars Marowsky-Bree wrote: > On 2001-06-07T14:30:57, > Eric Lee Green <er...@ba...> said: > > Now, the way Failsafe handles things is to have three IP addresses -- a > > public address (an IP alias) that all services are advertised on, > > Correction, FailSafe can manage arbitary IP addresses, and which IP address a > particular service is associated with depends on the resource groups. Sorry, I was choosing the case of the simplest possible system (a two-node cluster where one node fails all services over onto the other node). You are of course correct, FailSafe will handle all sorts of different scenarios, such as various services failing over onto different servers, each resource group having its own public address of course which fails over with the services, etc. etc. etc.... I've been playing around and there's a lot of interesting scenarios here. Also a lot of hideous complexity (agh!). Thus why I am keeping things simple (two nodes, fail all resources to the other) while I figure things out. I'm not sure your suggestion about abuse of the tap device will work for what I'm wanting to do, but I'll give it a try. I may end up playing with the helper app some to add some functionality that would be useful here, will probably require a bit of groking around on the kernel side here too, but first I need to figure out what needs to be issued by hand :-}. -- Eric Lee Green mailto:er...@ba... GnuPG public key at http://badtux.org/eric/eric.gpg |