Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Authentication-Warning: slinky.cs.nyu.edu: pechtcha owned process doing -bs
Date: Tue, 23 Mar 2004 17:22:17 -0500 (EST)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: Richard Troy <rtroy AT ScienceTools DOT com>
cc: cygwin AT cygwin DOT com
Subject: Re: suid bit on executables?
In-Reply-To: <Pine.LNX.4.33.0403231159470.1808-100000@denzel.sciencetools.com>
Message-ID: <Pine.GSO.4.56.0403231713050.2650@slinky.cs.nyu.edu>
References: <Pine DOT LNX DOT 4 DOT 33 DOT 0403231159470 DOT 1808-100000 AT denzel DOT sciencetools DOT com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.39

On Tue, 23 Mar 2004, Richard Troy wrote:

> Hi Igor,
>
> Interesting dialogue, but you seem to be mising one CRITICAL point, which
> I apparently didn't make clear: It is absolutely unacceptible to have the
> user of the software in question know any password other than the one for
> their own account or otherwise have access to privileges they're not
> supposed to have (through ssh keys, for example). The objective of the
> exercise is to find a way to enforce "proper" security.

Richard,

Then this won't work - installing a service can only be done by someone
with a "logon as service" privilege.

> Therefore, installing as a service with a password is entirely
> acceptible because it's done by a system administrator type person who
> _has_ the appropriate privilege...

Oh, I see the misunderstanding here.  I actually meant installing *and*
using the service right away.  If you wanted to have a service that always
runs and, when accessed by any user, opens a new window with a particular
application in it (running as someone else), you're really better off with
sshd.

> That said, the _LAST_ thing I'd want is to have a privileged console
> program come up and provide _any_ access whatsoever! ... Anyway, your
> suggestion about /dev/conin and /dev/conout may well be on the right
> track. Here might be a reasonable solution:
>
> $ cygrunsrv --install <my_service> --path <path_to_my_program.exe>
>  --args "<my_programs_args> </dev/conin >/dev/conout 2>/dev/conout"
>  --env <my_progs_env_vars> --username <proper_prived_account>
>  --password <proper_prved_accounts_passwd> [other cygrunsrv args]
>
> ...While typing all these emails, I've been trying to do just this!
> However, I've had to reboot a couple of times, and am otherwise slowed
> down a little. -frown- The key here is, from the command line, how does a
> user fire off a connection/dialogue with the installed program/service? My
> bet is, though, that this isn't possible, since you go on to state:

Exactly.  I was thinking of a way of having a somewhat privileged user
execute a program as someone else, with no concern for the security of
your system (which isn't much on Windows anyway).

> > conin/conout will let the process access the console that cygrunsrv pops
> > up, rather than the stdout/stderr file descriptors, which are redirected
> > to files in /var/log...
>
> ...and I very surely don't want any popup console!
>
> > Technically, you should have been able to look at
> > <http://cygwin.com/cygwin-ug-net/using-specialnames.html> instead...
>
> Thanks for the pointer...
>
> > The Cygwin User's Guide makes for wonderful and exciting bed-time
> > reading. ;-)
>
> (At one point, about 3 years ago, I actually read all available Cygwin
> documentation "cover to cover. -Yawn!-  )
>
> > However, the above document is strangely silent on the topic of
> > conin/conout...  As things stand now, looking at the Cygwin source is
> > probably your best bet.
>
> ...Hopefully that won't be necessary! I take it that conin and conout are
> "console in" and "console out", respectively, though I don't yet see how a
> user at a bash prompt, for example, hooks up with the installed program.
> If that can be done, I'd MUCH rather this solution than to use ssh...

I think, given what you said above, that sshd is your best bet,
unfortunately, until cygserver can do suid.

> > Yes, except you'd probably need to redirect the stdout to /dev/conout as
> > well.
>
> As above, maybe?
>
> > Yes, cygrunsrv allows services running explicitly as some user, with two
> > caveats: they can't be interactive, and you'd need to enter a password for
> > that user.  The above method will let you switch the context with no
> > password, thus emulating the "suid" functionality.
>
> I got errors when I tried to use the --interactive flag as found in your
> example, and -h didn't show it, either! -smile- Oh well...

Do you have the latest version of cygrunsrv?

> > All the password checking, etc, is superficial.  The point is that there
> > exists functionality that lets any user, no matter how unprivileged, to
> > switch the context to that of any other user, as long as the appropriate
> > permissions are verified (e.g., the user knows the root password).
>
> Well, I don't think the password checking is superficial at all! I'm just
> trying to let the "unprivileged user" have access to functionality
> (provided by a special program) without having access to the actual raw
> data (as used by that special program). ...The system administrator sets
> up that special data and special program... The "unprivileged user" must
> remain that way!

The password checking is an important part of the whole process, but is
completely orthogonal to the user context switching functionality.

> > I didn't say that having this functionality is a security hole, I just
> > said that in Windows, a user context switch is not possible from all user
> > accounts unless special privileges are assigned to all user accounts,
> > which *would* open a security hole.
>
> I sure hope you're wrong as that's what this whole exercise is all about!
> We want a user context switch to a new user without having to give extra
> privileges to anybody!

Again, sshd allows this.  The way it allows this is by running as a
privileged account (SYSTEM), and allowing non-privileged accounts to
communicate with it.  FWIW, I think that, if you plan to provide your own
service for the suid functionality, you'll be rewriting substantial parts
of either sshd or cygserver (or both).
	Igor

> I suspect that we're in violent agreement, it's just that you've perhaps
> misunderstood what I was after. -shrug-
>
> And again, thanks for the dialogue...
> Richard

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

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