HELLER%cs.umass.edu@CSNET-RELAY.ARPA (Stride 440 User) (08/15/86)
>From: McGuire_Ed%GRINNELL.Mailnet@MIT-MULTICS.ARPA >Subj: VMS: questions about LP11s and file security > >Any ideas about the following problem would be most appreciated! > >We have some disks on our cluster that are mounted /SYSTEM on some nodes but >not mounted at all on others. This is so that files on these "sensitive data >disks" cannot be accidentally made available to students, who have accounts on >nodes where the disks in question are not mounted. > >Our two LP11 printer controllers are currently installed in two 750s on the >cluster. When printing files, the disks where the files reside must be mounted >on the 750s for the print symbionts to open them. Therefore, the sensitive >disks have been available from these nodes. > >Soon we will be authorizing students on the 750s. We wish to discontinue >mounting the sensitive disks on the 750s. This has been a very easy way to >protect that data. Unfortunately, the print symbionts would not be able to >print files on the sensitive disks if we did this. > >Our alternatives, as I see them, are to leave the disks mounted or to move the >printer controllers. But if we leave the disks mounted, we need a different >security mechanism for those disks that is as easy to maintain and as efficient >as our current method. But we have no secure system to move our LP11s to >except one of our 8600s, and I've heard horror stories about performance of >8600s when LP11s are active on the UNIBUS. There is a possibly easy solution to this question. It is to create a rights identifier for the sensitive data (posible several identifiers if the data can be reasonably compartmentalized (ie SECURE_ACCOUNTING for accounting info and SECURE_GRADES for grades, etc.) and add this (these) identifier(s) to the rightslist DB for the "authorized personal" and not to the students. Then set the ownership of the root directories (or maybe sub-directories) to the appropriate identifier and world protection to zip (it does not really matter what the protection is on the files and subdirecteries is, since if one can't access the root, then the whole tree is inaccessable). You can then leave the disks mounted /SYSTEM on any node, whether there are students on that node or not. An alternitive is to use group UIC's - put the accounting people in one group and make all of their root files owned by some group member with world protection set to zip. Of course if there is group overlap this won't work. The rightslist identifiers in effect create "super groups" - everybody with identifier XXX are in the group XXX and can get at any file owned by identifier XXX. People who don't have identifier XXX can only touch files owned by XXX if the world protection lets them. (Of course people with SYSPRV or a system UIC can access files based upon system protection, but I am assuming you aren't giving students SYSPRV or system UICs!) I don't know anything about LP11's and 8600 UNIBUS's (I am mainly a software person), but you would probably do better if you leave the LP11's on the 750's since if the 8600 goes down, you can give access to the 750's to the people who need to keep working (maybe kicking the students off for the duration of the "emergency" or reducing their hours to non-prime time, etc.). Robert Heller ARPAnet: Heller@UMass-CS.CSNET BITNET: Heller@UMass.BITNET BIX: heller GEnie: rheller
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (08/17/86)
> >Subj: VMS: questions about LP11s and file security
I find it hard to believe that not one, but several people, have submitted
'solutions' to this problem without bothering to see if they had the slightest
chance of working. In particular, the one fallacious assumption that seems to
be more common than I would have believed is that: "it does not really matter
what the protection is on the files and subdirecteries is, since if one can't
access the root, then the whole tree is inaccessable". This assumption
has turned up in two separate submissions, and it points out the crying
need for some documentation on how a FILES-11 ODS works, and how RMS deals
with one. You DO NOT have to have access to the MFD (master file directory,
not "root") in order to access the rest of the files on the disk, unless
they all reside in the MFD. In order to protect all the files on the disk,
you would have to set an acl on every directory on the disk. And besides,
there's a much more straightforward way of doing this:
$ SET ACL/OBJECT_TYPE=DEVICE/ACL=(ace,....) device_name
Sets an acl not on the files, but on the device itself. Thus, there need
be only one ACL checked per channel assignment to the disk; you don't have
to hope that nobody makes a good guess as to the names of the user-file
directories on the disk and therefore gets access to the files without access
to the MFD, and if you want to change your policy regarding access, there's
only one ACL that has to be modified. CHRIS@engvax.UUCP (Chris Yoder) (08/18/86)
> [create Identifiers] >Then set the ownership of the root directories (or maybe sub-directories) to >the appropriate identifier and world protection to zip (it does not really >matter what the protection is on the files and subdirecteries is, since if >one can't access the root, then the whole tree is inaccessable). Ummm, I believe that that last phrase is in error. Protecting a file by it's directory protection *only* is not entirely secure. If someone gets ahold of the file-id of the file, they can access the file based on *it's* protection. Of course, one cannot do this directly from DCL, and you need to do some fun calls to RMS in the program that accesses it, but in any given group of students you have a small subset that are 1) very, very clever and 2) most interested in breaking into files/systems that they are not supposed to get access to. Thus you should always protect each file with the access that you want *it* to have. I haven't seen ACL driven access to a file system drive a system to it's knees yet. You only really have to worry about it when you start getting "long" ACLs on every file. VMS first checks each ACE in the ACLs in order, then the UIC based protection. It stops checking when it hits the first thing that guarantees access or denys access. If you set up things right so that the first ACE checked is the one that is most often used, then I doubt that you will see any real decrease in performance, unless you are accessing a lot of files over a short period of time. (I guess what I'm saying is, don't be afraid to use ACLs, just use them sparingly and efficiently.) -- Chris Yoder UUCP -- {allegra|ihnp4}!scgvaxd!engvax!chris Hughes Aircraft Company ARPA -- engvax!chris@csvax.caltech.edu