From: Jeff D. <jd...@ka...> - 2001-03-11 17:37:37
|
lis...@os... said: > It should be noted in the documention for hostfs that you really don't > want this if you're creating a secure gaol. Yup. > Not only that, but one should be able to built UML so that it > explicitly disallows it. I plan on adding a CONFIG_SECURE_JAIL which will disable (if possible) hostfs and whatever else can be used to escape. > However, even with normal user privilege, UML allows one local-user > access to the host without being logged in. That access may extend to > anyone (crackers included) with access to the guest. > My suspicous mind suggests this isn't a good idea. Depend on what you mean by "access". A UML user can use certain host resources, but those resources (especially the rootfs) are disposable. If they get trashed, you don't really care. You may be able to attempt DOS attacks on the host, but the ones I can think of are also DOS attacks on the guest, and the guest will fall over much sooner than the host. That being said, if you put a UML on the net, it's probably a good idea to run it as a 'nobody' user inside a chroot jail (or a namespace jail, once Al Viro gets his namespaces into 2.5). Jeff |
From: Jeff D. <jd...@ka...> - 2001-03-12 17:17:06
|
lis...@os... said: > In the context of rootfs, root on the guest can mount the host's > rootfs and then anyone in the guest can read/write anything that the > UID of UML gives access to. Currently, that's true. However, I'm planning on adding an option to hostfs that restricts any mounts to a specific directory. Sort of a chroot. That doesn't make it secure, though. > I think UML machines for "untrusted" access should disallow module > loading. Yup, that's another one. Jeff |
From: Jeff D. <jd...@ka...> - 2001-03-12 19:30:46
|
bu...@gn... said: > As a matter of fact, several root kits out in the wild have > functionality to load modules on systems that have no module support. > It's only a matter of time before these get adapted to work on uml. Except that I can disable access to kernel memory, even by root. And I can put important data outside "physical memory", which physical boxes can't do. Jeff |
From: Jeff D. <jd...@ka...> - 2001-08-20 19:06:31
|
mc...@fr... said: > hostfs_user.c: In function `stat_file': hostfs_user.c:31: structure > has no member named `__st_ino' This is fixed. Grab the latest patch. > Your CVS repository seems to have the entire kernel, which seems only > logical, although painful. No it doesn't. Only the files that UML modifies. The patch is probably easier to deal with, but for CVS, check it out into an empty directory, then cp -a it onto a kernel pool. Jeff |
From: Michael R. <mc...@sa...> - 2001-08-20 19:45:19
|
>>>>> "Jeff" == Jeff Dike <jd...@ka...> writes: >> Your CVS repository seems to have the entire kernel, which seems only >> logical, although painful. Jeff> No it doesn't. Only the files that UML modifies. Yes, I then noticed this... Jeff> The patch is probably easier to deal with, but for CVS, check it Jeff> out into Jeff> an empty directory, then cp -a it onto a kernel pool. hmm. okay... I'll do instead: "tar cf - . | (cd pool; tar -x -f - --unlink)" since my kernel pools are mostly made with "lndir". (patch likes this just fine) I now have hostfs built in. Thanks. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ |
From: Jeff D. <jd...@ka...> - 2001-08-20 20:03:51
|
mc...@sa... said: > hmm. okay... I'll do instead: > "tar cf - . | (cd pool; tar -x -f - --unlink)" Yup, tar works for this too. Jeff |
From: Trent L. <tr...@ir...> - 2003-02-26 12:14:42
|
oh so your assuming everything in / is owned by root? this is very often not the case? At 12:47 PM 26/02/2003 +0100, Henrik Nordstrom wrote: >As I said previously: hostfs is NOT suitable for user home directories >within UML. For this you should use NFS as you would do in any other >distributed computing environment where you want the home directories >shared.. > >Regards >Henrik > >ons 2003-02-26 klockan 12.42 skrev Trent Lloyd: > > But what about having multiple users on the system - they cant own their > > own files? > > > > At 12:36 PM 26/02/2003 +0100, you wrote: > > >ons 2003-02-26 klockan 11.39 skrev Trent Lloyd: > > > > Ok well what solutions are there for having the rootfs mounted on > the host > > > > system and inside the uml at the same time > > > > > > > > nfs.. etc > > > > > >hostfs is quite suitable as a root filesystem in many situations. > > > > > >if you need additional powers a networked filesystem is recommended (NFS > > >being the firs candidate), with the usual restrictions of networked > > >filesystems. > > > > > >-- > > >Henrik Nordstrom <hn...@ma...> > > >MARA Systems AB > > > > > > > > > > > >------------------------------------------------------- > > >This SF.net email is sponsored by: Scholarships for Techies! > > >Can't afford IT training? All 2003 ictp students receive scholarships. > > >Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > > >www.ictp.com/training/sourceforge.asp > > >_______________________________________________ > > >User-mode-linux-devel mailing list > > >Use...@li... > > >https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel >-- >Henrik Nordstrom <hn...@ma...> >MARA Systems AB |
From: Michael R. <mc...@sa...> - 2003-03-03 01:48:01
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Henrik" == Henrik Nordstrom <hn...@ma...> writes: >> Ok well what solutions are there for having the rootfs mounted on the >> host system and inside the uml at the same time >> >> nfs.. etc Henrik> hostfs is quite suitable as a root filesystem in many situations. Henrik> if you need additional powers a networked filesystem is Henrik> recommended (NFS being the firs candidate), with the usual Henrik> restrictions of networked filesystems. FreeSWAN's testing system puts everything on hostfs. We create a tmpfs for /tmp and /var/run, and use devfs (the default) hostfs does not support Unix domain sockets, and pluto wants to make a socket in /var/run. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPmKz4YqHRg3pndX9AQEA/wP+PESOsxxZMJxIUEfLt4zkAIuYcx1h/dCQ 6pdYklbkI44K4EkAFgZ3NpSNBhv2SYemPRa/IkdPXPELO+frhfL1BruUUCt9A/Gk pEtctCVfZ9bZni+lfUCGSF5oXMXOQFYAiX+6OauH3U4Rmb/gTeBzcmU72nSLcOVP 4EHSGcsrXQo= =XPX8 -----END PGP SIGNATURE----- |
From: <lis...@os...> - 2001-03-12 15:01:30
|
On Sun, 11 Mar 2001, Jeff Dike wrote: > > > However, even with normal user privilege, UML allows one local-user > > access to the host without being logged in. That access may extend to > > anyone (crackers included) with access to the guest. > > My suspicous mind suggests this isn't a good idea. > > Depend on what you mean by "access". A UML user can use certain host > resources, but those resources (especially the rootfs) are disposable. If > they get trashed, you don't really care. In the context of rootfs, root on the guest can mount the host's rootfs and then anyone in the guest can read/write anything that the UID of UML gives access to. I think UML machines for "untrusted" access should disallow module loading. |
From: Lennert B. <bu...@gn...> - 2001-03-12 17:14:21
|
On Mon, Mar 12, 2001 at 08:51:26AM +0800, lis...@os... wrote: > > Depend on what you mean by "access". A UML user can use certain host > > resources, but those resources (especially the rootfs) are disposable. If > > they get trashed, you don't really care. > > In the context of rootfs, root on the guest can mount the host's rootfs > and then anyone in the guest can read/write anything that the UID of UML > gives access to. > > I think UML machines for "untrusted" access should disallow module > loading. I don't think this solves the problem in any way. As a matter of fact, several root kits out in the wild have functionality to load modules on systems that have no module support. It's only a matter of time before these get adapted to work on uml. cheers, Lennert |
From: <lis...@os...> - 2001-03-13 23:50:21
|
Lennert Buytenhek writes: > > > > I think UML machines for "untrusted" access should disallow module > > loading. > > I don't think this solves the problem in any way. > > As a matter of fact, several root kits out in the wild have functionality > to load modules on systems that have no module support. It's only a matter > of time before these get adapted to work on uml. I didn't say it solves the problem. No one action solves the problem, but all loopholes we can think of should be closed. Having most filesystems ro (enforced by the host) helps too, but I was talking in the specific context of rootfs. |