This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: security.cc: bug report, question and suggestion


On Fri, Jan 25, 2002 at 09:57:02AM -0500, Pierre A. Humblet wrote:
> 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()  

Got it.

> 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.

That sounds weird, though.  It doesn't make sense.  The DACL
for the token only sets the permissions for accessing the token
and not for accessing other objects.

Hmm.

OTOH..., if the process can't access the token it doesn't know about
it's own permissions.  But why should only accessing a registry key
be affected and not accessing files?!?

Don't get me wrong but somehow I'm missing the *reason* for that
behaviour.

> > - 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
> [...]
> 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.

That's correct.  sec_user() creates a SECURITY_ATTRIBUTES struct (SA)
with four SIDs, the current user, admins group, system and creator_owner
by default.  If you give an additional SID as parameter, it creates a SA
with five SIDs, current user, the additional SID, admins group, system
and creator_owner.

The latter call is the one I added to the DuplicateTokenEx() call
to create this sort of SA with five SIDs, the current user, the
impersonated user (additional SID parameter), admins, system and
creator_owner.

And you say that this doesn't help at all?  Hmm, I will have to
debug that further.  SIGH!

Could you send your minimal testcase, please?

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

It might not be important.

Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]