According to Pavel Galynin:
>
>Are you familiar with Unix desktop anti-virus soft?
Not targeted at the unix binaries - the problem that a virus writer
has on unix is that, unless the user is really sloppy with their root
access (i.e. they run as root all the time OR they have . in their
path), then about the best the virus can do is attach it to the user's
own files.
> i'm not, but I
>assume that with Unix high-level programming required for portability
>and impossibility to write ASM progs.
When you assume....
You can write assembly programs on the unix platform, there is nothing
stopping you doing this. The reason that most people do not do it is
that there is very little you can do without resorting to system calls
and constructing a syscall stack frame in assembly is a pain in the
arse. You seem to have a very dos/pc centric view and are trying to
translate this to unix - typically on a unix machine (regardless of
the architecture) you cannot take control of _any_ of the hardware, to
do so would result in a access violation and the termination of your
process.
> This leaves you undefended and
>dressed-down in front of a polymorphic. I would be scared to even think
>about what would happen if a virus was designed for a specific Unix
>brand and platform...
Getting the thing onto the machine is a bit of a problem - the pc
world works on handing binaries around which makes it easy to hide the
real intent of the code. Traditionally, on a unix platform the source
is distributed due to the problems of making binaries for all the
different platforms, this in itself does not guarantee protection
against malicious code but it does make it harder to hide.
>Well, I don't know of any virii that use protected mode, but if there
>were ( there could be by now ), circumventing Unix memory protection
>would be very easy with some use of Appendix H and the likes
>instructions.
Suggest you go back and read your appendix H again - you will find
that those instructions only work in ring 0 (from memory, my 486 book
is a long way away), if you try to access those instructions from any
other ring you will generate a trap. Guess which ring all the user
processes live in - not ring 0 so any attempt to manipulate the mmu or
other such instructions will result in the user process being
terminated.
>Just lookin' :))
I suggest you do that with the source of one of the free unixen. It
would be most educational for you I think - especially how the kernel
controls access to the hardware.
Brett"grovels kernel structures for fun & profit"Lymn
--
Brett Lymn, Computer Systems Administrator, AWA Defence Industries
===============================================================================
"Upgrading your memory gives you MORE RAM!" - ad in MacWAREHOUSE catalogue.
Follow-Ups:
References:
|
|
