Dan Scott wrote:
I agree with your evaluation, Pixel.I agree with Dan in part. What I do to cope with this in part is:
Rationale: ---------- Worrying about a largely theoretical Linux virus seems pretty pointless.
Let's think about the user base that we're targeting:
* absolute beginners (the same ones likely to use autologin and msec 0):
will want to browse through their FAT32 filesystem to load and edit
their MS Word documents, then reboot into Windows for some other
application where they may also load the same document in MS Word again,
until they become accustomed to Linux and break ties with Windows. These
users are quite unlikely to quickly figure out how to change the mount
permissions, and not particularly likely to understand why they were
prevented from writing to those files in the first place... if it's
FAT32, in Windows they can delete pretty much anything they like.
* power users: familiar with at least one desktop environment, able to
find drakconf and change the permissions to lock themselves out of FAT32
partitions if they so desire (or able to browse the HOWTOs and learn
enough to edit /etc/fstab to do the right thing)
* LPIC-certified sysadmins: able to tweak /etc/fstab to their heart's
content
Just to get my own biases out of the way, I'm LPIC-1 certified, but
(shh) probably closer to a power user than sysadmin. I would expect this
kind of setting to be determined by msec, and/or easily tweakable
through drakconf.
Dan
On Tue, 2003-01-21 at 20:05, Pixel wrote:
"[Bug 974]" <[EMAIL PROTECTED]> writes:
The value of umask(=0) makes many system files on the FAT32 partition writable by a non-root linux user. This is very undesirable and risky. In the extreme case, a well-designed linux virus can easily damage the windows system files !! The proper solution to this is to change the umask value to 022 so that only root has write access to the FAT32 system.umask=0 is what people want AFAIK...
cooker people, WYT?
@resolution=invalid
@product=Installation
First, share only data files- that leaves older macro viruses, they tend to mostly corrupt files that are of the file type that the macro was written for, and the types I shared get scanned on open by NAV anyway. Actually, now I use only apps that run in Win4Lin 4.0. And they are writing data to directories that are actually on Ext3FS files systems. My /home is now huge, about 20 Gig.
Secondly, I could in Windows simply select all files in a directory, remove the read only that previous versions of Mandrake marked said files, and edited to my content thereafter. Windows users with Linux multiboot who run ISOs or file sets in SAO or TAO with fixate to CD-RW also quickly catch on to the need to do this when transferring those to other boxes that need to be able to operate them. I do this 5-10 times a week-- not complaining, saying that Windows users will usually know how to fix with 3 mouse clicks in Windows.
Thirdly, I tend to use RAV desktop AV in LINUX to check my pseudo FAT32 file subsystem encapsulated in four subtrees of my ext3 /home part, once a week or so(did this with my Windows true FAT32s before)-- and found nothing, nada for the month I have been doing so(this month from end of December 2002). 90% of Windows viruses primarily propagate from box to box by email, and while a novice might THINK something that said it was a Word doc trashed his machine, it was an executable encapsulation inside the doc that unarchived and acted. So, email AV scanning will break at entry for almost any known viruses. AND, RAV desktop for Linux has every def. that RAV fro mail servers has and every def. that the RAV for Windows has. AND, Windows viruses cannot trash Linux apps except those few that were ported with identical compromises built in and retained from other operating systems source apps.
Documenting this triune strat might just help quell such things, and if Mandrake can partner to include a year of RAV desktop in PowerPack or PowerSuite that would probably complete a non-recoding full solution.
John.
