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

Relevant Pages

  • RE: What server hardening are you doing these days?
    ... permissions on their data, and Microsoft encourages ISVs to minimize ... I've been able to discuss ACLs and other security issues in Windows with ... Control or DAC (which is what you're referring to by the "stupid ...
    (Focus-Microsoft)
  • RE: Read only on XP
    ... > All clients on the network are Windows XP pro with SP2. ... and open a file- the file shows as read only and it opens ... > users belong to the group and have both full file access permissions and full ...
    (microsoft.public.win2000.networking)
  • Re: Programmatically connecting to backend
    ... Server is Windows 2003, client ... given full permissions to that dir. when we say full permissions, ... Ms-access is a simple file share, and when you go mulit-user, ms-access ... When the user runs their front end, and opens the back end...a ...
    (microsoft.public.access.formscoding)
  • Cannot access word file from My Documents
    ... I have a customer with a new Dell Computer using Windows XP Home and Office 2002. ... Word opens just fine and documents saved go to the User's ... when you open the My Documents folder and select any Word file you get error messages. ... I booted in the Safe Mode to access the Administrator and check the permissions for the user. ...
    (microsoft.public.word.docmanagement)
  • read and write permission does not delete word ~ files
    ... I have a folder on Windows 2000 where the user has read&execute and write ... Whenever he opens a file from this folder word creates a ~ ... I can give him modify permissions but that seems negate the ...
    (microsoft.public.windows.server.security)