Re: run a program in memory , not from hard
"David Ching" <dc@remove-this.dcsoft.com> wrote in message
news:4ukCj.475$p24.85@nlpi061.nbdc.sbc.com...
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:fifjt3h3r9bou27irl1ok1t9oc6npdn1dp@4ax.com...
What I was saying is that the notion of "personal" computer is changing,
and the software
needs to adapt to those changes. In 1979, it was felt "acceptable" to
reboot your
personal machine whenever a program started doing something you didn't
like. Because it
was your "personal" machine. Uptime wasn't even a parameter that entered
the discussion
for these people, and I found it incomprehensible that they could not
understand the
notion.
I'm saying the same analogy holds true today: if it is my "personal"
machine, I should
control what happens on it. If I don't like your hook being in place in
my Word document,
I should be able to say "this hook is not permitted in this executable"
and that should be
a supported concept. I should be able to say "only these programs are
It is.
Without PROCESS_VM_OPERATION / PROCESS_VM_WRITE access to the other program,
the alleged malware is helpless to install hooks. If you haven't set
security appropriately, that is not the fault of the OS design (maybe it is
the fault of the shell design for not providing an easy way to configure
access restrictions when it launches a process).