Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Message-ID: <3C51723E.4010F766@ieee.org>
Date: Fri, 25 Jan 2002 09:57:02 -0500
From: "Pierre A. Humblet" <Pierre DOT Humblet AT ieee DOT org>
MIME-Version: 1.0
To: Corinna Vinschen <cygwin AT cygwin DOT com>
Subject: Re: security.cc: bug report, question and suggestion
References: <3C4EFF65 DOT FF7BA4DE AT ieee DOT org> <20020123194126 DOT H11608 AT cygbert DOT vinschen DOT de> <3C506701 DOT A334DC8A AT ieee DOT org> <20020124215729 DOT J11608 AT cygbert DOT vinschen DOT de> <3C5079FB DOT BD4E6FD2 AT ieee DOT org> <20020125115542 DOT Q11608 AT cygbert DOT vinschen DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Corinna Vinschen wrote:

Hi Corinna, I have rearranged the order of your questions.

> The registry you're trying to access, is that a key below HKCU or
> HKLM?  

Special keys:
HKLM
"SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib\\009
and
HKEY_PERFORMANCE_DATA
Although the first key above is under HKLM, it is not a "regular"
key. There is an article (bug report) about it on the Microsoft
site, but I don't find it right away. The bug report is irrelevant
here, it's about trouble after reading the key 64k times.

> I see now that I don't know of which user you're talking here,
> the user who's *creating* the token or the user who's going to
> be *impersonated* by the token?

The impersonated one, after setuid()
No problem whatsoever with the creator ("self" in Microsoft language).
 
>In which situation does the application try to read the
> registry key, before or after the successful setuid() call?  Does
> the application even try to read the registry key after setuid()
> or does a exec'd child process try to do that?

It fails after the setuid() and after a subsequent fork(). 
It succeeds after an exec()  

After trying different things, I believe it fails because the
impersonated user does not have access to its own token. When
I NULL the token DACL (giving access to everyone) the impersonated
user can read the keys. Also after an exec() the usersid 
appears in the token SD DACL.

> I have my own token print application which I changed to print
> the security descriptor (SD) of the token additionally.  What I found
> was:
> 
> - The owner returned by TOKEN_OWNER is the same as the owner of
>   the token's SD.
> 
> - The group returned by TOKEN_GROUP is the same as the group of
>   the token's SD.
> 
> - The DACL returned by TOKEN_DEFAULT_DACL is the same as the DACL
>   of the token's SD.

That's what I see for the original process token. However it's
different for the impersonated token. What I see is that the default
DACL is exactly as expected from get_dacl() in security.cc (usersid 
and system) but that the token SD DACL has admin and system, with
no access by the impersonated user of the impersonated token.
As I said  above, when I clear the SD DACL as follows
  /* Now clear the ACL */
  if (!OpenThreadToken(GetCurrentThread(), WRITE_DAC,
                       TRUE, /* OpenAsSelf (self=process) */ 
                       &ThreadHandle))
	printf("OpenThreadToken %ld\n", GetLastError());

  if (!(InitializeSecurityDescriptor(&sd, SECURITY_DESCRIPTOR_REVISION) &&
        SetSecurityDescriptorDacl(&sd, TRUE, NULL, FALSE)))
	printf("SecurityDescriptor error %ld\n", GetLastError());

  if (!SetKernelObjectSecurity(ThreadHandle, 
                               DACL_SECURITY_INFORMATION,
                               &sd))
        printf("SetKernellSecurity error %ld\n", GetLastError());
then the impersonated user can read the key. The right thing to do
of course is to build the correct DACL (usersid + system + admins)
instead of having a NULL DACL, which is what sec_user() is doing, 
as far as I understand.

> So, actually there's no need to distinguish between the token and
> it's SD.
I don't understand what you mean...

Pierre

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/