These are the hints we give you, when running dosemu on a machine that is (even temporary) connected to the internet or other machines, or that otherwise allows 'foreign' people login to your machine. 1. NEVER let foreign users execute dosemu under root login !!! (Starting with dosemu-0.66.1.4 this isn't necessary any more, all functionality should also be available when running as user) 2. Do _not_ configure dosemu with the --enable-runasroot option. Normally dosemu will switch privileges off at startup and only set them on, when it needs them. With '--enable-runasroot' it would permanently run under root privileges and only disable them when accessing secure relevant resources, ... not so good. 3. Never allow DPMI programms to run, when dosemu is suid root, ... and this normally is the case else only root could run dosemu. (in /etc/dosemu.conf set 'dpmi off' to disable) It is possible to overwrite sensitive parts of the emulator code, and this makes it possible for a intruder program under DOS, who knows about dosemu interna (what is easy as you have the source) to get root access also on non dosemu processes. Because a lot of games won't work without, we allow creation of LDT-descriptor that span the whole user space. There is a 'secure' option in /etc/dosemu.conf, that allows to turn off creation of above mentioned descritors, but those currently protect only the dosemu code and the stack, may be some diabolic person finds a way to use the (unprotected) heap in his sense of humor. Anyway, better 'secure on' then nothing. 2. Never allow the 'system.com' command (part of dosemu) to be executed. It makes dosemu execute the libc 'system() function'. Though privileges are turned off, the process inherits the switched uid-setting (uid=root, euid=user), hence the unix process can use setreuid to gain root access back. ... the rest you can imagine your self. Use of 'system' can be disabled by the 'secure on' option in /etc/dosemu.conf The 'unix.com' command (also part of dosemu) does _not_ have this security hole: before execution a separate process is forked that completely drops prililege, ... hence no danger (will no longer be disbaled by 'secure on'). Hans Lermen, Apr 6, 1997