Problems startmol Debian 0.9.68 on G3 Pismo (tun.o missing)

Samuel Rydh mol-general@lists.maconlinux.org
Sat, 22 Mar 2003 16:51:27 +0100


On Sat, Mar 22, 2003 at 03:49:00PM +0100, Jens Schmalzing wrote:
> > recompiled everything (using gcc-2.95.4 2001100), changed 
> > allow_kver_mismatch: from yes to no, started mol and it works now fine.
> 
> > Did you compile the mol package with the new default gcc 3.2?
> 
> Sure.  This is what we call the gcc 3.2 transition.  BTW, I ran into
> your very problem during this transition and documented this *quite*
> clearly in the Debian changelog.  If you are running unstable, I
> strongly recommend that you install apt-listchanges, so changelogs are
> shown to you on upgrades.
> 
Yes, compiling the kernel with gcc 2.95 and kernel modules with
gcc 3.X (or vice versa) will not work.

> > BTW, why do you don't add a option to the mol package to install
> > startmol as setuid root?
> 
> Because startmol is a shell script, and suid bits are ignored on shell
> scripts.

Well, startmol script doesn't need root privileges. When invoked
by non-root, its sole function is performing some sanity checks
and handling a couple of switches like 'startmol --list' or
'startmol --help'.

The startmol script execs the mol binary though and this
program can be setuid root. If this is done, then mol will
disregard any unsafe command line options when invoked
by an ordinary user. For instance, anything which involves
paths or explicit files are ignored.

The main question is whether a setuid root mol binary is a
security hole. I don't think it is. It has been written to
be secure (but of course, I can't guarantee that I haven't
overlooked something).

Some notes about the design with respect to security:

i) The client OS runs unprivileged and in a completely separate
address space. Regardless of what the client does, it should not
be able to for instance write to the address space of the
emulator.

ii) All communication between the client OS and MOL occurs
through a syscall like interface. The client's physical RAM
image is accessible by both the client and MOL. However,
any passed pointer has to be translated (and at the
same time, a range check is performed).

iii) The debugger socket (which is a security whole since
the debugger can do a lot of unsafe things) is not
instantiated when mol is started by an ordinary user.

/Samuel