public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Permissions and Security Documentation
@ 2000-01-03 11:19 Buddy Carter
  2000-01-15 19:56 ` Chris Faylor
  0 siblings, 1 reply; 2+ messages in thread
From: Buddy Carter @ 2000-01-03 11:19 UTC (permalink / raw)
  To: cygwin

I would like to bring to your attention, or maybe better put, to
complain about your statement within your CYGWIN User Documentation
section on Permissions and Security. We here at General Dynamics Weather
Systems Engineering are inclined to use CYGWIN as opposed to INTERIX for
porting our existing weather information server software to the NT
environment (from Solaris). We believe CYGWIN will result in a faster
implementation and faster execution of processing when the port is
complete. However, our primary customer is the US government (Department
of Defense/Air Force/etc). The second to last last sentence of your
verbiage on the Permissions and Security states:
" For this reason, it is not appropriate to use Cygwin in high security
applications".

I believe this statement is a disservice to CYGWIN and is in fact,
depending upon the situation, totally false. The term "high security" is
ambiguous at best, subjective at least. The appropriateness of use of
applications in a secure environment considers many factors, including
risk. If a server is within a locked down facility, only one "user" can
access it at a time, and all other services are Web Based, then I
believe this "vulnerability" within a Secret or Classified/Sensitive
environment is in the worst case, minimal. Statements like this one may
prevent us and many other vendors from delivering CYGWIN to ANY
government agency. The fact is that all agencies of the government, even
within an unclassified environment, are increasingly sensitive to
statements such as this. There presence makes all other reasoning
hopeless.

I would humbly request that the sentence be stricken from your web
page/documentation. It would help us and I believe it would help CYGWIN
as well.


Thanks,

Buddy Carter
General Dynamics
Weather Systems Engineering



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Permissions and Security Documentation
  2000-01-03 11:19 Permissions and Security Documentation Buddy Carter
@ 2000-01-15 19:56 ` Chris Faylor
  0 siblings, 0 replies; 2+ messages in thread
From: Chris Faylor @ 2000-01-15 19:56 UTC (permalink / raw)
  To: Buddy Carter; +Cc: cygwin

I'm sorry that it has taken so long to respond to this.

On Mon, Jan 03, 2000 at 11:11:50AM -0800, Buddy Carter wrote:
>I would like to bring to your attention, or maybe better put, to
>complain about your statement within your CYGWIN User Documentation
>section on Permissions and Security. We here at General Dynamics Weather
>Systems Engineering are inclined to use CYGWIN as opposed to INTERIX for
>porting our existing weather information server software to the NT
>environment (from Solaris). We believe CYGWIN will result in a faster
>implementation and faster execution of processing when the port is
>complete. However, our primary customer is the US government (Department
>of Defense/Air Force/etc). The second to last last sentence of your
>verbiage on the Permissions and Security states:
>" For this reason, it is not appropriate to use Cygwin in high security
>applications".
>
>I believe this statement is a disservice to CYGWIN and is in fact,
>depending upon the situation, totally false. The term "high security" is
>ambiguous at best, subjective at least. The appropriateness of use of
>applications in a secure environment considers many factors, including
>risk. If a server is within a locked down facility, only one "user" can
>access it at a time, and all other services are Web Based, then I
>believe this "vulnerability" within a Secret or Classified/Sensitive
>environment is in the worst case, minimal.

Hmm.  Well, no one is claiming that Cygwin will act as a magnet causing
perpetrators of illegal acts to migrate to your facility, so, sure, if
you are in a locked-down facility, accessible in the way that you
mention, then it is hard to imagine a software product which would pose
much of a risk.

Although, now that I think of it, if you're running any CGI scripts on
this theoretical web site then you are at risk since Cygwin's security
model is wide open to a craftily written perl script.  So, even here
I could foresee problems.

>Statements like this one may prevent us and many other vendors from
>delivering CYGWIN to ANY government agency.  The fact is that all
>agencies of the government, even within an unclassified environment,
>are increasingly sensitive to statements such as this.  There presence
>makes all other reasoning hopeless.
>
>I would humbly request that the sentence be stricken from your web
>page/documentation. It would help us and I believe it would help CYGWIN
>as well.

This is not going to happen.  We understand the security vunerabilities
of Cygwin very well.  The security model is basically security through
obscurity which, I'm sure you are aware, is no security at all.

So, it would be a disservice to anybody who used it to imply that cygwin
was secure.  It was never designed to be secure.  It undoubtedly has all
sorts of exploits, like buffer overruns, which could make it insecure.

We would certainly consider changing this if a customer wanted to pay
for this work.  It would be a very interesting project.

Until such time, however, we have a moral and legal obligation to point
out the facts about cygwin's lack of security.  So, the statement is not
going anywhere.

I'm sorry.  I really hate to turn away potential users but I like
to misrepresenting facts even less.

-Chris Faylor
-Cygwin Engineering Manager
-Red Hat

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2000-01-15 19:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-03 11:19 Permissions and Security Documentation Buddy Carter
2000-01-15 19:56 ` Chris Faylor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).