user-mode port 0.58-2.4.18-36
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
Hi!
Quoted 13 lines
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.
Quoted 6 lines
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?
Quoted 2 lines
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
Signature · 2 lines
Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email?
Quoted 2 lines · [email protected] 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
Hi!
Quoted 6 lines
Quoted 2 lines
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
Signature · 2 lines
Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email?
Quoted 1 line · [email protected] said:
...and using
CAP_SYS_RAWIO...
Do you really think I'm that stupid?
CAP_SYS_RAWIO is removed from the bounding set.
Jeff
Quoted 1 line · [email protected] 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
Hi!
Quoted 4 lines
Quoted 1 line
...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.
Quoted 3 lines
If so, that may be a problem, but I haven't seen anything that cares about
CAP_SYS_RAWIObeing 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
Signature · 2 lines
Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic.
Quoted 1 line · [email protected] 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