RE: Windows NT does not check permissions after HANDLEs are open

From: Michael Wojcik (Michael.Wojcik@merant.com)
Date: 08/30/01


Message-ID: <27B17B8B25A3D411B45800805FA7F01C012E2604@mtvmail.merant.com>
From: Michael Wojcik <Michael.Wojcik@merant.com>
To: VULN-DEV@securityfocus.com, FOCUS-MS@securityfocus.com
Subject: RE: Windows NT does not check permissions after HANDLEs are open
Date: Thu, 30 Aug 2001 08:49:33 -0700


> From: Syzop [mailto:syz@dds.nl]
> Sent: Thursday, August 30, 2001 5:59 AM
> To: c0ncept@hushmail.com
> Cc: VULN-DEV@securityfocus.com; FOCUS-MS@securityfocus.com
> Subject: Re: Windows NT does not check permissions after HANDLEs are
> open
>
> c0ncept@hushmail.com wrote:
>
> > The check against the ACL only occurs when the HANDLE
> > is first opened, however. If a HANDLE is opened and
> > permissions on the objecect subsiquently change, the original
> > requestor of the object retains the original access-permissions.

> Isn't this normal?

Yes, it's pretty typical for discretionary access control (DAC) mechanisms
to perform access checking when a subject first requests access to an object
(eg. opens a file) and grant that access (if allowed by the DAC) for the
subject's lifetime or until it's specifically relinquished (eg. by closing
the handle).

In principle, a reference monitor should check every access, but "every
access" is pretty vague. Should the monitor check every operation a subject
performs on an object - eg. every read and write on a file - against the
current ACL? That would be expensive, so instead most systems establish a
boundary at which a subject (eg. a program, running with the rights of a
particular user, who may belong to one or more groups) is granted access to
an object for any number of subsequent operations (generally of certain
kinds - eg. you open a file for reading or writing or read-write). Once the
subject is past that boundary the monitor remembers its decision for that
{subject, object, operation(s)} tuple and doesn't need to revisit the ACL.

This is indeed an issue for timely revocation of access, but it's a
well-known one, and arguably not much of a threat in most cases. See for
example the aside about revocation in capability-based DAC implementations
in section 7.1 of the Rainbow book on DAC mechanisms.[1]

[1] http://security.isu.edu/isl/dac.html

Michael Wojcik
Principal Software Systems Developer, Micro Focus
Department of English, Miami University