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


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/


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