simh running as root etc

From: David Holland <dholland_at_woh.rr.com>
Date: Sun Sep 5 15:21:21 2004

Hello,

On Fri, 2004-09-03 at 18:22, Vince Mulhollon wrote:
> Hello fellow retrocomputing folks
>
<snip>
>
> Imagine a multiuser system, with simh pdp11 installed as root.
> Now "attach lpt /etc/passwd" well you get the idea not a good
> situation.

Yup, that would be a problem w/ a suid solution.

[-- I don't know enough about about VAX hardware to even know if this is
possible, however, I'm paranoid enough to be concerned about it. :) --]

My concern w/ SIMH & 'root' was more along the lines of:

JoeHacker finds a VMS exploit, and now has full system priv's on the
simulated VAX. Say JoeHacker can hand invalid data off to the simulated
disk drive hardware that causes a stack overflow inside SIMH's simulated
hardware, spawning a shell listening on some network port. That shell
will have whatever privileges SIMH currently had. (In this case
'root'). I'd call that badness too. :)

My solution was to hack up a patch that allowed you to change the user
id, group id, and perform a chroot() system call. The idea would be:
1) put your SIMH config file somewhere outside of your chroot() jail,
2) leave SIMH mode 0755 (not setuid)
3) run SIMH as root, pointing to the config file.
4) Inside the config file, do things like so:
        set xq mac=xx-xx-xx-xx-xx
        attach xq eth0

        set priv root=/opt/jail gid=-1 uid=-1
        show priv

        load -r /rom/ka655x.bin
        set rq0 rauser=8192
        attach rq0 /data/d0.dsk
        <etc>

With my patch, and the above configuration, if the above exploit
happens, the only thing trashed is the simulated VAX environment. The
hacker is stuck inside of /opt/jail, has no permissions to modify much
of anything, They might be able to steal bandwidth, but I'd rather
someone steal bandwidth, than trash files.

If the SIMH developers don't want to accept my patches, I guess I'll be
maintaining my own copies of SIMH for a bit. <shrug>.

>
> The reference to a kernel 2.6 feature that works around all that,
> is probably a reference to the tun interfaces, the ones used by
> openvpn and all that. At least that is my guess. Never tried that.

There's also a capabilities linux interface, but you still end up
dropping privileges. It might be in later 2.4's as well. I figured
setuid()/setgid()/chroot() were more portable, and more applicable to
other Unix like platforms, so that's what I went with.

I'd like to see some examples utilizing the tun/tap interfaces, as I'm
not 100% certain the packet sniffing method will do what I want it to.

David
Received on Sun Sep 05 2004 - 15:21:21 BST