This is the mail archive of the cygwin@cygwin.com 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: Single-user Cygwin for improved security under standalone use with OpenSSH


John,

This is coming from a different angle, but have you thought of tightening
security using the SSH server instead?  I think you are considering opening
up an interactive session using SSH in order to execute arbitrary commands
on the remote system.  However, you can configure ssh on a per-account basis
to use forced commands rather than executing whatever program the user
wants.  You can write a script to parse the command sent by the user and
then execute the appropriate program.  You can also disable tty and
interactive sessions.  It seems like this might be a simpler approach than
trying to restrict what an ssh user can do in an interactive session.

The O'Reilly book "SSH, the Secure Shell: The Definitive Guide" (see
http://safari.oreilly.com/0596000111) is an excellent source for how to do
this.

-Mark

----- Original Message -----
From: "WARDEN,JON (HP-FtCollins,ex1)" <jon.warden@hp.com>
To: <cygwin@cygwin.com>
Sent: Tuesday, July 08, 2003 6:39 PM
Subject: Single-user Cygwin for improved security under standalone use with
OpenSSH


>
> We would like to use a Cgywin-based OpenSSH implementation
> (http://lexa.mckenna.edu/sshwindows/)
> for running tasks remotely on Windows (2000, XP) systems. The systems
> involved would have this
> OpenSSH distribution installed on them, but not a full Cygwin
distribution.
> The security issue
> of non-administrators being able to open the named memory-mapped files
used
> by Cygwin (for example,
> the pinfo class) is a concern, however.
>
> We can live with the restriction of a single-user model, where tasks on
the
> target system can
> only be run as a user in the Administrator group. In this situation it
seems
> to me that some
> restrictions on the SECURITY_DESCRIPTORs used for CreateFileMapping()
could
> be made. To test
> this idea with a simple change, I changed early_init_stuff() in
> exceptions.cc so set the
> sec_all and sec_all_nih struct's lpSecurityDescriptor to NULL, just like
the
> sec_none struct
> is currently.
>
> Without this change I was able to OpenFileMapping() and MapViewOfFile() on
> the pinfo memory-mapped
> file as a non-administrator. With this change, I couldn't.
>
> Now I am wondering, "Is restricting the SECURITY_DECRIPTORs for named
> memory-mapped files a
> reasonable way to close this vulnerability (given our willingness to
settle
> for single-user)?"
>
> If it is, the next question is, "Is it good for anything else?" In a
> multi-user Cygwin context,
> it seems unhelpful, but does it make sense to have a "single-user"
> configuration of Cygwin
> with improved security?
>
> Jon Warden
>
> --
> 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/
>
>



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