Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <00cd01c345a9$6d91b100$6902a8c0@markonius> From: "Mark Priest" To: References: Subject: Re: Single-user Cygwin for improved security under standalone use with OpenSSH Date: Tue, 8 Jul 2003 19:34:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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)" To: 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/