Re: More security issues

["Pierre A. Humblet" <Pierre.Humblet@ieee.org>]

Corinna Vinschen wrote:
> 
> I don't understand that description.  Could you try to explain
> in other words?  What do you mean by "natural group"?  Primary
> group as set by Windows (RID 513, "None" or "Domain Users",
> typically) or the primary group as set in /etc/passwd or ...?

When an internal token is created, groups come from two sources:
1) the "natural groups" including those associated with the user
on the logon server and some of those associated with the current 
process token
2) the primarygroupsid, which in many applications is also 
a natural group but in others (e.g. mail server) isn't. 
When the primary group is not a natural group the token has more
rights that the "normal user" and caution must be exercised when 
reusing it. 

> > 4) the primary group that was used when creating an internal token
> > is now saved in the token sd. This allows to set the token default
> 
> With what access rights?  The pgrp shouldn't have write access
> to the token's sd, isn't it?
I agree, it (usually) has no access. It's simply used as a 
storage spot.
 
> > primary group appropriately if the user calls setegid() after
> > creating the token, e.g. seteuid(uid1) .... setegid(gid1) ....
> > [can this order be legitimate ?].
> 
> That won't work due to the create_token call being only in
> seteuid().  This would require a redesign.

It works when gid1 is a "natural group". I am just trying to insure
that it works in as many reasonable cases as possible.

> > 9) get_dacl() (in security.cc) gives no access to admins if the
> > user is not in the admins group. I don't understand the logic.
> 
> It's Windows logic.  This is how a default security descriptor
> is created.
> 
> > My suggestion is to call instead the new sec_dacl() (see above),
> > which always has system, admins, sid1, [sid2] and creator/owner.
> 
> Why?  What's the effect you want to get by this?
Adherence to the policy that admins always has access, as in sec_user().
Actually it's not a good enough reason, I won't do it. 
Also allows code reuse, but this can be done easily enough.

> > 11) Can cygwin_logon_user() be called by a user not in admins?
> 
> Yep.  Don't think in groups here, it just depends on the privileges
> set for the user in the security policy.  Up to W2K the user needs

I fully agree, so I just created a local account, no admins, just TCB + 
IncQuota + ReplaceToken (just in case...). Token creation and impersonation
go fine (with the standard cygwin1.dll). However when forking I hit
Impersonate for forked child failed: 1307 
I will investigate.

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/