Re: [uml-devel] filemap feature 2.4.22-5um

["Steve Schmidtke" <steve_schmidtke@hotmail.com>]

Henrik Nordstrom wrote:
>What I do not quite get in this discussion is why one does not want to
>have the selected files available in the chroot in the first place?

Check out Jeff's talk on UML security and chroot:

  http://user-mode-linux.sourceforge.net/slides/ists2002/text17.htm

>To chroot you need to be root. As root you are also allowed to map files
>around using mount --bind.

I can't really argue with that, except hundreds of /etc/mtab entries might 
be annoying :)  (yes, I know you could mount -n to hide them).

BlaisorBlade wrote:
>Alle 16:08, marted� 14 ottobre 2003, Steve Schmidtke ha scritto:
> > yes. The discussion for a previous patch considered a "mm" table to hold 
>a
> > pool of /proc/mm files to handle one fd per process.
> > [....]
>Nooo! Don't make your like hard!

It's making the crackers lives hard that I'm attempting; making mine 
difficult in the process is merely an occupational hazard.

>cd <chroot path>
>mkdir proc
>touch proc/mm #You must create the mount point. In this case it's a file.
>(as root)mount --bind /proc/mm proc/mm
><start Uml binary with "# chroot . linux ...." >

--bind is useful, and I'm trying to avoid it out of principle, not because I 
don't know about it.  In this case --bind would work because /proc/mm is 
writable by everyone, so when the chroot wrapper drops root, the UML can 
still access the file.  That is not the case for all files you may want to 
give a non-root UML access to.

>About the ugliness, it's only a userspace syntax matter. This is the v2 of 
>the
>umlwrap syntax. Instead of this:
>   umlwrap -bind=21,/dev/shm/mconsole1 -dir=/home/uml -- \
>   /bin/linux mem=48M uml_dir=/uml/ umid=um1 filemap=22,/uml/um1/pid \
>   22</dev/shm/pid filemap=21,/uml/um1/mconsole
>
>We can have this:
>   umlwrap -dir=/home/uml -bind=/dev/shm/mconsole1,/uml/um1/mconsole \
>   -map=r,/dev/shm/pid,/uml/um1/pid-- /bin/linux mem=48M uml_dir=/uml/ 
>umid=um1

Yup, that's what I'm leaning towards.

>umlwrap will then setup the needed "filemap" options, at the end of the
>command line.

The order of the command line arguments may be important:  filemap options 
should be parsed before options that reference them (i.e. they should come 
first, not last, on the command line).

>However, does UML(unlike vanilla kernel) supports so long(>512
>char) command lines in the internal kernel part, (in the userspace part 
>it's
>granted)? If not, we can use a patch out there that is already used by
>Knoppix.

Adam Heath is working on a patch for reading config files that will also 
make command line length irrelevant.  I like this approach since the UML 
command line wouldn't have to be mangled to add filemap options to it.

Steve Schmidtke

_________________________________________________________________
Fretting that your Hotmail account may expire because you forgot to sign in 
enough? Get Hotmail Extra Storage today!   
http://join.msn.com/?PAGE=features/es



-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel