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

From: Michael Wojcik (Michael.Wojcikat_private)
Date: Thu Aug 30 2001 - 08:49:33 PDT

  • Next message: Dave Aitel: "Re: solaris gdb screen mayhem"

    > From: Syzop [mailto:syzat_private]
    > Sent: Thursday, August 30, 2001 5:59 AM
    > To: c0nceptat_private
    > Cc: VULN-DEVat_private; FOCUS-MSat_private
    > Subject: Re: Windows NT does not check permissions after HANDLEs are
    > open
    > 
    > c0nceptat_private 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
    



    This archive was generated by hypermail 2b30 : Thu Aug 30 2001 - 09:14:48 PDT