Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!bpa!cbmvax!vu-vlsi!dsinc!lgnp1!vskahan
From: vskahan@lgnp1.LS.COM (Vince Skahan)
Newsgroups: comp.sys.apollo
Subject: Re: Protection in Internets (kind of long...)
Summary: here's how WE handle it
Keywords: not much you can do if you want to provide the service
Message-ID: <1568@lgnp1.LS.COM>
Date: 3 Jun 89 01:20:16 GMT
References: <3877@hacgate.scg.hac.com>
Reply-To: vince@atc.boeing.com (Vince Skahan)
Organization: Boeing Computer Services - Phila.
Lines: 108

In article <3877@hacgate.scg.hac.com> lori@hacgate.scg.hac.com (Lori Barfield) writes:
>Our Apollo hardware configuration here consists of two Domain rings
>internetted via Ethernet.  We are set up such that our nodes believe
>they are actually part of one big ring (I have heard this referred to
>by 2APOLLO elves as a "DDS" configuration.)
>

we have over 10 rings connected via ethernet and over a dozen
ethernet-only nodes that are all set up as different logical rings with
different internet network numbers.  Every node has every other node
cataloged by a merged ns_helper database. The ethernet hosts are set up
as one "logical" ethernet "ring".  

We have one merged registry mainly because SR10 requires it.  We ran in
the past with as many as 3 different registries for diferent sets of
organizations and it all worked to prevent non-priv'd users from doing
what they shouldn't.

The stuff in the SR10 manuals about REQUIRING one merged registry is
true at SR10.1 at least.  I've experienced having a node's registry site
down and having that node's rgyd (I think it's that daemon at least...I
forget) find the other  (the WRONG) registry across the ethernet.

At SR10.2 I hear the ability to have multiple registries will be
avaiilable.  I'm not as sure what they're doing with the canned UID
problem other than saying "yep...we realize we have a problem here and
we're working on it...".

>Now what do we do for security?  People with root/sys_admin access on
>one network can blast away at anything on the other.  Shared resources
>are critical to our operation, but not shared priviledges.
>

At any released version of the Apollo OS you have a very simple
choice... either do NOT talk ring-ring with token ring protocol as if it
was one big ring (use TCP to remote login and/or transfer files) and get
perfect security at the cost of maintaining multiple registries... or
make it look like one big ring and leave yourself open to the
possibility of a sys_admin/locksmith/root on one ring blasting another
ring either on purpose or by accident.

There's nothing you can do at 10.1 or before to handle it that I'm aware
of.  I hear that this MAY be handled at 10.2 (which I hear is slipping
more toward Labor Day so that its quality and functionality are
significantly better than SR10.x has been so far.)

The bottom line is that APollo has concentrated so much on
internetworking and inner-connectivity in the past (and done so well, I
might add) that they forgot that there might be occasions where you have
to stop people from abusing this ability either accidently or
maliciously. They handled the non-priv'd guys well (since there's more
of them and they're more likely to messaround where they shouldn't) but
they didn't put a priority on protecting sys_admins from each other
where there were multiple sys_admins on an internet of rings).
  
>I'm an Aegis fan, but I hear that under UNIX, rlogin checks network
>priviledges before allowing a user on, even as root.  Crp couldn't care
>less where I'm coming from.  Also, the users here depend on UNIX, and
>have told me that their file protection doesn't check past root to
>group or world when allowing access to files and directories.  So setting
>up separate root accounts with different projects (groups) does me no
>good.
>

SR10.1 at least does nothing different from SR9 other than preventing
root to rsh or rlogin with root-type priv's (that's a feature...not a
bug...imagine being on the Internet and having a root somewhere with the
ability to poke around due to canned UID's...scary, eh ???).

Interestingly enough...you have to be a member of the "wheel" group to
do a "su" to root at SR10 but ANYONE can do a "/com/login root" if they
know the password. (...Apollo: is that a feature or a bug ??? I haven't
opened any calls or APRs about this one because I'm not sure...)

Either in SR9 or SR10 you can do normal stuff with Aegis ACLS or unix
groups, etc. to prevent non-priv'd users from poking around.

There's nothing to prevent root/locksmith/sys_admins from doing the
same.

>Help!  What did YOU do?

We keep real tight control of who has privs and are trying to make
administrative policies controlling network connections that will
prevent joe_sys_admins out there from connecting to the ethernet and
doing a "/com/rtsvc -dev eth802.3_at -route" or the like to turn
ring-ring routing on...we can't STOP them from doing it but we can ask
real nicely...

Several rings on our network don't want to talk ring-ring and that's OK
too.  They have been told to contact the sys_admins who DO before they
do so. Again...we can ask for cooperation but can't force it..

Every other place in our company refuses to provide the service of
ring-to-ring via Apollo protocol due to the risks.  We work so closely
together among the various organizations that we license software based
on this feature, work together on projects, etc.  We accept the risks
(with our knees shaking in fear sometimes) to get the benefits.

>
>...lori

...Vince..
-- 
Vince Skahan - please reply to skahan@boeing.com or bcsaic!psev!bcs212

Note: any comments expressed above are mine and have no relation to
Boeing or the real nice folks who let me read news on their system...