Re: run a program in memory , not from hard
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:4f7lt3l6td9cj29u8dkakedlekg235ha8h@4ax.com...
Fine. That's another difference between "Vista Home" and "Vista
Professional". The home
version has default policies that enable everything; the professional
version has default
policies that disable some things. But I can change the policy after
installation so
either one can implement any policy I feel like
But the Home market needs this policy thing even more than the enterprise
does. Many enterprises are already locked down and the malware won't get on
there through other means.
2) Even if they did know, they would hate the popups just like they hate
Vista UAC prompts; and
****
I'm willing to trade off popups for security, as long as I have a way of
saying "You don't
need to ask this question under <these circumstances>" where the
conditions might be
"ever", "from the Microsoft Web Site", "from the local disk", etc.
****
Heh, when Outlook blocks all .exe attachments because it can't think of an
effective UI to ask the user whether to really allow it or not, and have the
user give a thoughtful answer, the UI you propose would be extremely
difficult to design.
3) You really do have the policy already by choosing to run the
hook-setting program or not.
****
I do? And do I know a program sets hooks? Do I know if an ActiveVirus
control is setting
hooks? I can't even get a list of hooks and who set them (a gross
oversight in the hook
API; where is EnumHookProcesses, which gives me a list of every process
that has a current
hook set, and what kind of hook)
****
For many people, they either trust a program or they don't. If they trust
it, it can do whatever it wants. In another message you mention giving
Acrobat more rights than you would from someone you haven't heard about. So
even though you might not give Acrobat rights to everything, what you
propose and what people actually do with trusting an app wholeheartedly is
not that different. I doubt you would stop a program like Acrobat from
installing any hook it wants, even if you did not understand the reasons for
it installing the hook... and you won't know the reasons. I really doubt
Acrobat or anything else will list in their on-line help the reasons for
installing a hook, and even if they do, there's no reason to trust their
reason. All of which says that after all this work to design this thing you
propose, you still won't have significantly better security.
What I had an issue with was your saying, "no sane OS should have the
capability [of allowing hooks]". As long as we're clear that you're not
advocating removing hooks, and instead are advocating a policy by which
they
can be restricted, we agree.
****
No, I said that no sane OS should allow me to randomly overwrite the
process memory of an
arbitrary process from another arbitrary process. Such overwrites should
be limited to,
for example, the debugger process, and by default should be blocked for
every other
process, unless I specifically enable it. If any process can overwrite the
memory of any
other process, then ActiveVirus controls can (and do) modify behavior in
unintended ways
(except as intended by their creators, for tasks such as DoS attacks,
identity theft, and
industrial espionage. Note that I have taught courses in how to use these
techniques, to
groups like DoD security teams, and pointed out there is no way to prevent
or detect such
attacks).
What exactly is the difference between a hook and randomly overwriting
another process's memory? Either way, once your code has been injected into
another process, it can do whatever it wants, so I fail to see the
difference in what I said you said and what you claim you said.
-- David