user-mode port 0.58-2.4.18-36

user-mode port 0.58-2.4.18-36

[Jeff Dike]

This is the fourth release of the 2.4.18 UML.

The major changes in this release include:

	It is now possible the to attach the UML gdb to sleeping threads.
	This is done by detaching gdb from the in-context thread and attaching
	it to the host pid of the sleeping UML process.  UML may be continued
	by reattaching to the in-context thread.  This feature was sponsored
	by Cluster File Systems, Inc.

	There is a /proc/exitcode, which allows a UML process to set the
	eventual UML exit code.

	Fixed some segfaults caused by calling openpty, which has an unusually
	large stack frame, overflowing the UML kernel stack.

	The tty logging patch is integrated.  This allows UML honeypots to
	log all tty traffic to a host file.  This logging can't be detected
	or interfered with by root inside the UML.

	UML now has a "hardware" watchdog.

	The UML binary now lives in its own physical memory.  This makes it
	easier for the swsusp patch to be ported to UML.

	Fixed a bug with lots of zombies causing a UML panic.

	It is now possible to move backing files and update the COW files with	
	ubdx=cow-file,new-backing-file.  Note that you must preserve the
	modification time when moving a backing file with something like 
	'cp -p' or 'tar p'. 

	Added support for kernel watchpoints.  They can be mixed with 
	watchpoints in gdb inside UML.  

	Fixed the bug which was closing file descriptors which should have
	been left open.  This was most often seen as a panic during UML
	shutdown, although it also appeared in other places.

	The mconsole driver now sends panic notifications to mconsole clients.

	A number of smaller bugs were fixed and features added.

The project's home page is http://user-mode-linux.sourceforge.net

Downloads are available at 
	http://user-mode-linux.sourceforge.net/dl-sf.html

				Jeff

Re: user-mode port 0.58-2.4.18-36

[Pavel Machek]

Hi!

> This is the fourth release of the 2.4.18 UML.
> 
> The major changes in this release include:
> 
> 	It is now possible the to attach the UML gdb to sleeping threads.
> 	This is done by detaching gdb from the in-context thread and attaching
> 	it to the host pid of the sleeping UML process.  UML may be continued
> 	by reattaching to the in-context thread.  This feature was sponsored
> 	by Cluster File Systems, Inc.
> 
> 	There is a /proc/exitcode, which allows a UML process to set the
> 	eventual UML exit code.
> 
> 	Fixed some segfaults caused by calling openpty, which has an unusually
> 	large stack frame, overflowing the UML kernel stack.
> 
> 	The tty logging patch is integrated.  This allows UML honeypots to
> 	log all tty traffic to a host file.  This logging can't be detected
> 	or interfered with by root inside the UML.

So... what prevents uml root from inserting rogue module (perhaps
using /dev/kmem) and escape the jail?

> 	The UML binary now lives in its own physical memory.  This makes it
> 	easier for the swsusp patch to be ported to UML.

Good ;-).
									Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: [uml-user] Re: user-mode port 0.58-2.4.18-36

[Jeff Dike]

pavel@ucw.cz said:
> So... what prevents uml root from inserting rogue module (perhaps
> using /dev/kmem) and escape the jail? 

That's prevented by the admin taking basic precautions and turning on 'jail',
which refuses to run if module support is present and which also disables
writing to /dev/kmem.

				Jeff

Re: [uml-user] Re: user-mode port 0.58-2.4.18-36

[Pavel Machek]

Hi!

> > So... what prevents uml root from inserting rogue module (perhaps
> > using /dev/kmem) and escape the jail? 
> 
> That's prevented by the admin taking basic precautions and turning on 'jail',
> which refuses to run if module support is present and which also disables
> writing to /dev/kmem.

...and using CAP_SYS_RAWIO...
									Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: [uml-user] Re: user-mode port 0.58-2.4.18-36

[Jeff Dike]

pavel@ucw.cz said:
> ...and using CAP_SYS_RAWIO... 

Do you really think I'm that stupid?

CAP_SYS_RAWIO is removed from the bounding set.

				Jeff

Re: [uml-user] Re: user-mode port 0.58-2.4.18-36

[Jeff Dike]

pavel@ucw.cz said:
> ...and using CAP_SYS_RAWIO... 

... or were you complaining about 'jail' turning off CAP_SYS_RAWIO, rather
than claiming that it is an unplugged hole?

If so, that may be a problem, but I haven't seen anything that cares about
CAP_SYS_RAWIO being off.  That was the simplest way I could find to disable
writing to /dev/kmem.

				Jeff

Re: [uml-user] Re: user-mode port 0.58-2.4.18-36

[Pavel Machek]

Hi!

> > ...and using CAP_SYS_RAWIO... 
> 
> ... or were you complaining about 'jail' turning off CAP_SYS_RAWIO, rather
> than claiming that it is an unplugged hole?

I thought it was that. It was mostly for other list users that may try
to setup their UML jail, and forget about this.

> If so, that may be a problem, but I haven't seen anything that cares about
> CAP_SYS_RAWIO being off.  That was the simplest way I could find to disable
> writing to /dev/kmem.

I don't understand here. So UML never ever permits access to
/dev/kmem? If so that is rather strange architecture.
									Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [uml-user] Re: user-mode port 0.58-2.4.18-36

[Jeff Dike]

pavel@suse.cz said:
> I don't understand here. So UML never ever permits access to /dev/kmem?

Jeez, have a look at the code.  CAP_SYS_RAWIO (and write access to /dev/kmem)
is disabled only when 'jail' is turned on.

				Jeff