vskahan@lgnp1.MASA.COM (Vince Skahan) (10/20/88)
[...not necessarily "flame on" but certainly "bitch on"...] We have about 12 subnets hanging off of the same ethernet (at work) and 10 of these are Apollo rings. Each ring has a gateway (or 2) for TCP/IP and "native apollo" communications so each node can talk to any other node. As we add rings to new organizations, we have a few problems that occur... - apollo says use one master registry but we have very different organizations with very different ideas and needs for security. This leads to the need to use more than one master registry. - the "canned SIDs" for administrators and system accounts/ppo's results in a sys_admin in one registry having the same priv's in other registry rings (internets), making everyone everywhere open to problems created by well-meaning but rookie admin's (and hypothetically not-so-well-meaning folks). - there is an inherent trade-off between the idea of transparent access from all nodes in all rings to one another and the real world problems of different organizations on the same ethernet who need access to common Vaxes (with TCP/IP and/or access) but want to protect the heck out of everything to keep *their* system under reasonable control. My questions go like this: - Why can't there be more than one master registry in an internet? This will prevent the dozens of non-privileged users from each other (I'm assuming that the admins all talk and that they all understand that they can inadvertently affect other rings). - For native ring-ring communications, you might be able to have the common ethernet be more than one *logical* apollo internet (organization A has 2 rings that think the ethernet is 28EEE and organization B's 3 rings think the ethernet has a different internet ID). Is this reasonable??? The only thing that this doesn;t have is organization-organization transparent file transfer (other than ftp). - mail can be handled by creating gateways for SMTP between the organizations or rings (everyone uses the SAME subnet for the ethernet using TCP)...is this also OK?? I guess the real problem is that the Apollo networks are SO transparent, it's a bit tough to lock other rings out for valid real-world reasons. If you're in a 300 or so node network that comprises 10 organizations, you should be able to set things up so there can be local control of their areas and not require "company-standards". Feel free to e-mail how you're set up if you've come up with a solution to these problems...any ideas will be appreciated. -- Vince Skahan UUCP: lgnp1!vskahan Internet: skahan@boeing.com
krowitz@RICHTER.MIT.EDU (David Krowitz) (10/24/88)
If you were at the ADUS conference, there was a talk on a new distributed registry which comes with SR10. It allows for seperate sys_admins, each of which has control over their own accounts and not over each others. Apparently each entry in the registry has an "owner" slot which says who can change that entry. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
giebelhaus@hi-csc.UUCP (Timothy R. Giebelhaus) (10/25/88)
In article <14@lgnp1.MASA.COM> vskahan@lgnp1.MASA.COM (Vince Skahan) writes: >[...not necessarily "flame on" but certainly "bitch on"...] > > - apollo says use one master registry but we have very different >organizations with very different ideas and needs for security. >This leads to the need to use more than one master registry. If you are going to use native ethernet, then, yes, it makes sense to use one registry as the definition of native ethernet is to have one file system. If you wish, you can have seperate file systems, though. You can have completely seperate rings with nothing but the "standard" UNIX TCP applications joining the rings. You would have to use rcp or ftp to gain access to files on a remote ring. >- the "canned SIDs" for administrators and system accounts/ppo's results >in a sys_admin in one registry having the same priv's in other registry >rings (internets), making everyone everywhere open to problems created >by well-meaning but rookie admin's (and hypothetically >not-so-well-meaning folks). I'll assume native ethernet here. The trick to this is to have a master administrator who has the root and %.sys_admin account. Then using the extended acls, add other users to have access over exactly the files on exactly the machines they should have access over. For example, say your different rings are "sales", "r_d", "marketing", and "finance". You give a user on the sales ring the account user.admin.sales and acl either all the files in the sales ring so that %.admin.sales has access or just some files so that %.admin.sales has access. In the SR10 registry system, you can divide the registry reponsibilities also. Perhaps you will want user.admin.sales to only have access to %.%.sales accounts. There will be a paper on the SR10 registry system at the next USENIX. Granted, however, that there are some things that the user.admin.sales user will not be able to do without help from the root user (such as set the sticky bit on a root owned program). It is my belief that the system outlined above is in general much more flexible, more secure, and easier to administrate for more applications than not using the native ethernet. For example, say someone in sales wanted to make a file availble to the people in marketing also. The people in marketing could have transparent access to it as soon as the person in sales gave them access. No networking commands need be learned by the users. If you have more questions about this, please feel free to mail them to me. -- UUCP: uunet!hi-csc!giebelhaus UUCP: tim@apollo.uucp ARPA: hi-csc!giebelhaus@umn-cs.arpa ARPA: tim@apollo.com Tim Giebelhaus, Apollo Computer, Regional Software Support Specialist. My comments and opinions have nothing to do with work.
long-morrow@YALE.ARPA ("H. Morrow Long") (10/25/88)
In your article you write: >From: vskahan%lgnp1%dsinc%vu-vlsi%cbmvax%bpa.uucp@rutgers.edu (Vince Skahan) >... >- there is an inherent trade-off between the idea of transparent access >from all nodes in all rings to one another and the real world problems >of different organizations on the same ethernet who need access to >common Vaxes (with TCP/IP and/or access) but want to protect the heck >out of everything to keep *their* system under reasonable control. >... >Is this reasonable??? The only thing that this doesn;t have is >organization-organization transparent file transfer (other than ftp). >... >I guess the real problem is that the Apollo networks are SO transparent, >... Sounds like you might want to run NFS between your rings, mounting each ring in each others global root, this would allow ordinary users to 'read' world-readable files and users with accounts (userids) on both rings to have owner (rwxd) access to their files on the remote ring. This would provide somewhat more 'firewalling' of security problems between rings (than the Domain filesystem) at the cost of less transparency and functionality (currently you can't store - and use - many file type objects under Aegis on NFS filesystems). H. Morrow Long Mgr. of Dev. Yale U. CS Dept. Computing Fac.
vskahan@lgnp1.MASA.COM (Vince Skahan) (10/25/88)
I know all about the SR10.0 stuff but unfortunately, third party and company software prevents me from going to 10.0 until this time next year...by that time we'll have about 15 rings under at least 5 organizations so that's why I asked the questions about locking out other admin's (from the other rings) until SR10.0 when I'll have a bit more control. Of course, from what I hear about SR10, I'll have to have only one master registry but can use local node owner (etc) to help control the internet... -- Vince Skahan UUCP: lgnp1!vskahan Internet: skahan@boeing.com
lnz@LUCID.COM (Leonard Zubkoff) (10/27/88)
Actually, it's not pretty, but you *can* have multiple multiple master registries on the same network; it is, however, a bit of an administrative nightmare. What you need to do is manually arrange that all the person, full_name, project, and organization information matches, with only the account files being different. This will allow the ring-segments to interoperate reasonably, but somewhat inhibit logins from one segment to another. Note that if a user has physical access to a machine, of course, they can just netboot off a node in their own segment and gain control that way. One problem is that is essentially impossible to get around is the pervasiveness of root/locksmith, but if a file has acl's that allow only local access (every line of the form p.p.o.node_id), then I believe even remote root may be protected against. Of course that means you better not allow crp or rlogin. If you want any sharing at all, it's next to impossible to really protect yourself against a malicious user on another segment. For example, even though NFS by default maps root to nobody so that special access is not granted, a system administrator on one segment (or on any remote NFS system) could create a user id that matches yours, and then su to that id and access your files via NFS. Leonard
weber_w@apollo.COM (Walt Weber) (10/29/88)
Vince Skahan raises the admin issue about "domains of control" (a
Domain/OS term) under sr9.7.
The only approach I can identify is making the following tradeoff decision:
a) if you need to run DOMAIN services (file access, crp -on, etc.) over
the link or across a gateway, then both segments share a common view
of user identity and must operate from a single registry database.
b) If you need separate registries for network segments, then do NOT utilize
domain routing services over the gateway, and instead route only
tcp/ip packets across the gateway. Interconnect between the networks
would then be via telnet/rsh/ftp/nfs , as opposed to the Domain
protocols.
...walt...
--
Walt Weber Apollo Computer
(508) 256-6600 x7004 People's Republic of Massachusetts
-The views expressed herein are personal, and not necessarily Apollo's-achille@cernvax.UUCP (achille) (10/31/88)
Hi there, I think what Vince Skahan is asking for is really the possibility to run more than one 'logical' Domain ring on the same physical Ethernet. That's also exactly what we would like to do. Tricks with the internet routing will not help in this case. Achille Petrilli, Cray and Personal Workstation Operations