On 06/07/2012 06:37 AM, Sampsa Laine wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a
socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes
to Box B, and MAIL to Box C :)
Yes, you could multiplex/demultiplex it any way you wanted. It would
open up all sorts of interesting configuration possibilities.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 11:29, Dave McGuire wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a socket?
Cool idea - you could even have multiple hosts connect this way but export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes to Box B, and MAIL to Box C :)
Sampsa
On 06/07/2012 06:24 AM, Mark Benson wrote:
So we agree security is a storm in an espresso cup.
Well put. :)
If you farm it out to a low cost dedicated device it's not costing you
CPU cycles on your work computer.
MAC address spoofing gets around the issue of source MAC address from
a DECnet stack.
pcap gets around finding incoming packets that are fror your DECnet stack.
What issues remain that stop you using a non-kernel solution?
My only concern now is if the stack has to run as root how do
non-privileged ysers use it?
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a socket?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
So we agree security is a storm in an espresso cup.
If you farm it out to a low cost dedicated device it's not costing you
CPU cycles on your work computer.
MAC address spoofing gets around the issue of source MAC address from
a DECnet stack.
pcap gets around finding incoming packets that are fror your DECnet stack.
What issues remain that stop you using a non-kernel solution?
My only concern now is if the stack has to run as root how do
non-privileged ysers use it?
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 06/07/2012 06:15 AM, Mark Benson wrote:
Yup, we are in agreement..."practically nonexistent". ;)
It's the sort of thing *I* don't care about but someone else might get
unduly upset about.
Like me being unduly upset about the additional system load incurred
by running the interface in promiscuous mode. ;)
Yes, 'practically' non-existant.
See above. =)
I think it is time for sleep!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 11:05, Dave McGuire <mcguire at neurotica.com> wrote:
Yup, we are in agreement..."practically nonexistent". ;)
It's the sort of thing *I* don't care about but someone else might get
unduly upset about.
Yes, 'practically' non-existant.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Jordi,
You wrote that the NIC on the 4000-90 was broken. Did you try an external transceiver on the AUI connector (there's a switch on the back).
An Alllied Telesys or DEC transceiver might solve the issue. The logic that drives the BNC connector is on a separate module IIRC.
If you need software kits for the VAX, post your needs. If I have the kit(s) I'll burn them on a CD.
Hans
-----Original Message-----
From: Jordi Guillaumes i Pons <jg at jordi.guillaumes.name>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 07 Jun 2012 11:32:40
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: [HECnet] Introducing myself... and my little network
Hello list,
I've just joined HECnet under the area 7, and I wanted to introduce
myself and my little puppies :)
My first computer (apart from the 8-bit home stuff) was a VAX-8250
running VAX/VMS 4.7. It was back in 1987, and it was a departamental
machine which was going to replace a PDP11/60, which, regretabily, I
didn't pay a lot of attention to. I was involved professionally with DEC
machines until 1992. My "last" machine was a VAXServer 4000 mod. 200,
which eventually ended living at my home :). I did plenty of stuff at
that time, from system managing to application design (and programming).
I had the pleasure to work with the DEC development environment, which I
still miss these days: VAXSet, CDD, the consistent VAX Calling
standard... I've not seen something so well integrated since those days.
Just to complete the picture, when I left the DEC environment, and after
a short time working with DOS (fortunately it was a SHORT time) I ended
working in the mainframe world, beginning in the applications
programming area (PLI, IMS/DB-DC, DB2...) and ending in the systems
programming area (mostly in the IMS environment). Right now I'm a
"software architect", whatever that means.
As I said before, when my company got rid of that 4000/200 I toke care
of it, as well as a uVAX 3300... those two machines now live happyly at
my home, forming a DSSI cluster which I power up from time to time (too
much noisy and hot for a home environment). I've tried to keep them in
working state (had to replace a fan in the 3300 and some minor stuff),
and they indeed work.
I got some vaxStations from eBay, and some other classical stuff (2 old
sun stations). I had diverse luck with those machines. I've got a
perfectly functioning VS 4000 mod. 60, and a broken VS 4000 mod 90
(that's unfortunate). The '90 has its NIC physically broken. It boots
but I can't network it, so its utility is limited (I don't own the
graphics display, and I've just got a VT320 which I have to switch
between all my boxen...). There is also a broken VS 3100; that machine
has a cache problem and does boot VMS; however it boots NetBSD (weird!).
I don't use it a lot, to say something :)
After I learnt the existence of HECnet researching some PDP11 stuff, I
asked Johnny to join. He has been -of course- very helpful, as well as
other members of the net, to whom I want to say thanks for the support.
Right now, area 7 is formed by these nodes:
7.6 MBSERV Linux Machine, host of my simulated boxen
7.60 BITXOV SIMH 3900 running openVMS 7.3
7.70 BITXOT SIMH PDP11 running RSTS/E 10.1
7.71 BITXOR SIMH PDP11 running RSXM+ 4.6
7.64 BITXO1 4000/200 running openVMS 7.3
7.65 BITXO2 3300 running openVMS 7.3
7.68 BITXO5 4000/60 running openVMS 7.3
I've got also some emulated PDP10 which I've not networked (yet). I'm
having trouble plugging into DECNET a TOPS20/Panda machine... If someone
could point me to any docs I would appreciate it a lot. I'm trying too
to DECNETize a TOPS10 running on a KLH10 simulated machine; this one
kinda works... I get the adjacency up messages but I can't talk to the
machine (neither FROM the machine). The only docs I've found are for the
7.03 version of the monitor, but I've got 7.04. Again, any pointers to
docs will be appreciated.
I'm still working on the setup. I intend to have the virtual machines up
most of the time. The physical ones are down most of the time, with the
exception of the 4000/60 (right now, it is up). I plan to add a SIMH 780
running VMS 4.7 soon. By the way, if someone could point me to pre-5.0
software kits I'd be very happy. I've got some stuff in the usual sites,
but I'd like to find BASIC, FMS, TDMS and BLISS for pre-5.0 VMS (I've
got the full CD consolidated distribution, circa 1992, and the hobbyist
kit so I've got covered the "modern" stuff :)). Same thing for RSX
software: I'd like to get a working COBOL (C81) for RSX11MPlus, as well
as DECNET for RSX11M (NOT plus). I really love to tinker with these
classical OSes :)
Well,tha'ts all for now. I've been reading the last message interchanges
in the list, and I think you could get a real boost to solve your
networking/interface sharing issues if you used VDE for the SIMH
machines. It's really easy to set up and you can do things like hooking
to your home DECnet network when you are on the road, using NATed
networks in which you can't control the port redirctions. Right now I'm
doing just that, extending my laptop "ethernet" to home using a ssh
tunneled vde plug thru a tethered iphone (whoa!). I've got the recipes
to make it work more or less automatically on ubuntu machines. If
someone is interested just ask.
Have a nice day, and enjoy!
On 06/07/2012 06:02 AM, Mark Benson wrote:
Indeed. In addition to the fact that I'm not clear what security threat
we're talking about here...
I'm not convinced at all that there's any sort of security issue here.
It is marginally less secure based on thus:
Any OS can be violated to provide root access. In normal circumstances
the ethernet interface does not expose other packets. On a system
running with the interface in promiscuous mode it does expose other
packets. Thus if the system's security is breached (i.e. the box is
rooted) it exposes more than the normal level of information about
your network without the perpetrator needing to act (i.e. run a
scanner of their own) to get it.
Like I said it's minimal. If your box gets rooted you are screwed anyway ;)
Yup, we are in agreement..."practically nonexistent". ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 10:32, Dave McGuire <mcguire at neurotica.com> wrote:
On 06/07/2012 05:09 AM, Johnny Billquist wrote:
Indeed. In addition to the fact that I'm not clear what security threat
we're talking about here...
I'm not convinced at all that there's any sort of security issue here.
It is marginally less secure based on thus:
Any OS can be violated to provide root access. In normal circumstances
the ethernet interface does not expose other packets. On a system
running with the interface in promiscuous mode it does expose other
packets. Thus if the system's security is breached (i.e. the box is
rooted) it exposes more than the normal level of information about
your network without the perpetrator needing to act (i.e. run a
scanner of their own) to get it.
Like I said it's minimal. If your box gets rooted you are screwed anyway ;)
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 7 Jun 2012, at 10:09, Johnny Billquist <bqt at softjar.se> wrote:
Yeah, I'm also starting to wonder if we're talking about different things...
I wouldn't be surprised if I am totally across-purposes as I am just a
user with a little knowledge (and we all know about a little
knowledge?) in this argument.
Maybe someone can explain to me the worries they have with this "wide open" thing, and how that improves by having the bridge (or router) running on a separate machine?
As far as I see it, using pcap and promiscuous mode creates 2 potential issues:
Security is possibly compromised, but promiscuous mode is only
activated as root so rhis isn't a big concern.
There is an increase in traffic and filtering loads on the CPU because
the LAN interface is no longer filtering packets in hardware.
Using a separate 'appliance' to do the work presents these possible solutions:
There is nothing of import on the appliance so immediate security is
not a problem. Packets from or intended for other destinations can
still be sniffed but you still need root access to the device.
Traffic through the device and using the CPU to filter it is the
intended purpose of the 'appliance' thus it is not invading your other
tasks on a user-centric machine and it is also not compromised by
other heavy tasks absorbing CPU cycles for other things.
Indeed. In addition to the fact that I'm not clear what security threat we're talking about here...
It's minimal, but it shouldn't be totally ignored unless it's an
acceptable risk to the users concerned. Usual security caveats apply
i.e. use good passwords on the router device etc.
It's just anal-retentive perfectionism, nothing more, no REAL impact,
no REAL casualties...but it makes me sleep better at night, and I can
usually achieve it pretty much everywhere else. :)
No objections to that one. Except I don't loose sleep over a few CPU cycles here, since they are pretty much zero anyway. But like I said before, I don't mind clean stuff.
Again, shut it in a small box on it's own with a single-purpose OS and
it becomes a clean(er) solution.
--
Mark
