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!
> 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?
[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!
> > 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?
[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
[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!
> > ...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.
[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