lori@hacgate.scg.hac.com (Lori Barfield) (06/02/89)
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.) 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. 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. Help! What did YOU do? ...lori
vskahan@lgnp1.LS.COM (Vince Skahan) (06/03/89)
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...
krowitz@RICHTER.MIT.EDU (David Krowitz) (06/05/89)
Apollo has always provided the concept of node_admin's in addition to that of sys_admin's. The sys_admin account is *meant* to be the account for controlling the *entire* integrated network (along with root and locksmith). If you want to make accounts that have control only over a certain subset of the entire network, then create accounts of the form 'user.node_admin.subset.%' and add ACL entries on the nodes they control which are duplicates of the sys_admin entries. Sys_admin accounts should only be given to those people who are *supposed* to have priviledges on *all* machines. The root account is a problem. Unix compatibility requires that it have 'locksmith' priviledges. If it does not have complete privildges, then you lose Unix compatibility. it's a clasic catch-22. Unfortunately, you must have a 'root' account to perform day-to-day system administration functions on a Unix machine (unlike the Aegis 'locksmith' account, which is usually only needed in extreme circumstances). If you want to have Unix installed on a netowrk of integrated workstations, then you either must accept that every 'root' user has access to everything, or you must turn your local system administration over to a centralized (and trusted!) group. 'root', as defined by Unix standards, is equal to 'locksmith', as defined by Aegis. -- 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)
nazgul@apollo.COM (Kee Hinckley) (06/07/89)
In article <3877@hacgate.scg.hac.com> lori@hacgate.scg.hac.com (Lori Barfield) writes: >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. Unlike some of our competitors', the Apollo network really *is* treated as a single computer :-). However there are some things that you can do. >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 True, but you can protect your node from crp'ing on a per-user/group/org basis using the standard acl systems (see the man page entry below, I believe this applies to SR10.1 and greater, but I could be wrong). You may also be able to set protections (particular on the spm_control file) so that only users actually on that machine can modify files. See the man page on "lprotect". LPROTECT(8) Domain/OS BSD LPROTECT(8) NAME lprotect - control local protection SYNOPSIS /etc/lprotect [-rmtroot all | none | readonly] DESCRIPTION lprotect controls what privileges processes running as root (locksmith) on remote nodes have on the local node. The argument you supply to the -rmtroot option controls these privileges: .... From the man page on "spm". .... Controlling Access to a Node spm can optionally prevent unauthorised users from creating processes on a node or logging in. If the file `node_data/spm_control exists on the node running spm, all process creation and login requests are validated and only users with a SID matching an entry in the file are allowed access. If the file does not exist all requests are allowed. If present, the control file should contain a list of SIDs, one per line, specifying users that are authorised. Each entry should be specified as follows: user.group.org where a % character in a field matches anything. Examples: Allow access to all users %.%.% Allow access to all members of group grp %.grp.% I hope that helps some.
FERGUSON@TMASL.EXXON.COM (06/07/89)
I haven't put sr10.1 on yet, but it came in the mail with a big note
saying:
DON'T USE /etc/lprotect!!! You'll die if you do
(or something to that effect :-)
Has that been fixed? Is there another patch I haven't seen?
I can't put sr10 on for months, because I have non-Apollo peripherals,
but I saw a recent suggestion to use lprotect, and don't remember hearing
that it was safe to use yet.
Scott Ferguson
ferguson@erevax.bitnet
Exxon Research & Engineeringthompson%animal.decnet@CIM-VAX.HONEYWELL.COM ("ANIMAL::THOMPSON") (06/13/89)
Aaarrggghhh. We were told, when SR10.1 came out to us, NOT, REPEAT NOT, to use the 'lprotect' command lest horrible nasty things happen to us. As I understood (understand) it, lprotect is buggy, and may prevent normal root processes from functioning. (Trivial things like init, tcpd, dm, ....) What's the scoop? Was it changed, and we weren't told? Or are we being given bad, dangerous information now? For what it's worth, the spm access control file works just fine. John Thompson Honeywell, SSEC 12001 St Hwy 55 Plymouth, MN, 55441 The above ramblings are my own, and have little if any bearing on my employer.