Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Wed, 18 Apr 2001 20:29:43 +0200
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygdev <cygwin-developers AT cygwin DOT com>
Subject: Re: handle protection - please comment
Message-ID: <20010418202943.O15005@cygbert.vinschen.de>
Reply-To: Corinna Vinschen <cygwin-developers AT cygwin DOT com>
Mail-Followup-To: cygdev <cygwin-developers AT cygwin DOT com>
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF79C2 AT itdomain002 DOT itdomain DOT net DOT au> <20010418120530 DOT Q15962 AT cygbert DOT vinschen DOT de> <00a401c0c7f0$02bb1f30$0200a8c0 AT lifelesswks> <13327115627 DOT 20010418144700 AT logos-m DOT ru> <20010418155552 DOT S15962 AT cygbert DOT vinschen DOT de> <175340295909 DOT 20010418182640 AT logos-m DOT ru> <20010418164712 DOT J15005 AT cygbert DOT vinschen DOT de> <53342543912 DOT 20010418190408 AT logos-m DOT ru> <20010418173712 DOT N15005 AT cygbert DOT vinschen DOT de> <107348915634 DOT 20010418205020 AT logos-m DOT ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <107348915634.20010418205020@logos-m.ru>; from deo@logos-m.ru on Wed, Apr 18, 2001 at 08:50:20PM +0400

On Wed, Apr 18, 2001 at 08:50:20PM +0400, egor duda wrote:
> CV> Uhm, ok, but from my point of view it's an academic problem.
> CV> The PROCESS_DUP_HANDLE permission on a process handle does _not_
> CV> open up the other handles of a process if the access rights of
> CV> these handles are set using appropriate values.
> 
> not academic, but rather practical. unfortunately. here's the
> demonstration.
> 
> CV> For example process A has a handle H with ALL_ACCESS for the user
> CV> of A and with R/O for the world. Giving it's process handle to
> CV> process B of another user doesn't allow suddenly R/W access to
> CV> process B. The user of B doesn't have that permission. So he's
> CV> stuck at that point. It's in the responsibility of process A not
> CV> to open up it's resources to others.
> 
> gcc -o /tmp/t.exe t.c
> 
> from admin account:
> $ echo "secret info" > /tmp/secret
> $ chmod 600 /tmp/secret
> 
> from normal user account start /tmp/t.exe
> it'll print 'slave pid=<some pid>'
> and blocks waiting for input.
> 
> then switch to admin account and run '/tmp/t.exe <slave_pid>'
> it'll print 'master handle=<handle1> object handle=<handle2>'
> 
> switch back to client account and input <handle1> and <handle2>
> values.
> 
> now look what /tmp/secret contains.

I didn't test it but I assume it contains "Kaboom!". Hmm. I'm somewhat
distressed about that result. So the secure way to get a handle to any
shared object is by accessing it using names as suggested by Robert.
This doesn't apply to parent/child relations, obviously.

RC> The thing egor as talking about was child process's needing to read the
RC> parents open handles, and that programs than setuid are apparently
RC> setting the perms to everyone, all to allow the child process with it's
RC> different uid to read the handles. He was proposing a server model,

Wouldn't that problem (which originally was related to ttys) be resolved
if the master cares for the duplication?

Corinna

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