Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Message-Id: <3.0.5.32.20011230112615.00813e60@pop.ne.mediaone.net>
Date: Sun, 30 Dec 2001 11:26:15 -0500
To: Corinna Vinschen <cygwin@cygwin.com>
From: "Pierre A. Humblet" <Pierre.Humblet@ieee.org>
Subject: Re: security.cc: bug report, question and suggestion
In-Reply-To: <20011229231505.O27340@cygbert.vinschen.de>
References: <3.0.5.32.20011229152301.0083a1f0@pop.ne.mediaone.net>
 <3.0.5.32.20011229152301.0083a1f0@pop.ne.mediaone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:15 PM 12/29/01 +0100, Corinna Vinschen wrote:
>On Sat, Dec 29, 2001 at 03:23:01PM -0500, Pierre A. Humblet wrote:
Thanks Corinna, that was fast!

>> Bug in security.cc:
>Thanks for the heads up.  I've checked in a patch.
It works, thanks. The following alternative
 LSA_HANDLE lsa;
 NTSTATUS ret = LsaOpenPolicy(NULL, &oa, POLICY_ALL_ACCESS, &lsa);
 if (ret!= ERROR_SUCCESS) return INVALID_HANDLE_VALUE;
would not rely at all on the undocumented way Microsoft 
sets lsa in case of failure.

>> Question:
>> is the Policy Object only accessible by administrators 
>AFAIK, it's accessible by everyone but it's only changable
>by administrators.  I've checked in a patch so that the
>call to LsaOpenPolicy() only requests the needed user rights.

You are reading my mind! I tried it without being administrator.
Now open_local_policy () goes OK but in get_priv_list ()
calls to LsaEnumerateAccountRights() (that succeed with 
administrators privilege) fail with "access denied" (although
you do specify the correct access rights in open_local_policy() )
get_priv_list () returns privs = NULL, resulting in failure.

I am also mind boggled by the behavior of setuid() running
under cygrunsrv.
Base case: user xxx runs program "prog" from the shell without admin
           (but with CREATE_TOKEN) privs. prog does setuid(y). 
           That fails, which is consistent the previous paragraph.
case 1: cygrunsrv -I ... -u xxx -p ...prog
           setuid(y) fails, as expected.
case 2: cygrunsrv -I .... -p ...prog
           prog notices it is SYSTEM and setuid(xxx). That works as expected.
           Now running as xxx, setuid(y) succeeds!
           It looks like prog has inherited unexpected rights from SYSTEM...

While I am at it, here is another weird observation:
base case above: prog reads some registry key. Succeeds.
cases 1 and 2: prog reads some registry key. Access denied.
But if xxx has admins privilege, prog can read the registry in 
cases 1 and 2...
Can this be explained somehow? It's all on a standalone Win2000.

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/