Re: Feedback needed on proposed cygwin feature

[cgf@bbc.com (Chris Faylor)]

In article < 34870542.A0933226@twinspot.net >,
Tomas Fasth  <tomas.fasth@twinspot.net> wrote:
>Chris Faylor wrote:
>
>> What security considerations are there that are not also present with
>> any other scheme, whether it is using extended attributes or setting options
>> in the registry?  You would have to have the right privileges to change
>> the binary.
>
>The binary is normally a single entity, shared among users. Configuring
>a certain  behavior at compile time is just fine, having it modified
>after installment is not. It will simply introduce all kinds of
>nightmares.
>
>If a user wants to change the behavior of a certain binary, it has to be
>done within that particular user's environment only. Otherwise, you will
>end up with a situation where no-one can trust current settings and
>being forced to check/reset the settings at each and every point of use.
>
>If I remember right, the registry allow user specific entries. Also,
>it's nothing new in the Unix environment to have configuration files for
>binaries stored within the file system space controlled by current user.
>We just have to figure out a viable structure to store such information
>into.
>
>> How does a virus detection program detect the difference between installing
>> a new version of bash or changing a byte in the existing file?
>
>It does not. At both occations the virus tripwire will be sprung.

Can you point me to some specific virus software that will complain given
the above scenario?

>But a binary installation is normally a system level activity, or at
>least done with an intention to share the binary among some or all of
>the users on that system.
>
>A change of a binary's runtime behavior should not require a change to
>the binary itself. I'm quite surprised that this option came up in the
>discussion in the first place. Everybody having worked in the Unix
>environment should realize the obvious security breach such solution
>would introduce. NT is certainly not an exception.

I guess I need more explanation about why it is "obvious" that modifying
the binary results in a security breach.  A user either has the right
to modify the binary or they don't.  If they don't, it is not a security
problem.  If they do then they can replace 'ls' with 'rm' if they want to.
They can also edit the binary with 'vi'.  So what?

Your point about individual users not being able to set their own per-binary
defaults is a good one, though.  So, I guess that means that we're back
to the registry, with all its attendent quirks.
-- 
http://www.bbc.com/	cgf@bbc.com			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".