Re: The eternal uid issue

[Andrey Repin <anrdaemon at yandex dot ru>]

Greetings, D. Boland!

> 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.

There's no "model", there's "rights" or "capabilities", or "privileges".

> I searched the web extensively for an explanation on the newly imposed restriction.
> I didn't find one yet.

Because there's none.

> 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."

Exactly that. What is unclear?

> So I have to assume that it was to enhance Windows security.

It's to enhance operating security of default installations. "Windows
security" as a "model" isn't changed in even slightest way.

> 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".

It's not "model" again. It's privilege separation.

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

That's no different here. The point you miss is that in Windows you don't have
single "privileged user", which is just a long synonym for "root" in Linux
world. You have exactly "privileged users", as in "users that have privileges
above and beyond".

> Again, the only option I have at this moment is to run the Sendmail user (smmsp) as
> an Administrator, so it can do impersonation.

You contradicting yourself. Mere lines above you said your Linux user is
unprivileged, now you want to do impersonation. Which is only possible for
privileged user.

> But this does *not* constitute 'minimum privileges', nor does this make the
> Sendmail user run as an 'unprivileged user'.

That because... see above.

> 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.

Right.

> 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). 

Look, here you have a problem, that you don't want to understand it seems.
Checking for 'privileged user' is not the same as checking for 'uid == 0'.

> So, my original question was: can the Cygwin function 'getuid' be made to return '0'

No. A blatant and angry one. There's more systems, than Linux, and not all of
them employ same security model, nor their model can be closely approximated
to the one in Linux.

> 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'

"Can", "will" and "want" (or in our case "should") are three completely
different terms. The fact their areas intersect sometimes is a complete
coincidence.

> if the program is running as the SYSTEM user or is
> running with administrator rights?

No. If you want to do the right thing, do it right.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 24.07.2014, <16:05>

Sorry for my terrible english...