3 Sep
2004
3 Sep
'04
1:22 p.m.
Hello fellow retrocomputing folks
Here's my perspective as the guy whom maintains the Debian
package of simh.
Lots of people don't like to run or install suid binaries
especially something like simh that can overwrite files.
Imagine a multiuser system, with simh pdp11 installed as root.
Now "attach lpt /etc/passwd" well you get the idea not a good
situation.
My way around it, was to compile two copies of the pdp11, one
plain user prog called pdp11, one with ethernet compiled in
called pdp11-ether. If someone wants they can SUID root the
pdp11-ether, but I'm not going to do it for them.
I am not an expert pdp11 user but this seems to result in no
complaints (whom is an expert on all 32 simh emulators other
than Bob S ?)
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.
Its open source, if you can give a good explanation of what you
want in a simh package for Debian, I'll make it happen...
5 Sep
5 Sep
2:12 a.m.
Vince Mulhollon wrote:
My way around it, was to compile two copies of the
pdp11, one
plain user prog called pdp11, one with ethernet compiled in
called pdp11-ether. If someone wants they can SUID root the
pdp11-ether, but I'm not going to do it for them.
I am not an expert pdp11 user but this seems to result in no
complaints (whom is an expert on all 32 simh emulators other
than Bob S ?)
Why does simh need to run as root to do networky stuff?
Gordon.
9:04 a.m.
Cause SIMH does it's networking things (currently) by packet sniffing,
and most OS's don't want everyone sniffing packets, (Particularly the
ones w/ passwords in them.) ergo, you must be 'root' to sniff packets.
David
On Sun, 2004-09-05 at 07:12, Gordon JC Pearce wrote:
Vince Mulhollon wrote:
My way around it, was to compile two copies of
the pdp11, one
plain user prog called pdp11, one with ethernet compiled in
called pdp11-ether. If someone wants they can SUID root the
pdp11-ether, but I'm not going to do it for them.
I am not an expert pdp11 user but this seems to result in no
complaints (whom is an expert on all 32 simh emulators other
than Bob S ?)
Why does simh need to run as root to do networky stuff?
Gordon.
2:43 p.m.
David Holland wrote:
Cause SIMH does it's networking things (currently)
by packet sniffing,
and most OS's don't want everyone sniffing packets, (Particularly the
ones w/ passwords in them.) ergo, you must be 'root' to sniff packets.
David
Have you seen how User Mode Linux handles this? IIRC you can run a
userspace kernel, and have it talk to a networking daemon which runs as
root. Obviously this gives you a lot more fine-grained control over
what the UML kernel actually sees - great for honeypots, because from
"outside" it looks just like an ordinary running Linux kernel.
Gordon.
11:21 a.m.
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
7255
days inactive
7257
days old
4 comments
3 participants
participants (3)
-
dholland＠woh.rr.com -
gordon＠gjcp.net -
vlm＠mulhollon.com