ts@cup.portal.com (Tim W Smith) (12/23/88)
One of the desired features listed at that first CAM meeting was to allow both user and kernel access to SCSI. Has anyone considered the security implications of this? Even if CAM prevents used code from accessing devices that are being used by the kernel ( or other users ), there is still the problem of the COPY command. Or will CAM have to restrict the SCSI commands available from user mode? Tim Smith
ward@cfa.harvard.EDU (Steve Ward) (12/25/88)
I think that CAM ought to be kept lean and mean and as OS independent as possible. I do not want CAM itself to deal with OS security as this will complicate it and invariably make it less portable. Each OS implementation can deal with security as it sees fit. Two possible ways: first, make CAM access privileged, but if you have permission, you can get at all of CAM. This is like system privilege in most OS's. Second, implement a "system OS front end" to CAM. CAM is privileged, but access is indirect through the OS so that privileged access can be refined and controlled on a device by device basis and even by requested operation. In any case, CAM should be designed for efficiency, simplicity, and portability so that it can move from simple embedded applications to larger OS's with a minimum of porting grief. Steve W. ward@cfa.harvard.edu
jlohmeye@entec.Wichita.NCR.COM (John Lohmeyer) (12/27/88)
In article <12872@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >One of the desired features listed at that first CAM meeting was to >allow both user and kernel access to SCSI. Has anyone considered >the security implications of this? Even if CAM prevents used >code from accessing devices that are being used by the kernel ( or >other users ), there is still the problem of the COPY command. Or >will CAM have to restrict the SCSI commands available from user mode? > I doubt that anyone at the CAM meeting seriously regards CAM as a secure interface. The principal problem that the group set out to solve was to allow software drivers to be independent of the installed host adapter. As such, I regard this as a very low level interface and not necessarily available to users. Whether to allow user access depends on the operating system policies. If the system is MS-DOS, it probably would (couldn't really prevent it). Other systems with better security simply would not let the user have access to such an interface. They would have to do whatever is necessary to enforce their own security rules. There is a faction within the CAM group that wants a higher level interface to be defined. Perhaps even one that is independent of the I/O interface below (e.g., SCSI, ESDI, ST506, etc.). At this higher level, it is indeed feasible (and perhaps desirable) to include security. I would like to see this higher level interface defined -- later. Our first priority should be the original task: to define a host adapter independent interface. This task is not too difficult to accomplish quickly and is really NEEDED. The higher level interface will be a more difficult task and as such will take more time. (The difficulty is not technical, but rather political.) Of course, the higher level interface should use the low level interface when talking to SCSI devices. BTW, the next SCSI-2 CAM meeting is January 12 at the Red Lion Inn in Costa Mesa, CA. There is no charge for attending this meeting. If you want to get the mailings from the CAM Committee, there is a one-time charge of $200. If you want a voting membership, there is a $2000 charge which includes one mailing subscription. Contact Dal Allan at (408) 867-6630 for more information. John Lohmeyer NCR Corporation J.Lohmeyer@Wichita.NCR.COM
wilker@batcomputer.tn.cornell.edu (Clarence W. Wilkerson Jr.) (12/28/88)
I would like to mount a floppy disk on my SUN 3/50 with its SCSI bus. Does someone make such a gadget? I have XEBEC SASI 1420 with a floppy interface, but I have not seen a SCSI version.