amull@Morgan.COM (Andrew P. Mullhaupt) (03/20/90)
What kind of protection does OS/2 HPFS allow? Is there more than just DOS-style 'Hidden' and 'Read-Only' attributes? Is there any notion of password or restriction of access? Thanks in Advance, Andrew Mullhaupt
alistair@microsoft.UUCP (Alistair BANKS) (03/22/90)
security beyond FAT (read/hidden/system/archive bits!), but LanMan 2.0 has a version of HPFS called HPFS386 which is still the HPFS format, but has security built into the file system - that is, you have to log on with a named account and password to get access priviledges to your LOCAL disk. Those priviledges are read, write, execute(only), change permissions, create, delete and these permissions are applied on a per-file basis according to your account name, and what account groups you are in. The upshot of this is that LanMan 2.0 gives your local machine 'real' security and os/2 1.2 does not. Alistair Banks OS/2 Group Microsoft
alistair@microsoft.UUCP (Alistair BANKS) (03/22/90)
my previous article lost its first line... it read:- OS/2 1.2 has not greater security than dos fat (read on...)
gordonl@microsoft.UUCP (Gordon LETWIN) (03/22/90)
In article <789@s6.Morgan.COM>, amull@Morgan.COM (Andrew P. Mullhaupt) writes: > What kind of protection does OS/2 HPFS allow? Is there more than > just DOS-style 'Hidden' and 'Read-Only' attributes? Is there any > notion of password or restriction of access? The HPFS available under OS/2 1.2 only allows the "protection against accident" features of DOS: Hidden and Read-Only. The file system itself - and the disk format - allows the specification of a powerful access control mechanism. My fingers aren't up to typing a full description, but basically you can specify an arbitrarily long list of "ID = permission" records. You can also have "exception" records: "ID is deny permission" so that you can deny permission to specific members or subgroups of groups. These records can also describe who has permissions to change or grant permissions. The general idea is that file server sites can setup administrators who have the ability to sub-administer stuff so that you don't have to give out "super user" passwords. There's also an auditing facility so that you can keep track of who is either granted or denied access to your stuff. You can set it up so that you grant someone else the ability to adminster access to your files, but they can't turn off auditing, so that you can always know who they've given access to and they can't hide that from you. This facility is used "somewhat" in the current release of the LAN manager. I'm pretty sure - but not positive - that LAN manager just uses a subset of the full HPFS protection mechanism to provide a more efficient implimentation of the LANMAN security services available under FAT. Clearly, we have future plans to expose the full facilities of the design. OS/2 1.2 has no APIs for file ACLs. If you mount an HPFS disk which has ACLs, OS/2 1.2 will refuse to access those files which have ACLs set on them, since he doesn't know how to interpret the ACLs. Yes, you can write a direct-physical-read program and still get the info; we just didn't want to make it too easy and obvious to circumvent the ACL security by just booting up a non-lanman OS/2. A future OS/2 release will contain the necessary support for ACLs. As others have noted, the IOPL=YES business for the 286 precludes most general purpose systems (i.e., ones that need IOPL=YES) from ever being fully secured. And likewise the "real mode box" precludes full protection. But OS/2 is designed so that a future release, *running on a 386*, can be fully secured. The key points are 1) an ACL mechanism for the file system. See above 2) restricting the activities of real mode programs. Virtual 8086 mode on 386s will allow this 3) Allowing programs to have direct I/O access to some ports - such as video control ports - while denying them access to other I/O addresses, such as the disk controller. The 386 has a bitmap table which allows per-port I/O access; Intel put this into the chip at Microsoft's request specifically to allow us to close this security window. Bottom line, a future release of OS/2 will be "fully secure" and thus immune from viruses 1) modulo any security holes due to system bugs. Like any other OS, OS/2 will have these. I expect that the discovery and cure rate will be high due to the large # of users. 2) modulo setting up the system correctly. Any secure system must be setup correctly in order to be fully secure. I don't know what we'll do here, specifically, but given that our users don't have to do as much system fiddling as UNIX users - at least the old V7 UNIX - it should be easier to have the install program set things up secure and to expect them to stay that way. We've worried about security - both viruses and malicous (sp?) attack - from day 1. But it's taken both time and the necessary hardware (the 386) to do the job and still allow programs to be written the way that ISVs want to write them. (I.e., the traditional device security model says, "just use a device driver", but many PC programs insist on direct hardware access to improve their performance.) Gordon Letwin microsoft
feustel@well.sf.ca.us (David Alan Feustel) (03/23/90)
What is the product name of Lanman2.0? How is it (or more info about
it) obtained?
--
Phone: (home) 219-482-9631
E-mail: feustel@well.sf.ca.us {ucbvax,apple,hplabs,pacbell}!well!feustel
USMAIL: Dave Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805feustel@well.sf.ca.us (David Alan Feustel) (03/23/90)
How about a bitmap specifying user/system handling of software
interrupts and a 370-style virtual machine capability for the 586?
--
Phone: (home) 219-482-9631
E-mail: feustel@well.sf.ca.us {ucbvax,apple,hplabs,pacbell}!well!feustel
USMAIL: Dave Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805