Mail Archives: cygwin/2004/03/23/17:22:53
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/
- Raw text -