UNIX Security Weaknesses and Potential Solutions



Hello Everyone:

I recall reading once, about 10 years ago (in a book titled "Out of
Control"), that writers of malware code protect their computers from
becoming infected from their own malware by creating a complete
virtual/simulated computer inside of their (real) computer and running
their malware code on the simulated computer. Although malware could
infect the simulated computer, it would not be able to (truly) infect
the real computer which is running the simulated computer. I suspect
that the real computer is used as a "dummy" terminal which only allows
input and display data to be transferred between the simulated computer
and the real computer. This would be one way to quarantine data. As
opposed to temporarily running code in a simulated environment to
observe it's behavior so as to determine if it will morph or mutate
into malicious code, one would actually be able to permanantly
quarantine all code. Since one would retain an uninfected computer (the
real computer), malware would not be able to compromise the ability of
anti-malware programs to detect malicious behaviour or unauthorised
activity. Any code which morphed into malware would be detectable.

Perhaps a similar strategy could be used by the average computer user,
at least when surfing the internet, in order (to prevent the firmware
from becoming infected). Such a strategy could (and should) be used by
web browsers (at minimum). Although this may seem unnecessary, since
one could utilise a back-up to restore their system every time they
restart their computer (or log on). Yet, utilising a real computer to
"remotely" operate a simulated computer is an interesting concept which
offers many other advantages not provided by restoring the system using
a back-up. For example, I am not certain that one would be fully
protected against the aforementioned firmware attacks by using a simple
back-up/restore strategy.

Do you (or anyone else reading this) know of a way to amend or alter
the UNIX code so that it is NOT possible to change the root password
without knowing the password which had previously been set? I would be
disappointed to learn that someone has not already made this . If not,
someone should make this amendment available. To those who object,
saying that it is important to retain an ability to reset the password
without knowing the current password, should it ever be forgotten or
lost, I say that for some (such as myself)...maintaining a secure
system is more important than protecting incompetent computer users
from themselves. An important password can be written down and hidden
in case it is lost. For those whom worry that the root user password
will become corrupted and prevent the user from logging in...I say that
restoring the system using a back-up would resolve the problem without
requiring one to change the root user password.

In my opinion, the fact that the root/super-user has unrestrained
administrative ability is a major security flaw. It should be possible
to protect different parts of the system using different administrator
and root/super-user paswords. For example, one admin password would be
required to install applications from inside user accounts. Another
administrator or root user password would be required to make changes
to specific folders, volumes, etcetera. And perhaps yet another
password would be required to log into the admin/root account. This
would prevent an intruder from gaining wide access to the system using
a single stolen password. Perhaps this is already a security feature
offered by "permissions"? If not, it should be. My understanding is
that permissions are to restrict file and folder access to certain
users and do not apply to data in the RAM (or elsewhere). Of course,
keystroke capture software may function simply by monitoring keyboard
activity as opposed to reading data located elsewhere in the RAM, in
which case it would also be necessary to restrict system access to the
keyboard so that any malware will not be able to read data entered into
the keyboard (at least while the password is being entered). I'm sure I
don't need to explain the principle of least/minimum privelege to most
readers of this forum.

In the end, it seems as though someone desires to keep the door wide
open, if you ask me. I have been the
victim of computer security vulnerabilities for the past 10 years. My
life has been destroyed as a result. Now I know why. And I'm sure I'm
not the only one who is suffering. We need to end this reign of
tyranny which has been wrought by legions of devious souls intent upon
destroying the integrity of people's lives. Perhaps the ideas I've
presented herein will be of assistance in fulfilling the objective of
giving the power back to the people whom it rightly belongs to.

-Phantasy

.

Relevant Pages

  • Re: A question for the group
    ... They don't protect you from trojans. ... Even on windows, careful use of NTFS permissions and user level clearances can limit programs' damage to some extent, but on the majority of windows setups, any program can pretty much do what it wants to any files, including vital OS files. ... Add that on *nix systems, it is hard to get malware programs to run without user intervention, and you have an inherently much safer system. ...
    (sci.electronics.design)
  • Re: anti virus programs
    ... designed to help protect your computer from virus, worms, and Trojans. ... uniformed computer users who thoughtlessly click pretty links or ... download and install the "brightest and shiniest" new, ... this malware are email attachments that many people open and execute ...
    (microsoft.public.security.virus)
  • Re: Win xp sp2 firewall
    ... the proper approach. ... protect them or us from them. ... get something better then SP2 firewall. ... Why even encourage people to allow malware to ...
    (comp.security.firewalls)
  • Re: Re:How To Suspend Thread In Kernel?
    ... Malware comes to kernel mode and begin hooking SDT, ... third companies create components that hooks API to protect themself from ... Everyone on this thread says that this is dangerous trick, ...
    (microsoft.public.win32.programmer.kernel)