Dave Temkin wrote:
So? Had the virii been an application compiled for RedHat and
everyone ran RedHat instead of Windows and they downloaded it using
Evolution and double clicked on it, it would suddenly be RH's fault
instead of MIcrosoft's? Or is it sendmail's fault because it was
listening on p
: So? Had the virii been an application compiled for RedHat and
: everyone ran RedHat instead of Windows and they downloaded it using
: Evolution and double clicked on it, it would suddenly be RH's fault
: instead of MIcrosoft's?
I suspect the skill set/clue of RH users is at least an order
hig
On Jan 28, 2004, at 11:56 AM, james wrote:
: So? Had the virii been an application compiled for RedHat and
: everyone ran RedHat instead of Windows and they downloaded it using
: Evolution and double clicked on it, it would suddenly be RH's fault
: instead of MIcrosoft's?
I suspect the skill set/
RedHAT do not allow to run an attachment, even if attachment wish to be
runned - it uses 'x' flag which is not attachment's attribute. Linus useers
are niot Administrator's, so virus can not infect the whole system,... Etc
etc
(Why RedHAT? It is the worst Lunux amongs all. Use SuSe or Mandrak
On Wed, Jan 28, 2004 at 12:07:36PM -0500, Patrick W.Gilmore said something to the
effect of:
>
> On Jan 28, 2004, at 11:56 AM, james wrote:
> Not sure why that is the case. Web browsers know better than to
> execute things, or at least to execute them in a sandbox, and there
> seems to be muc
Unfortunately, Microsoft products seem to have a default which is set to hide
file extensions and to make it very difficult to see 'multiple extensions' like
the '.doc.pif' in the current worm, it is somewhat easier to dress
a vampire in gerbil clothing in these systems than in others.
--
-=[L]=
On Wednesday 28 January 2004 08:37, Dave Temkin wrote:
>> So? Had the virii been an application compiled for RedHat and
>> everyone ran RedHat instead of Windows and they downloaded it using
>> Evolution and double clicked on it, it would suddenly be RH's fault
>> instead of MIcrosoft's?
>If Re
: Also, for reference to other people - the preview pane does *not* allow
: the execution of attachments unless they're double-clicked on and
: acknowledged. Again - we're not talking about another OS or Outlook
: exploit, only a stupid user exploit.
The "feature" has been fixed but it **did** a
>>: Also, for reference to other people - the preview pane does *not*
>>allow
>>: the execution of attachments unless they're double-clicked on and
>>: acknowledged. Again - we're not talking about another OS or Outlook
>>: exploit, only a stupid user exploit.
>The "feature" has been fixed but
: What's that got to do with today?
I might be reaching here, but I understand some people never upgrade or patch.
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> james
> Sent: Wednesday, January 28, 2004 4:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Misplaced flamewar... WAS: RE: in case nobody else noticed
> it, there was
> I suspect the skill set/clue of RH users is at least an order
> higher that windows users.
really, based on experience that would be surprising, rh is now so easy to get
and install, securing it is still problematic for most users
> The main problem I see is many e-mail readers default to hav
>
> Most Windows boxes are running with administrative privledges. That makes
> Windows a willing accomplice. The issue isn't that people click on
> attachments, but that there are no built in safeguards from what happens
> next.
This is problem #1. Unfortunately, Windose is too complex and hav
On Wed, 28 Jan 2004, Alexei Roudnev wrote:
>
>
> >
> > Most Windows boxes are running with administrative privledges. That makes
> > Windows a willing accomplice. The issue isn't that people click on
> > attachments, but that there are no built in safeguards from what happens
> > next.
> Thi
On Thu, 29 Jan 2004 07:41:20 -0500 (EST), you wrote:
>...
>When NTFS came out an ordinary user could not write the system directory
>tree Hence most users are running as Administrator or equivalent so that
>they can write into the system tree. This was a bad design decision by
>MS _and_ applicat
> [EMAIL PROTECTED] wrote:
> But, regardless, Win2K and WinXP do have restricted-user
> modes that tie this stuff down quite well. They tend to
> be used in corporate environments.
Indeed, and the one reason being that the last thing the IT staff wants
is users installing apps, because even if t
If I install code, I'd like to know, when installation is trying to make
_administrative_ change, explicitly - so that I have a chance to say YES or
NO. In Windows, it is not implemented in installations - you _must_ begin
installation as admin.
Another big problem is permission system and direct
On 30-jan-04, at 7:20, Alexei Roudnev wrote:
Second problem is directory structure. In Unix, when I configure IDS
(osiris
or Tripwire or Intact), I can just be sure, that 'bin' and 'etc' and
'sbin'
and 'libexec' directories does not have any variable files - all
non-static
files are in /var (So
On Fri, 30 Jan 2004, Iljitsch van Beijnum wrote:
> Actually IMO putting all their crap in their own dir is a feature
> rather than a bug. I really hate the way unix apps just put their stuff
> all over the place so it's an incredible pain to get rid of it again.
Putting all crap in the working
It's not completely the fault of anything except the end-user. It's like
the Jimmy Buffet song says:
Evolution is mean, there's no dumbass vaccine
scott
On Wed, 28 Jan 2004, Dave Temkin wrote:
: >>> : They rate of it is quite surprising. By the description, the trick
: >>>
20 matches
Mail list logo
