16 Nov
2005
16 Nov
'05
5:40 p.m.
[Apologies for the length of the reply; it is a longish one. -Mike]
Sarocet wrote:
I had an idea about virus propagation. As we'll
have added attribs on
FS, i'd implement the eXecution flag. No program could be run
without it. If a DLL were loaded it'd have that flag would
automatically set (if allowed). If you try to run a program, the
explorer.exe or whatever else program tha tried to call it must ask
the user for permission or handle the adding in an efficient way. If
you modify, append, or in whatever method change a file, the +x would
be reseted. Any program can set that flag on, BUT if before it gets
set, the system calls a DLL (could be an exe, but it should stay in
memory as it can be very frequently called...) that checks it for
virus. If it's ok, it allows the flag. If not, the flag is not set
(it doesn't remove it, as it have never been set). Then the DLLs can
be very different, they can check it into an internal virus database,
ask about it at the ROS website (the problem'd be to determine what
it can give apart of a hash, that not reveals personal informetion, a
filename or path can reveal too much), give it happily (first
implementation), ask the user if (s)he's experienced (if not, the dll
loads can be very annoying :D)...
For one thing, Win32 (the NTFS filesystem) already provides for this.
All files are created with the "Read & Execute" permission set on by
default. This is why there can be problems when exchanging files from a
Windows box and an improperly configured Samba box if you are trying to
retain security on it by disallowing execution.
However, the whole idea is sort of like the (rather broken) general
permissions system of Windows. It's hard to fix it without breaking a
lot of programs and making things difficult for the end-user; in order
to do nearly anything, you need Admin privileges. If you start
restricting everything by default and expecting the user to actually
administer their box, you're introducing confusion and likely driving
people away from using what is (read: will be) a very high-quality system.
Microsoft has claimed to have started to make a transition to a more
UNIX-like way of handling permissions, which would be safer and more
secure, where Admin rights aren't needed everywhere you go. Part of it
is that Windows will prompt you to run files and let you know if they're
"signed" or not. That's a worthy system to support. It doesn't get
terribly much in the way of the end-users, and it helps to boost what
the end-user can do to create a more secure environment both standalone
and networked.
The permissions thing is already in the system layout, it would just
need to be *used.* In fact, Windows, and the Win32 way of working with
the filesystem, provides for total ACLs and such that Linux/UNIX
filesystems, AFAIK, are pretty new to. You can have ACLs with
ext2fs/ext3fs, IIRC, and if those systems are used with ReactOS, it'd
make a great pairing. Probably so with ReiserFS, too. It'll be a long
time before NTFS is supported natively, I think, but the permissions
system is something that can be used on other filesystems that support it.
As that flag can be set to any file, programs that use macros, must
then -to be compliant- confirm before that the file has +x. If not,
load without macros, ask the user, not load... That aplies to WSH,
Java, Flash, Php, shell scripts...
That would be extremely difficult to do. You're then expecting the
filesystem to know everything about every single file that is on the
system. Rather, it'd make more sense to try to get things so that they
don't run with privileges that are able to really do any damage; that's
how control is given on UNIX systems. I don't +x my PHP scripts on the
web server; I do, however, have the Web Server set up to run as a user
without permissions to write anywhere except for its own log directory.
That helps to keep the environment safe.
Perhaps a better idea here would be to create some mechanisms in the
system that can retain compatibility with the Win32 way of doing things
(run as a privileged user all the time) and the best practice way of
doing things (run as a regular user for anything that doesn't explicitly
need administrative rights) and educate the users on that. This relives
some of the burden on the operating system and puts it back into the
hands of the network administrator/system administrator. Development
workstations, such as what you find in someone's home, are traditionally
behind a NAT, and if a dev is silly enough to run scripts that they
haven't at the very least reviewed... Well. *shrugs* There's something
to be said for "due diligence" to system security, and if you're a
developer, even just for something like small PHP or ASP Web projects
(under 5 files), you should be able to know to look before leaping.
FS like FAT would have then an index file with the programs with +x,
some kind of system to emulate it. Removable devices (USB sticks,
CD-ROMs, floppy-disk...) must not have +x flags. A remote computer
can think it's secure but our computer (note that we can't be sure
we're the same, everything can be faked) must not trust on it. +x
should only stay per session, not allowing the user to set it. If a
+x flag is found set, the system must ignore it.
You may recall; that's how Windows implements VFAT; they added hacks
into their FAT filesystem drivers to support the features that Windows
95 attempted to make so popular, with long filenames and the like. This
was done similar to the volume label hack way back in the days of MS-DOS
when they added the Volume Label as a special portion in the BPB, as
well as a hidden file that had an impossible attribute set attached to
it. The FAT system isn't really reliable and I don't think that it's
really safe to add new "features" to it - it's one filesystem that was
so poorly designed that it's seriously only good for short-term use on
removable media.
The system'd be more secure and only executable files get scanned,
and only once so it's fast (by the way, i have to disable my
antivirus before updating svn, as it tries to scan them all, so it
slows a lot). If you think you've a virus, or simply monthly, for
example, you can ask a program to reset all +x flags (no check is
done to remove it), so your programs will be scanned next time :-)
It sounds like what you're suggesting is that the system should assume
that each file gets to "earn" the executable attribute, and then you can
assume that unless the user pulls the attribute, the file is safe.
That's not really a good idea; users tend to be pretty bad housekeepers
when it comes to computing. It's best to leave the system work without
trying to introduce new points of failure, regardless if said new points
of failure are in the technical aspect of the system, or in the user
aspect of the system. Virus scanners do their jobs pretty well by
default, and you can configure them to streamline their performance so
that on-access scanning requests can be queued and what-not, helping to
streamline SVN/CVS updates, archive extraction, and so forth.
I know that my scanner keeps an internal database of when it does
sweeps, does on-access scanning, and I have it configured to perform one
full system sweep once per week, when the computer is known to be idle,
without impacting any performance on what I do or when I work on the
system. I don't notice *any* performance hit on the on-access scanning,
either, even when using the web (I have a very large cache size for
images and the like, and that is constantly being hit by the OAS part of
my AV system, without a hit).
The benefit of this is that as it'd be implemented at low level
(driver, or between driver and system), it can be more secure, with
less work.
It actually sounds like it'd create a veritable load of problems;
essentially, breaking compatibility with Win32 and how Windows does
things. Remember, the system needs to come out being compatible, that's
one of the design goals.
It sounds like one of the better ways to go about handling this would be
to use the process management aspects of the system to reduce the
execution priority of the virus scanner toolset; this would enable the
system to not lose any performance to a virus-scanner, while keeping the
system running at a proper speed. I don't think changing the system's
interfaces is the answer to this, in any case.
Regards,
Mike
--
Michael B. Trausch fd0man(a)gmail.com
AIM: MB Trausch Jabber: mtrausch(a)jabber.com