🚀 go-pugleaf

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