X-Recipient: archive-cygwin@delorie.com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=HFiZXnQrDkw1pBEqv+0oz2xfqf2eCElRGOCzIJDfhRe/S1AVd9wh5
	+6ZKzh/NzhI1a8U1j5qiPJmW9+dWBV4GxGnTyYwwtaCj1RsLe05wlFiFOkZ8Quh4
	8BQkclIx5kYx4pfusX+NTK8mXnOsvBh9k/YYzpkONtOyy4TyJanDl0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	 bh=wfAVNz9JUR1rmmrdtJNrfKHu4nk=; b=VV762Wcqko+tIKSCjZmBscFmjGjY
	xZyn5EdIG6ek/BC4sAJvdM6MVWyDYib/SSt6Fa/iGJA8/x2NnYXzAUOwsKSx1Le1
	zLQRGKDLmhYp3FCo1nJCHiSX53hmfys0NUdC6zDD3hSy83UWDrd8h6WM8PXChzbu
	Kbr8CqjqMSpr8LE=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO: plane.gmane.org
To: cygwin@cygwin.com
From: "D. Boland" <daniel@boland.nl>
Subject: Re: The eternal uid issue
Date: Thu, 24 Jul 2014 11:34:14 +0200
Lines: 84
Message-ID: <53D0D316.F34DBB2B@boland.nl>
References: <53CF6CEC.6D68E485@boland.nl> <20140723091409.GH27005@calimero.vinschen.de> <53CF9E0F.F596FC60@boland.nl> <1273556697.20140723200807@yandex.ru> <20140723162703.GA3951@ednor.casa.cgf.cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes

Hi Christopher,

Thanks for your reply.

Christopher Faylor wrote:
> 
> On Wed, Jul 23, 2014 at 08:08:07PM +0400, Andrey Repin wrote:
> >Greetings, D. Boland!
> >> Cygwin security will be done for in the long run. Why not make the leap and
> >> show MS admins/developers how it should be done?
> >
> >You really think they are all idiots?... Like, really?
> 
> Sure, why not.  MS admins/developers are all idiots who are apparently
> supposed to be taught by Cygwin developers who have been getting it
> wrong for many years until being correct by the OP.
> 
> To the OP: If you want to start a dialog, do research and ask questions.
> Don't just assume that you understand everything and can provide insight
> that no one else has thought of.
> 
> cgf

I didn't say 'idiots', but I did LOL at Andrey's suggestion. Andrey, I'm beginning
to like you. By the way, your english really isn't that bad.

What I meant was that MS dicided to take away impersonation privileges from the
SYSTEM user, without educating admins/developers about the new model or alternatives
for SYSTEM.

I searched the web extensively for an explanation on the newly imposed restriction.
I didn't find one yet. Only vague advice to not start services using the local
System account:

"Minimize the use of the Local System account on the site servers and site systems
by not installing other services that use the Local System account. This ensures
that other processes cannot take advantage of the enhanced privileges of the
system’s computer account, accessing Configuration Manager 2007 files and data
through those other systems."
--
source: http://technet.microsoft.com/en-us/library/bb680595.aspx

So I have to assume that it was to enhance Windows security. That is not
far-fetched, since the SYSTEM "user" is totally unrestricted and not suited to be
exposed directly to users from the outside.
I also have to assume that what they mean by "not installing other services that use
the Local System account" is to create a new user and running a service on behalf of
it.

Here's how they explain how to configure MS SQL Server (which uses impersonation),
but without explaining the underlying security model for services:

http://msdn.microsoft.com/en-us/library/ms143504.aspx

The only reference I can find about the service security model are the terms
"minimum rights" and "minimum privileges". 

In Linux, the daemon security model is well-known and can be implemented by running
as an 'unprivileged user'. Sendmail uses this idea extensively. 

Again, the only option I have at this moment is to run the Sendmail user (smmsp) as
an Administrator, so it can do impersonation. But this does *not* constitute
'minimum privileges', nor does this make the Sendmail user run as an 'unprivileged
user'.

The preferred solution is to only *start* Sendmail with a privileged user, let's say
'cyg_server'. Now Sendmail can switch to the 'smmsp' user and be running totally
unprivileged, only having access to its mail queue directory.

But after configuring Sendmail this way, it starts to complain about not having
access permissions, because it detects it was not started with the root user (getuid
!= 0). 

So, my original question was: can the Cygwin function 'getuid' be made to return '0'
if the program is running as the SYSTEM user? But because SYSTEM cannot be used
anymore, Corinna suggests to use 'cyg_server' instead and put checks for
administrator rights in the Sendmail source. 

In my reply to her in this thread, I rephrased my question: can the Cygwin function
'getuid' be made to return '0' if the program is running as the SYSTEM user or is
running with administrator rights?

Cincerely,
Daniel


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

