This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: suid bit on executables?


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

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:

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

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

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

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

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

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]